[要約] RFC 9433 は、モバイルユーザープレーンにおけるIPv6セグメントルーティングの適用性と目的を議論しています。SRv6のネットワークプログラミングの性質は、モバイルユーザープレーンの機能を簡単に実現し、柔軟性やSLAコントロールを提供します。
Internet Engineering Task Force (IETF) S. Matsushima, Ed.
Request for Comments: 9433 SoftBank
Category: Informational C. Filsfils
ISSN: 2070-1721 M. Kohno
P. Camarillo, Ed.
Cisco Systems, Inc.
D. Voyer
Bell Canada
July 2023
This document discusses the applicability of Segment Routing over IPv6 (SRv6) to the user plane of mobile networks. The network programming nature of SRv6 accomplishes mobile user-plane functions in a simple manner. The statelessness of SRv6 and its ability to control both service layer path and underlying transport can be beneficial to the mobile user plane, providing flexibility, end-to-end network slicing, and Service Level Agreement (SLA) control for various applications.
このドキュメントでは、モバイルネットワークのユーザープレーンへのIPv6（SRV6）を介したセグメントルーティングの適用性について説明します。SRV6のネットワークプログラミングの性質は、簡単な方法でモバイルユーザープレーン機能を達成します。SRV6のステートレス性と、サービスレイヤーパスと基礎となる輸送の両方を制御する能力は、モバイルユーザープレーンに有益であり、さまざまなアプリケーションの柔軟性、エンドツーエンドネットワークスライス、およびサービスレベルの合意（SLA）制御を提供します。
This document discusses how SRv6 could be used as the user plane of mobile networks. This document also specifies the SRv6 Endpoint Behaviors required for mobility use cases.
このドキュメントでは、SRV6をモバイルネットワークのユーザープレーンとして使用する方法について説明します。このドキュメントは、モビリティユースケースに必要なSRV6エンドポイントの動作も指定しています。
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。IESGによって承認されたすべてのドキュメントが、インターネット標準のあらゆるレベルの候補者であるわけではありません。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/rfc9433.
このドキュメントの現在のステータス、任意のERRATA、およびそれに関するフィードバックを提供する方法に関する情報は、https：//www.rfc-editor.org/info/rfc9433で取得できます。
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2023 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。
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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Terminology
2.1. Terminology
2.2. Conventions
2.3. Predefined SRv6 Endpoint Behaviors
3. Motivation
4. 3GPP Reference Architecture
5. User-Plane Modes
5.1. Traditional Mode
5.1.1. Packet Flow - Uplink
5.1.2. Packet Flow - Downlink
5.2. Enhanced Mode
5.2.1. Packet Flow - Uplink
5.2.2. Packet Flow - Downlink
5.2.3. Scalability
5.3. Enhanced Mode with Unchanged gNB GTP-U Behavior
5.3.1. Interworking with IPv6 GTP-U
5.3.2. Interworking with IPv4 GTP-U
5.3.3. Extensions to the Interworking Mechanisms
5.4. SRv6 Drop-In Interworking
6. SRv6 Segment Endpoint Mobility Behaviors
6.1. Args.Mob.Session
6.2. End.MAP
6.3. End.M.GTP6.D
6.4. End.M.GTP6.D.Di
6.5. End.M.GTP6.E
6.6. End.M.GTP4.E
6.7. H.M.GTP4.D
6.8. End.Limit
7. SRv6-Supported 3GPP PDU Session Types
8. Network Slicing Considerations
9. Control Plane Considerations
10. Security Considerations
11. IANA Considerations
12. References
12.1. Normative References
12.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
In mobile networks, mobility systems provide connectivity over a wireless link to stationary and non-stationary nodes. The user plane establishes a tunnel between the mobile node and its anchor node over IP-based backhaul and core networks.
モバイルネットワークでは、モビリティシステムは、固定および非定常ノードへのワイヤレスリンクを介した接続を提供します。ユーザープレーンは、モバイルノードとIPベースのバックホールとコアネットワーク上のアンカーノードの間にトンネルを確立します。
This document specifies the applicability of SRv6 [RFC8754] [RFC8986] to mobile networks.
このドキュメントは、SRV6 [RFC8754] [RFC8986]のモバイルネットワークへの適用性を指定しています。
Segment Routing (SR) [RFC8402] is a source-routing architecture: a node steers a packet through an ordered list of instructions called "segments". A segment can represent any instruction, topological or service based.
セグメントルーティング（SR）[RFC8402]はソースルーティングアーキテクチャです。ノードは、「セグメント」と呼ばれる命令のリストを介してパケットを操縦します。セグメントは、トポロジーまたはサービスベースの任意の指示を表すことができます。
SRv6 applied to mobile networks enables a mobile architecture based on source routing, where operators can explicitly indicate a route for the packets to and from the mobile node. The SRv6 Endpoint nodes serve as mobile user-plane anchors.
モバイルネットワークに適用されるSRV6は、ソースルーティングに基づいてモバイルアーキテクチャを有効にします。ここでは、オペレーターはモバイルノードとの間のパケットのルートを明示的に示すことができます。SRV6エンドポイントノードは、モバイルユーザー平面アンカーとして機能します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
CNF:
CNF：
Cloud-native Network Function
クラウドネイティブネットワーク機能
NFV:
NFV：
Network Function Virtualization
ネットワーク機能仮想化
PDU:
PDU：
Packet Data Unit
パケットデータユニット
PDU Session:
PDUセッション：
Context of a UE connected to a mobile network
モバイルネットワークに接続されたUEのコンテキスト
UE:
UE：
User Equipment
ユーザー機器
gNB:
GNB：
gNodeB [TS.23501]
gnodeb [Ts.23501]
UPF:
UPF：
User Plane Function
ユーザープレーン機能
VNF:
VNF：
Virtual Network Function
仮想ネットワーク機能
DN:
DN：
Data Network
データネットワーク
Uplink:
アップリンク：
from the UE towards the DN
UEからDNに向かいます
Downlink:
ダウンリンク：
from the DN towards the UE
DNからUEに向かいます
The following terms used within this document are defined in [RFC8402]: Segment Routing, SR domain, Segment ID (SID), SRv6, SRv6 SID, Active Segment, SR Policy, and Binding SID (BSID).
このドキュメント内で使用される次の用語は、[RFC8402]で定義されています：セグメントルーティング、SRドメイン、セグメントID（SID）、SRV6、SRV6 SID、アクティブセグメント、SRポリシー、およびバインディングSID（BSID）。
The following terms used within this document are defined in [RFC8754]: Segment Routing Header (SRH) and Reduced SRH.
このドキュメント内で使用される次の用語は、[RFC8754]で定義されています。セグメントルーティングヘッダー（SRH）およびSRHの削減。
The following terms used within this document are defined in [RFC8986]: NH (next header), SL (the Segments Left field of the SRH), FIB (Forwarding Information Base), SA (Source Address), DA (Destination Address), and SRv6 Endpoint Behavior.
このドキュメント内で使用される次の用語は、[RFC8986]で定義されています：NH（次のヘッダー）、SL（SRHの左フィールド）、FIB（転送情報ベース）、SA（ソースアドレス）、DA（宛先アドレス）、DA（宛先アドレス）、およびSRV6エンドポイントの動作。
An SR Policy is resolved to a SID list. A SID list is represented as <S1, S2, S3> where S1 is the first SID to visit, S2 is the second SID to visit, and S3 is the last SID to visit along the SR path.
SRポリシーはSIDリストに解決されます。SIDリストは<S1、S2、S3>として表されます。ここで、S1は訪問する最初のSID、S2は訪問する2番目のSID、S3はSRパスに沿って最後に訪問するSIDです。
(SA,DA) (S3, S2, S1; SL) represents an IPv6 packet where:
（sa、da）（s3、s2、s1; sl）は、ipv6パケットを表します。
* Source Address is SA, Destination Address is DA, and next header is SRH
* ソースアドレスはsa、宛先アドレスはda、次のヘッダーはsrhです
* SRH with SID list <S1, S2, S3> with Segments Left = SL
* SIDリスト<S1、S2、S3>セグメントが残っています= SL
* Note the difference between the <> and () symbols. <S1, S2, S3> represents a SID list where S1 is the first SID and S3 is the last SID to traverse. (S3, S2, S1; SL) represents the same SID list but encoded in the SRH format where the rightmost SID in the SRH is the first SID and the leftmost SID in the SRH is the last SID. When referring to an SR Policy in a high-level use case, it is simpler to use the <S1, S2, S3> notation. When referring to an illustration of the detailed packet behavior, the (S3, S2, S1; SL) notation is more convenient.
* <>と（）シンボルの違いに注意してください。<S1、S2、S3>は、S1が最初のSIDであり、S3がトラバースの最後のSIDであるSIDリストを表します。（S3、S2、S1; SL）は同じSIDリストを表しますが、SRHの右端SIDが最初のSIDであり、SRHの左端のSIDが最後のSIDであるSRH形式でエンコードされています。高レベルのユースケースでSRポリシーを参照する場合、<S1、S2、S3>表記を使用する方が簡単です。詳細なパケット動作のイラストを参照する場合、（S3、S2、S1; SL）表記はより便利です。
* The payload of the packet is omitted.
* パケットのペイロードは省略されています。
(SA1,DA1) (SA2, DA2) represents an IPv6 packet where:
（SA1、DA1）（SA2、DA2）はIPv6パケットを表します。
* Source Address is SA1, Destination Address is DA1, and next header is IP.
* ソースアドレスはSA1、宛先アドレスはDA1、次のヘッダーはIPです。
* Source Address is SA2, and Destination Address is DA2.
* ソースアドレスはSA2で、宛先アドレスはDA2です。
Throughout the document, the representation SRH[n] is used as a shorter representation of Segment List[n], as defined in [RFC8754].
ドキュメント全体で、[RFC8754]で定義されているように、表現SRH [n]はセグメントリスト[n]のより短い表現として使用されます。
This document uses the following conventions throughout the different examples:
このドキュメントでは、さまざまな例全体で次の規則を使用しています。
* gNB::1 is an IPv6 address (SID) assigned to the gNB.
* GNB :: 1は、GNBに割り当てられたIPv6アドレス（SID）です。
* U1::1 is an IPv6 address (SID) assigned to UPF1.
* U1 :: 1は、UPF1に割り当てられたIPv6アドレス（SID）です。
* U2::1 is an IPv6 address (SID) assigned to UPF2.
* U2 :: 1は、UPF2に割り当てられたIPv6アドレス（SID）です。
* U2:: is the Locator of UPF2.
* U2 ::はUPF2のロケーターです。
The following SRv6 Endpoint Behaviors are used throughout this document. They are defined in [RFC8986].
次のSRV6エンドポイントの動作は、このドキュメント全体で使用されます。それらは[RFC8986]で定義されています。
* End.DT4: Decapsulation and Specific IPv4 Table Lookup
* end.dt4：脱カプセル化と特定のIPv4テーブルルックアップ
* End.DT6: Decapsulation and Specific IPv6 Table Lookup
* end.dt6：脱カプセル化と特定のIPv6テーブルルックアップ
* End.DT46: Decapsulation and Specific IP Table Lookup
* End.DT46：脱カプセル化と特定のIPテーブルの検索
* End.DX4: Decapsulation and IPv4 Cross-Connect
* end.dx4：脱カプセル化とIPv4クロスコネクト
* End.DX6: Decapsulation and IPv6 Cross-Connect
* end.dx6：脱カプセル化とIPv6クロスコネクト
* End.DX2: Decapsulation and L2 Cross-Connect
* end.dx2：脱カプセル化とL2クロスコネクト
* End.T: Endpoint with specific IPv6 Table Lookup
* End.T：特定のIPv6テーブルルックアップを備えたエンドポイント
This document defines new SRv6 Endpoint Behaviors in Section 6.
このドキュメントは、セクション6の新しいSRV6エンドポイントの動作を定義しています。
Mobile networks are becoming more challenging to operate. On one hand, traffic is constantly growing, and latency requirements are tighter; on the other hand, there are new use cases like distributed NFV Infrastructure that are also challenging network operations. On top of this, the number of devices connected is steadily growing, causing scalability problems in mobile entities as the state to maintain keeps increasing.
モバイルネットワークは、動作がより困難になっています。一方では、トラフィックは絶えず増加しており、潜伏期の要件はより厳しくなります。一方、分散NFVインフラストラクチャのような新しいユースケースがあり、ネットワーク操作にも挑戦しています。これに加えて、接続されたデバイスの数は着実に増加しており、状態が維持され続けるにつれて、モバイルエンティティのスケーラビリティの問題を引き起こします。
The current architecture of mobile networks does not take into account the underlying transport. The user plane is rigidly fragmented into radio access, core, and service networks that connected by tunneling according to user-plane roles such as access and anchor nodes. These factors have made it difficult for the operator to optimize and operate the data path.
モバイルネットワークの現在のアーキテクチャは、基礎となる輸送を考慮していません。ユーザープレーンは、アクセスやアンカーノードなどのユーザープレーンの役割に応じてトンネルによって接続されたラジオアクセス、コア、およびサービスネットワークに厳密に断片化されています。これらの要因により、オペレーターがデータパスを最適化および操作することが困難になりました。
In the meantime, applications have shifted to use IPv6, and network operators have started adopting IPv6 as their IP transport. SRv6, the IPv6 data plane instantiation of Segment Routing [RFC8402], integrates both the application data path and the underlying transport layer into a single protocol, allowing operators to optimize the network in a simplified manner and removing forwarding state from the network. It is also suitable for virtualized environments, like VNF/CNF-to-VNF/CNF networking. SRv6 has been deployed in dozens of networks [SRV6-DEPLOY-STAT].
それまでの間、アプリケーションはIPv6を使用するようにシフトし、ネットワークオペレーターはIPv6をIP輸送として採用し始めました。SRV6は、セグメントルーティング[RFC8402]のIPv6データプレーンインスタンス化[RFC8402]で、アプリケーションデータパスと基礎となる輸送層の両方を単一のプロトコルに統合し、オペレーターがネットワークを簡素化し、ネットワークから転送状態を削除できるようにします。また、VNF/CNFからVNF/CNFネットワークなどの仮想化環境にも適しています。SRV6は、多数のネットワーク[SRV6-DEPLOY-STAT]に展開されています。
SRv6 defines the network programming concept [RFC8986]. Applied to mobility, SRv6 can provide the user-plane behaviors needed for mobility management. SRv6 takes advantage of the underlying transport awareness and flexibility together with the ability to also include services to optimize the end-to-end mobile data plane.
SRV6は、ネットワークプログラミングの概念[RFC8986]を定義します。モビリティに適用されるSRV6は、モビリティ管理に必要なユーザープレーンの動作を提供できます。SRV6は、基礎となる輸送の意識と柔軟性を活用し、エンドツーエンドのモバイルデータプレーンを最適化するサービスも含める機能を備えています。
The use cases for SRv6 mobility are discussed in [SRV6-MOB-USECASES], and the architectural benefits are discussed in [SRV6-MOB-ARCH-DISCUSS].
SRV6モビリティのユースケースは[SRV6-MOB-USECASES]で説明されており、建築上の利点は[SRV6-MOB-ARCH-DISCUSS]で説明されています。
This section presents the 3GPP reference architecture and possible deployment scenarios.
このセクションでは、3GPPリファレンスアーキテクチャと展開シナリオの可能性を示します。
Figure 1 shows a reference diagram from the 5G packet core architecture [TS.23501].
図1は、5Gパケットコアアーキテクチャ[Ts.23501]の参照図を示しています。
The user plane described in this document does not depend on any specific architecture. The 5G packet core architecture as shown is based on the 3GPP standards.
このドキュメントで説明されているユーザープレーンは、特定のアーキテクチャに依存しません。示されている5Gパケットコアアーキテクチャは、3GPP標準に基づいています。
+-----+
| AMF |
/+-----+
/ | [N11]
[N2] / +-----+
+------/ | SMF |
/ +-----+
/ / \
/ / \ [N4]
/ / \ ________
/ / \ / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/
Figure 1: 3GPP 5G Reference Architecture
図1：3GPP 5Gリファレンスアーキテクチャ
UE:
UE：
User Equipment
ユーザー機器
gNB:
GNB：
gNodeB with N3 interface towards packet core (and N2 for control plane)
パケットコアに向かってn3インターフェイスを備えたgnodeb（およびコントロールプレーン用のn2）
UPF1:
UPF1：
UPF with Interfaces N3 and N9 (and N4 for control plane)
インターフェイスN3とN9（およびコントロールプレーンのN4）を備えたUPF
UPF2:
UPF2：
UPF with Interfaces N9 and N6 (and N4 for control plane)
インターフェイスN9とN6（およびコントロールプレーンのN4）を備えたUPF
SMF:
SMF：
Session Management Function
セッション管理機能
AMF:
AMF：
Access and Mobility Management Function
アクセスおよびモビリティ管理機能
DN:
DN：
Data Network, e.g., operator services and Internet access
データネットワーク、例えば、オペレーターサービスやインターネットアクセス
This reference diagram does not depict a UPF that is only connected to N9 interfaces, although the mechanisms defined in this document also work in such a case.
この参照図は、N9インターフェイスにのみ接続されているUPFを描写していませんが、このドキュメントで定義されているメカニズムはそのような場合にも機能します。
Each session from a UE gets assigned to a UPF. Sometimes multiple UPFs may be used, providing richer service functions. A UE gets its IPv4 address, or IPv6 prefix, from the DHCP block of its UPF. The UPF advertises that IP address block toward the Internet, ensuring that return traffic is routed to the right UPF.
UEからの各セッションはUPFに割り当てられます。複数のUPFを使用して、より豊富なサービス機能を提供する場合があります。UEは、UPFのDHCPブロックからIPv4アドレス（IPv6プレフィックス）を取得します。UPFは、IPアドレスがインターネットに向かってブロックされることを宣伝し、リターントラフィックが適切なUPFにルーティングされるようにします。
This section introduces an SRv6-based mobile user plane. It presents two different "modes" that vary with respect to the use of SRv6.
このセクションでは、SRV6ベースのモバイルユーザープレーンを紹介します。SRV6の使用に関して異なる2つの異なる「モード」を提示します。
The first mode is the "Traditional mode", which inherits the current 3GPP mobile architecture. In this mode, the GTP-U protocol [TS.29281] is replaced by SRv6. However, the N3, N9, and N6 interfaces are still point-to-point interfaces with no intermediate waypoints as in the current mobile network architecture.
最初のモードは、現在の3GPPモバイルアーキテクチャを継承する「従来モード」です。このモードでは、GTP-Uプロトコル[Ts.29281]がSRV6に置き換えられます。ただし、N3、N9、およびN6インターフェイスは、現在のモバイルネットワークアーキテクチャのように中間ウェイポイントがないポイントツーポイントインターフェイスです。
The second mode is the "Enhanced mode". This is an evolution from the "Traditional mode". In this mode, the N3, N9, or N6 interfaces have intermediate waypoints (SIDs) that are used for traffic engineering or VNF purposes transparent to 3GPP functionalities. This results in optimal end-to-end policies across the mobile network with transport and services awareness.
2番目のモードは「拡張モード」です。これは「従来のモード」からの進化です。このモードでは、N3、N9、またはN6インターフェイスには、トラフィックエンジニアリングまたはVNFの目的で3GPP機能に透明に使用される中間ウェイポイント（SID）があります。これにより、トランスポートとサービスの認識により、モバイルネットワーク全体で最適なエンドツーエンドポリシーが生じます。
In both the Traditional and the Enhanced modes, this document assumes that the gNB as well as the UPFs are SR-aware (N3, N9, and potentially N6 interfaces are SRv6).
従来のモードと強化されたモードの両方で、このドキュメントは、GNBとUPFSがSRアウェア（N3、N9、および潜在的にN6インターフェイスがSRV6）であることを前提としています。
In addition to those two modes, this document introduces three mechanisms for interworking with legacy access networks (those where the N3 interface is unmodified). In this document, they are introduced as a variant to the Enhanced mode, but they are equally applicable to the Traditional mode.
これらの2つのモードに加えて、このドキュメントでは、レガシーアクセスネットワーク（N3インターフェイスが変更されていない場合）とのインターワーキングのための3つのメカニズムを紹介します。このドキュメントでは、それらは拡張モードのバリアントとして紹介されていますが、従来のモードに等しく適用できます。
One of these mechanisms is designed to interwork with legacy gNBs using GTP-U/IPv4. The second mechanism is designed to interwork with legacy gNBs using GTP-U/IPv6. The third mechanism is another mode that allows deploying SRv6 when legacy gNBs and UPFs still run GTP-U.
これらのメカニズムの1つは、GTP-U/IPv4を使用してレガシーGNBと対話するように設計されています。2番目のメカニズムは、GTP-U/IPv6を使用してレガシーGNBと対話するように設計されています。3番目のメカニズムは、レガシーGNBとUPFSがGTP-Uを実行するときにSRV6を展開できる別のモードです。
This document uses the SRv6 Endpoint Behaviors defined in [RFC8986] as well as the new SRv6 Endpoint Behaviors designed for the mobile user plane that are defined in Section 6 of this document.
このドキュメントでは、[RFC8986]で定義されているSRV6エンドポイント動作と、このドキュメントのセクション6で定義されているモバイルユーザープレーン向けに設計された新しいSRV6エンドポイント動作を使用します。
In the Traditional mode, the existing mobile UPFs remain unchanged with the sole exception of the use of SRv6 as the data plane instead of GTP-U. There is no impact to the rest of the mobile system.
従来のモードでは、既存のモバイルUPFは、GTP-Uの代わりにSRV6をデータプレーンとして使用することの唯一の除外を除き、変化しません。他のモバイルシステムに影響はありません。
In existing 3GPP mobile networks, a PDU Session is mapped 1-for-1 with a specific GTP-U tunnel (Tunnel Endpoint Identifier (TEID)). This 1-for-1 mapping is mirrored here to replace GTP-U encapsulation with the SRv6 encapsulation, while not changing anything else. There will be a unique SRv6 SID associated with each PDU Session, and the SID list only contains a single SID.
既存の3GPPモバイルネットワークでは、PDUセッションが特定のGTP-Uトンネル（トンネルエンドポイント識別子（TEID））を備えた1対1でマッピングされます。この1対1マッピングは、GTP-Uカプセル化をSRV6カプセル化に置き換えるためにここでミラーリングされていますが、他には何も変更しません。各PDUセッションに関連付けられた一意のSRV6 SIDがあり、SIDリストには単一のSIDのみが含まれています。
The Traditional mode minimizes the required changes to the mobile system; hence, it is a good starting point for forming common ground.
従来のモードは、モバイルシステムへの必要な変更を最小限に抑えます。したがって、それは共通の基盤を形成するための良い出発点です。
The gNB/UPF control plane (N2/N4 interface) is unchanged; specifically, a single IPv6 address is provided to the gNB. The same control plane signaling is used, and the gNB/UPF decides to use SRv6 based on signaled GTP-U parameters per local policy. The only information from the GTP-U parameters used for the SRv6 policy is the TEID, QFI (QoS Flow Identifier), and the IPv6 Destination Address.
GNB/UPFコントロールプレーン（N2/N4インターフェイス）は変更されていません。具体的には、GNBに単一のIPv6アドレスが提供されます。同じコントロールプレーンシグナル伝達が使用され、GNB/UPFは、ローカルポリシーごとにシグナル付きGTP-Uパラメーターに基づいてSRV6を使用することを決定します。SRV6ポリシーに使用されるGTP-Uパラメーターの唯一の情報は、TEID、QFI（QOSフロー識別子）、およびIPv6宛先アドレスです。
Our example topology is shown in Figure 2. The gNB and the UPFs are SR-aware. In the descriptions of the uplink and downlink packet flow, A is an IPv6 address of the UE, and Z is an IPv6 address reachable within the DN. End.MAP, a new SRv6 Endpoint Behavior defined in Section 6.2, is used.
私たちのトポロジの例を図2に示します。GNBとUPFSはSR-Awareです。アップリンクとダウンリンクパケットフローの説明では、AはUEのIPv6アドレスであり、ZはDN内で到達可能なIPv6アドレスです。セクション6.2で定義された新しいSRV6エンドポイントの動作であるEnd.Mapが使用されます。
________
SRv6 SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| UPF1 |--------| UPF2 |--------- \ DN /
+--+ +-----+ +------+ +------+ \________/
SRv6 node SRv6 node SRv6 node
Figure 2: Traditional Mode - Example Topology
図2：従来のモード - トポロジの例
The uplink packet flow is as follows:
アップリンクパケットフローは次のとおりです。
UE_out : (A,Z)
gNB_out : (gNB, U1::1) (A,Z) -> H.Encaps.Red <U1::1>
UPF1_out: (gNB, U2::1) (A,Z) -> End.MAP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
When the UE packet arrives at the gNB, the gNB performs an H.Encaps.Red operation. Since there is only one SID, there is no need to push an SRH (reduced SRH). gNB only adds an outer IPv6 header with IPv6 DA U1::1. gNB obtains the SID U1::1 from the existing control plane (N2 interface). U1::1 represents an anchoring SID specific for that session at UPF1.
UEパケットがGNBに到着すると、GNBはh.encaps.red操作を実行します。SIDは1つしかないため、SRH（SRHの減少）をプッシュする必要はありません。GNBは、IPv6 DA U1 :: 1を使用して外側のIPv6ヘッダーのみを追加します。GNBは、既存のコントロールプレーン（N2インターフェイス）からSID U1 :: 1を取得します。U1 :: 1は、UPF1でのそのセッションに固有のアンカーSIDを表します。
When the packet arrives at UPF1, the SID U1::1 is associated with the End.MAP SRv6 Endpoint Behavior. End.MAP replaces U1::1 with U2::1, which belongs to the next UPF (U2).
パケットがUPF1に到着すると、SID U1 :: 1はend.map SRV6エンドポイントの動作に関連付けられています。End.mapは、U1 :: 1をU2 :: 1に置き換えます。U2:: 1は次のUPF（U2）に属します。
When the packet arrives at UPF2, the SID U2::1 corresponds to an End.DT4/End.DT6/End.DT46 SRv6 Endpoint Behavior. UPF2 decapsulates the packet, performs a lookup in a specific table associated with that mobile network, and forwards the packet toward the DN.
パケットがUPF2に到着すると、SID U2 :: 1はend.dt4/end.dt6/end.dt46 srv6エンドポイントの動作に対応します。UPF2はパケットを脱カプセル化し、そのモバイルネットワークに関連付けられた特定のテーブルのルックアップを実行し、パケットをDNに転送します。
The downlink packet flow is as follows:
ダウンリンクパケットフローは次のとおりです。
UPF2_in : (Z,A)
UPF2_out: (U2::, U1::2) (Z,A) -> H.Encaps.Red <U1::2>
UPF1_out: (U2::, gNB::1) (Z,A) -> End.MAP
gNB_out : (Z,A) -> End.DX4, End.DX6, End.DX2
When the packet arrives at the UPF2, the UPF2 maps that flow into a PDU Session. This PDU Session is associated with the segment endpoint <U1::2>. UPF2 performs an H.Encaps.Red operation, encapsulating the packet into a new IPv6 header with no SRH since there is only one SID.
パケットがUPF2に到着すると、UPF2はPDUセッションに流れ込むマップをマップします。このPDUセッションは、セグメントエンドポイント<U1 :: 2>に関連付けられています。UPF2はH.ENCAPS.RED操作を実行し、SIDが1つしかないため、SRHのない新しいIPv6ヘッダーにパケットをカプセル化します。
Upon packet arrival on UPF1, the SID U1::2 is a local SID associated with the End.MAP SRv6 Endpoint Behavior. It maps the SID to the next anchoring point and replaces U1::2 with gNB::1, which belongs to the next hop.
UPF1にパケット到着すると、SID U1 :: 2はEnd.map SRV6エンドポイントの動作に関連するローカルSIDです。SIDを次のアンカーポイントにマッピングし、U1 :: 2を次のホップに属するGNB :: 1に置き換えます。
Upon packet arrival on gNB, the SID gNB::1 corresponds to an End.DX4, End.DX6, or End.DX2 behavior (depending on the PDU Session Type). The gNB decapsulates the packet, removing the IPv6 header and all its extensions headers, and forwards the traffic toward the UE.
GNBにパケット到着すると、SID GNB :: 1はend.dx4、end.dx6、またはend.dx2の動作に対応します（PDUセッションタイプによって異なります）。GNBはパケットを脱カプセル化し、IPv6ヘッダーとそのすべての拡張ヘッダーを削除し、トラフィックをUEに向けます。
Enhanced mode improves scalability, provides traffic engineering capabilities, and allows service programming [SR-SERV-PROG], thanks to the use of multiple SIDs in the SID list (instead of a direct connectivity in between UPFs with no intermediate waypoints as in Traditional mode).
拡張モードはスケーラビリティを向上させ、トラフィックエンジニアリング機能を提供し、SIDリストで複数のSIDを使用したことのおかげで（従来のモードのように中間ウェイポイントのないUPFの間の直接接続の代わりに、サービスプログラミング[SR-Serv-Prog]を許可します。）。
Thus, the main difference is that the SR Policy MAY include SIDs for traffic engineering and service programming in addition to the anchoring SIDs at UPFs.
したがって、主な違いは、SRポリシーには、UPFSでのアンカーSIDに加えて、トラフィックエンジニアリングとサービスプログラミングのSIDSが含まれる可能性があることです。
Additionally, in this mode, the operator may choose to aggregate several devices under the same SID list (e.g., stationary residential meters (water and energy) connected to the same cell) to improve scalability.
さらに、このモードでは、オペレーターは、同じSIDリスト（たとえば、同じセルに接続された静止住宅メーター（水とエネルギー））の下にいくつかのデバイスを集約することを選択できます。
The gNB/UPF control plane (N2/N4 interface) is unchanged; specifically, a single IPv6 address is provided to the gNB. A local policy instructs the gNB to use SRv6.
GNB/UPFコントロールプレーン（N2/N4インターフェイス）は変更されていません。具体的には、GNBに単一のIPv6アドレスが提供されます。ローカルポリシーは、GNBにSRV6を使用するよう指示します。
The gNB resolves the IP address received via the control plane into a SID list. The resolution mechanism is out of the scope of this document.
GNBは、コントロールプレーンを介して受信したIPアドレスをSIDリストに解決します。解像度メカニズムは、このドキュメントの範囲外です。
Note that the SIDs MAY use the argument Args.Mob.Session (Section 6.1) if required by the UPFs.
SIDSは、UPFSで要求されている場合、引数args.mob.session（セクション6.1）を使用する場合があることに注意してください。
Figure 3 shows an Enhanced mode topology. The gNB and the UPF are SR-aware. The figure shows two service segments, S1 and C1. S1 represents a VNF in the network, and C1 represents an intermediate router used for traffic engineering purposes to enforce a low-latency path in the network. Note that neither S1 nor C1 are required to have an N4 interface.
図3は、強化されたモードトポロジを示しています。GNBとUPFはSR-Awareです。この図は、2つのサービスセグメント、S1とC1を示しています。S1はネットワーク内のVNFを表し、C1はトラフィックエンジニアリングの目的で使用される中間ルーターを表し、ネットワーク内の低遅延パスを実施します。S1もC1もN4インターフェイスを持つ必要はないことに注意してください。
+----+ SRv6 _______
SRv6 --| C1 |--[N3] / \
+--+ +-----+ [N3] / +----+ \ +------+ [N6] / \
|UE|----| gNB |-- SRv6 / SRv6 --| UPF1 |------\ DN /
+--+ +-----+ \ [N3]/ TE +------+ \_______/
SRv6 node \ +----+ / SRv6 node
-| S1 |-
+----+
SRv6 node
VNF
Figure 3: Enhanced Mode - Example Topology
図3：強化されたモード - トポロジの例
The uplink packet flow is as follows:
アップリンクパケットフローは次のとおりです。
UE_out : (A,Z)
gNB_out : (gNB, S1)(U1::1, C1; SL=2)(A,Z)->H.Encaps.Red<S1,C1,U1::1>
S1_out : (gNB, C1)(U1::1, C1; SL=1)(A,Z)
C1_out : (gNB, U1::1)(A,Z) ->End with PSP
UPF1_out: (A,Z) ->End.DT4,End.DT6,End.DT2U
UE sends its packet (A,Z) on a specific bearer to its gNB. gNB's control plane associates that session from the UE(A) with the IPv6 address B. gNB resolves B into a SID list <S1, C1, U1::1>.
UEは、特定のベアラーにパケット（A、Z）をGNBに送信します。GNBのコントロールプレーンは、UE（a）からのセッションをIPv6アドレスBに関連付けます。GNBはBをSIDリスト<S1、C1、U1 :: 1>に解決します。
When gNB transmits the packet, it contains all the segments of the SR Policy. The SR Policy includes segments for traffic engineering (C1) and for service programming (S1).
GNBがパケットを送信すると、SRポリシーのすべてのセグメントが含まれます。SRポリシーには、トラフィックエンジニアリング（C1）およびサービスプログラミング（S1）のセグメントが含まれています。
Nodes S1 and C1 perform their related Endpoint functionality and forward the packet. The "End with PSP" functionality refers to the Endpoint Behavior with Penultimate Segment Popping as defined in [RFC8986].
ノードS1とC1は、関連するエンドポイント機能を実行し、パケットを転送します。[PSPでエンド]機能性は、[RFC8986]で定義されているように、ペナグリテーションセグメントがポップするエンドポイントの動作を指します。
When the packet arrives at UPF1, the active segment (U1::1) is an End.DT4/End.DT6/End.DT2U, which performs the decapsulation (removing the IPv6 header with all its extension headers) and forwards toward the DN.
パケットがUPF1に到着すると、アクティブセグメント（U1 :: 1）はend.dt4/end.dt6/end.dt2uです。これは、脱カプセル化を実行します（すべての拡張ヘッダーでIPv6ヘッダーを削除）、dnに向かって転送します。
The downlink packet flow is as follows:
ダウンリンクパケットフローは次のとおりです。
UPF1_in : (Z,A) ->UPF1 maps the flow w/
SID list <C1,S1, gNB>
UPF1_out: (U1::1, C1)(gNB::1, S1; SL=2)(Z,A)->H.Encaps.Red
C1_out : (U1::1, S1)(gNB::1, S1; SL=1)(Z,A)
S1_out : (U1::1, gNB::1)(Z,A) ->End with PSP
gNB_out : (Z,A) ->End.DX4/End.DX6/End.DX2
When the packet arrives at the UPF1, the UPF1 maps that particular flow into a UE PDU Session. This UE PDU Session is associated with the policy <C1, S1, gNB>. The UPF1 performs a H.Encaps.Red operation, encapsulating the packet into a new IPv6 header with its corresponding SRH.
パケットがUPF1に到着すると、UPF1は特定のFlowがUE PDUセッションに流れ込みます。このUE PDUセッションは、ポリシー<C1、S1、GNB>に関連付けられています。UPF1はH.Encaps.RED操作を実行し、対応するSRHを使用してパケットを新しいIPv6ヘッダーにカプセル化します。
The nodes C1 and S1 perform their related Endpoint processing.
ノードC1とS1は、関連するエンドポイント処理を実行します。
Once the packet arrives at the gNB, the IPv6 DA corresponds to an End.DX4, End.DX6, or End.DX2 behavior at the gNB (depending on the underlying traffic). The gNB decapsulates the packet, removing the IPv6 header, and forwards the traffic towards the UE. The SID gNB::1 is one example of a SID associated to this service.
パケットがGNBに到着すると、IPv6 DAはGNBでのend.dx4、end.dx6、またはend.dx2の動作に対応します（基礎となるトラフィックに応じて）。GNBはパケットを脱カプセル化し、IPv6ヘッダーを削除し、トラフィックをUEに向けます。SID GNB :: 1は、このサービスに関連付けられたSIDの一例です。
Note that there are several means to provide the UE session aggregation. The decision about which one to use is a local decision made by the operator. One option is to use Args.Mob.Session (Section 6.1). Another option comprises the gNB performing an IP lookup on the inner packet by using the End.DT4, End.DT6, and End.DT2U behaviors.
UEセッションの集約を提供する手段がいくつかあることに注意してください。どちらを使用するかについての決定は、オペレーターによるローカルの決定です。1つのオプションは、args.mob.session（セクション6.1）を使用することです。別のオプションは、end.dt4、end.dt6、およびend.dt2uの動作を使用して、内側のパケットでIPルックアップを実行するGNBで構成されています。
The Enhanced mode improves scalability since it allows the aggregation of several UEs under the same SID list. For example, in the case of stationary residential meters that are connected to the same cell, all such devices can share the same SID list. This improves scalability compared to Traditional mode (unique SID per UE) and compared to GTP-U (TEID per UE).
強化されたモードは、同じSIDリストの下にいくつかのUEの集約を可能にするため、スケーラビリティを向上させます。たとえば、同じセルに接続されている固定住宅メーターの場合、そのようなデバイスはすべて同じSIDリストを共有できます。これにより、従来のモード（UEごとの一意のSID）と比較して、GTP-U（UEごとのTEID）と比較してスケーラビリティが向上します。
This section describes two mechanisms for interworking with legacy gNBs that still use GTP-U: one for IPv4 and another for IPv6.
このセクションでは、GTP-Uを使用しているレガシーGNBとの相互作用のための2つのメカニズムについて説明します。1つはIPv4用、もう1つはIPv6用です。
In the interworking scenarios illustrated in Figure 4, the gNB does not support SRv6. The gNB supports GTP-U encapsulation over IPv4 or IPv6. To achieve interworking, an SR Gateway (SRGW) entity is added. The SRGW is a new entity that maps the GTP-U traffic into SRv6. It is deployed at the boundary of the SR domain and performs the mapping functionality for inbound and outbound traffic.
図4に示されているインターワーキングシナリオでは、GNBはSRV6をサポートしていません。GNBは、IPv4またはIPv6を介したGTP-Uカプセル化をサポートしています。インターワーキングを実現するために、SRゲートウェイ（SRGW）エンティティが追加されます。SRGWは、GTP-UトラフィックをSRV6にマッピングする新しいエンティティです。SRドメインの境界に展開され、インバウンドトラフィックとアウトバウンドトラフィックのマッピング機能を実行します。
The SRGW is not an anchor point and maintains very little state. For this reason, both IPv4 and IPv6 methods scale to millions of UEs.
SRGWはアンカーポイントではなく、ほとんど状態を維持していません。このため、IPv4メソッドとIPv6メソッドの両方が数百万のUEにスケーリングされています。
_______
IP GTP-U SRv6 / \
+--+ +-----+ [N3] +------+ [N9] +------+ [N6] / \
|UE|------| gNB |------| SRGW |--------| UPF |---------\ DN /
+--+ +-----+ +------+ +------+ \_______/
SR Gateway SRv6 node
Figure 4: Example Topology for Interworking
図4：インターワーキングのトポロジの例
Both of the mechanisms described in this section are applicable to the Traditional mode and the Enhanced mode.
このセクションで説明するメカニズムは両方とも、従来のモードと拡張モードに適用できます。
In this interworking mode, the gNB at the N3 interface uses GTP-U over IPv6.
このインターワーキングモードでは、N3インターフェイスのGNBはIPv6を介してGTP-Uを使用します。
Key points:
キーポイント：
* The gNB is unchanged (control plane or user plane) and encapsulates into GTP-U (N3 interface is not modified).
* GNBは変更されておらず（コントロールプレーンまたはユーザープレーン）、GTP-Uにカプセル化します（N3インターフェイスは変更されていません）。
* The 5G control plane towards the gNB (N2 interface) is unmodified, though multiple UPF addresses need to be used. One IPv6 address (i.e., a BSID at the SRGW) is needed per <SLA, PDU Session Type>. The SRv6 SID is different depending on the required <SLA, PDU Session Type> combination.
* GNB（N2インターフェイス）に向かう5Gコントロールプレーンは変更されていませんが、複数のUPFアドレスを使用する必要があります。1つのIPv6アドレス（つまり、SRGWのBSID）が必要です<SLA、PDUセッションタイプ>。SRV6 SIDは、必要な<SLA、PDUセッションタイプ>組み合わせによって異なります。
* In the uplink, the SRGW removes the GTP-U header, finds the SID list related to the IPv6 DA, and adds SRH with the SID list.
* アップリンクでは、SRGWはGTP-Uヘッダーを削除し、IPv6 DAに関連するSIDリストを見つけ、SIDリストにSRHを追加します。
* There is no state for the downlink at the SRGW.
* SRGWのダウンリンクの状態はありません。
* There is simple state in the uplink at the SRGW; using Enhanced mode results in fewer SR Policies on this node. An SR Policy is shared across UEs as long as they belong to the same context (i.e., tenant). A set of many different policies (i.e., different SLAs) increases the amount of state required.
* SRGWのアップリンクには単純な状態があります。拡張モードを使用すると、このノードでのSRポリシーが少なくなります。SRポリシーは、同じコンテキスト（つまり、テナント）に属している限り、UES間で共有されます。さまざまなポリシーのセット（つまり、異なるSLA）は、必要な状態の量を増加させます。
* When a packet from the UE leaves the gNB, it is SR-routed. This simplifies network slicing [RFC9350].
* UEからのパケットがGNBを離れると、SRルーティングが行われます。これにより、ネットワークスライシング[RFC9350]が簡素化されます。
* In the uplink, the SRv6 BSID steers traffic into an SR Policy when it arrives at the SRGW.
* アップリンクでは、SRV6 BSIDはSRGWに到着したときにトラフィックをSRポリシーに導きます。
An example topology is shown in Figure 5.
トポロジの例を図5に示します。
S1 and C1 are two service segments. S1 represents a VNF in the network, and C1 represents a router configured for traffic engineering.
S1とC1は2つのサービスセグメントです。S1はネットワーク内のVNFを表し、C1はトラフィックエンジニアリング用に構成されたルーターを表します。
+----+
IPv6/GTP-U -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP-U \ +------+ / +----+ +------+ \___
-| SRGW |- SRv6 SRv6
+------+ TE
SR Gateway
Figure 5: Enhanced Mode with Unchanged gNB IPv6/GTP-U Behavior
図5：変更されていないGNB IPv6/GTP-Uの動作による強化モード
The uplink packet flow is as follows:
アップリンクパケットフローは次のとおりです。
UE_out : (A,Z)
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3 unmodified
(IPv6/GTP)
SRGW_out: (SRGW, S1)(U2::T, C1; SL=2)(A,Z) -> B is an End.M.GTP6.D
SID at the SRGW
S1_out : (SRGW, C1)(U2::T, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::T)(A,Z) -> End with PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific bearer for that session. The gNB, which is unmodified, encapsulates the packet into IPv6, UDP, and GTP-U headers. The IPv6 DA B and the GTP-U TEID T are the ones received in the N2 interface.
UEは、そのセッションのために特定のベアラーでGNBに向かってzを運営するパケットを送信します。変更されていないGNBは、パケットをIPv6、UDP、およびGTP-Uヘッダーにカプセル化します。IPv6 Da BとGTP-U TEID Tは、N2インターフェイスで受信されたものです。
The IPv6 address that was signaled over the N2 interface for that UE PDU Session, B, is now the IPv6 DA. B is an SRv6 Binding SID at the SRGW. Hence, the packet is routed to the SRGW.
そのUE PDUセッションBが現在IPv6 DAになっているため、N2インターフェイスで信号を送られたIPv6アドレスがIPv6 Daになりました。Bは、SRGWのSRV6結合SIDです。したがって、パケットはSRGWにルーティングされます。
When the packet arrives at the SRGW, the SRGW identifies B as an End.M.GTP6.D Binding SID (see Section 6.3). Hence, the SRGW removes the IPv6, UDP, and GTP-U headers and pushes an IPv6 header with its own SRH containing the SIDs bound to the SR Policy associated with this Binding SID. There is at least one instance of the End.M.GTP6.D SID per PDU type.
パケットがSRGWに到着すると、SRGWはBをEnd.m.gtp6.dバインディングSIDとして識別します（セクション6.3を参照）。したがって、SRGWはIPv6、UDP、およびGTP-Uヘッダーを削除し、この結合SIDに関連するSRポリシーに結合したSIDを含む独自のSRHを使用してIPv6ヘッダーをプッシュします。PDUタイプごとに、end.m.gtp6.d sidには少なくとも1つのインスタンスがあります。
S1 and C1 perform their related Endpoint functionality and forward the packet.
S1とC1は、関連するエンドポイント機能を実行し、パケットを転送します。
When the packet arrives at UPF2, the active segment is (U2::T), which is bound to End.DT4/6. UPF2 then decapsulates (removing the outer IPv6 header with all its extension headers) and forwards the packet toward the DN.
パケットがUPF2に到着すると、アクティブセグメントは（u2 :: t）であり、end.dt4/6に結合されます。UPF2は、すべての拡張ヘッダーで外側のIPv6ヘッダーを削除します）を脱カプセル化し、パケットをDNに向かって転送します。
The downlink packet flow is as follows:
ダウンリンクパケットフローは次のとおりです。
UPF2_in : (Z,A) -> UPF2 maps the flow with
<C1, S1, SRGW::TEID,gNB>
UPF2_out: (U2::1, C1)(gNB, SRGW::TEID, S1; SL=3)(Z,A) -> H.Encaps.Red
C1_out : (U2::1, S1)(gNB, SRGW::TEID, S1; SL=2)(Z,A)
S1_out : (U2::1, SRGW::TEID)(gNB, SRGW::TEID, S1, SL=1)(Z,A)
SRGW_out: (SRGW, gNB)(GTP: TEID=T)(Z,A) -> SRGW/96 is End.M.GTP6.E
gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a lookup in the table associated to A and finds the SID list <C1, S1, SRGW::TEID, gNB>. The UPF2 performs an H.Encaps.Red operation, encapsulating the packet into a new IPv6 header with its corresponding SRH.
Aに運命づけられたパケットがUPF2に到着すると、UPF2はAに関連付けられたテーブルのルックアップを実行し、SIDリスト<C1、S1、SRGW :: TEID、GNB>を見つけます。UPF2はH.Encaps.RED操作を実行し、対応するSRHを使用してパケットを新しいIPv6ヘッダーにカプセル化します。
C1 and S1 perform their related Endpoint processing.
C1とS1は、関連するエンドポイント処理を実行します。
Once the packet arrives at the SRGW, the SRGW identifies the active SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header and all its extensions headers. The SRGW generates new IPv6, UDP, and GTP-U headers. The new IPv6 DA is the gNB, which is the last SID in the received SRH. The TEID in the generated GTP-U header is also an argument of the received End.M.GTP6.E SID. The SRGW pushes the headers to the packet and forwards the packet toward the gNB. There is one instance of the End.M.GTP6.E SID per PDU type.
パケットがSRGWに到着すると、SRGWはアクティブなSIDをEnd.m.gtp6.e関数として識別します。SRGWは、IPv6ヘッダーとそのすべての拡張ヘッダーを削除します。SRGWは、新しいIPv6、UDP、およびGTP-Uヘッダーを生成します。新しいIPv6 DAはGNBであり、これは受信したSRHの最後のSIDです。生成されたGTP-UヘッダーのTeidは、受信したEnd.m.gtp6.e Sidの引数でもあります。SRGWはヘッダーをパケットに押し込み、パケットをGNBに向けます。end.m.gtp6.e PDUタイプごとに1つのインスタンスがあります。
Once the packet arrives at the gNB, the packet is a regular IPv6/ GTP-U packet. The gNB looks for the specific radio bearer for that TEID and forwards it on the bearer. This gNB behavior is not modified from current and previous generations.
パケットがGNBに到着すると、パケットは通常のIPv6/ GTP-Uパケットになります。GNBは、そのTeidの特定のラジオベアラーを探し、Bearerに転送します。このGNBの動作は、現在および前世代から変更されていません。
For downlink traffic, the SRGW is stateless. All the state is in the SRH pushed by the UPF2. The UPF2 must have the UE state since it is the UE's session anchor point.
ダウンリンクトラフィックの場合、SRGWは無国籍です。すべての状態は、UPF2によってプッシュされたSRHにあります。UPF2は、UEのセッションアンカーポイントであるため、UE状態が必要です。
For uplink traffic, the state at the SRGW does not necessarily need to be unique per PDU Session; the SR Policy can be shared among UEs. This enables more scalable SRGW deployments compared to a solution holding millions of states, one or more per UE.
アップリンクトラフィックの場合、SRGWの州は必ずしもPDUセッションごとに一意である必要はありません。SRポリシーはUES間で共有できます。これにより、数百万の州を保持しているソリューションと比較して、よりスケーラブルなSRGWの展開が可能になります。
In this interworking mode, the gNB uses GTP over IPv4 in the N3 interface.
このインターワーキングモードでは、GNBはN3インターフェイスでIPv4を介してGTPを使用します。
Key points:
キーポイント：
* The gNB is unchanged and encapsulates packets into GTP-U (the N3 interface is not modified).
* GNBは変更されておらず、パケットをGTP-Uにカプセル化します（N3インターフェイスは変更されていません）。
* N2 signaling is not changed, though multiple UPF addresses need to be provided -- one for each PDU Session Type.
* N2シグナリングは変更されませんが、複数のUPFアドレスを提供する必要があります。1つはPDUセッションタイプごとに1つです。
* In the uplink, traffic is classified by SRGW's classification engine and steered into an SR Policy. The SRGW may be implemented in a UPF or as a separate entity. How the classification engine rules are set up is outside the scope of this document, though one example is using BGP signaling from a Mobile User Plane (MUP) Controller [MUP-SR-ARCH].
* アップリンクでは、トラフィックはSRGWの分類エンジンによって分類され、SRポリシーに進みます。SRGWは、UPFまたは別のエンティティとして実装できます。分類エンジンのルールの設定方法は、このドキュメントの範囲外ですが、1つの例はモバイルユーザープレーン（MUP）コントローラー[MUP-SR-ARCH]からのBGPシグナリングを使用しています。
* SRGW removes the GTP-U header, finds the SID list related to DA, and adds an SRH with the SID list.
* SRGWはGTP-Uヘッダーを削除し、DAに関連するSIDリストを見つけ、SIDリストにSRHを追加します。
An example topology is shown in Figure 6. In this mode, the gNB is an unmodified gNB using IPv4/GTP. The UPFs are SR-aware. As before, the SRGW maps the IPv4/GTP-U traffic to SRv6.
図6にトポロジの例を示します。このモードでは、GNBはIPv4/GTPを使用した変更されていないGNBです。UPFはSR-Awareです。前と同様に、SRGWはIPv4/GTP-UトラフィックをSRV6にマッピングします。
S1 and C1 are two service segment endpoints. S1 represents a VNF in the network, and C1 represents a router configured for traffic engineering.
S1とC1は2つのサービスセグメントエンドポイントです。S1はネットワーク内のVNFを表し、C1はトラフィックエンジニアリング用に構成されたルーターを表します。
+----+
IPv4/GTP-U -| S1 |- ___
+--+ +-----+ [N3] / +----+ \ /
|UE|--| gNB |- SRv6 / SRv6 \ +----+ +------+ [N6] /
+--+ +-----+ \ [N9]/ VNF -| C1 |---| UPF2 |------\ DN
GTP-U \ +------+ / +----+ +------+ \___
-| UPF1 |- SRv6 SRv6
+------+ TE
SR Gateway
Figure 6: Enhanced Mode with Unchanged gNB IPv4/GTP-U Behavior
図6：変更されていないGNB IPv4/GTP-Uの動作による強化モード
The uplink packet flow is as follows:
アップリンクパケットフローは次のとおりです。
gNB_out : (gNB, B)(GTP: TEID T)(A,Z) -> Interface N3
unchanged IPv4/GTP
SRGW_out: (SRGW, S1)(U2::1, C1; SL=2)(A,Z) -> H.M.GTP4.D function
S1_out : (SRGW, C1)(U2::1, C1; SL=1)(A,Z)
C1_out : (SRGW, U2::1) (A,Z) -> PSP
UPF2_out: (A,Z) -> End.DT4 or End.DT6
The UE sends a packet destined to Z toward the gNB on a specific bearer for that session. The gNB, which is unmodified, encapsulates the packet into a new IPv4, UDP, and GTP-U headers. The IPv4 DA, B, and the GTP-UTEID are the ones received at the N2 interface.
UEは、そのセッションのために特定のベアラーでGNBに向かってzを運営するパケットを送信します。変更されていないGNBは、パケットを新しいIPv4、UDP、およびGTP-Uヘッダーにカプセル化します。IPv4 DA、B、およびGTP-UteIDは、N2インターフェイスで受信されたものです。
When the packet arrives at the SRGW for UPF1, the SRGW has a classification engine rule for incoming traffic from the gNB that steers the traffic into an SR Policy by using the function H.M.GTP4.D. The SRGW removes the IPv4, UDP, and GTP headers and pushes an IPv6 header with its own SRH containing the SIDs related to the SR Policy associated with this traffic. The SRGW forwards according to the new IPv6 DA.
PacketがUPF1のSRGWに到着すると、SRGWには、関数H.M.GTP4.D.SRGWは、IPv4、UDP、およびGTPヘッダーを削除し、このトラフィックに関連するSRポリシーに関連するSIDSを含む独自のSRHを使用してIPv6ヘッダーをプッシュします。SRGWは、新しいIPv6 DAに従って転送されます。
S1 and C1 perform their related Endpoint functionality and forward the packet.
S1とC1は、関連するエンドポイント機能を実行し、パケットを転送します。
When the packet arrives at UPF2, the active segment is (U2::1), which is bound to End.DT4/6, which performs the decapsulation (removing the outer IPv6 header with all its extension headers) and forwards toward the DN.
パケットがUPF2に到着すると、アクティブセグメントは（U2 :: 1）であり、end.dt4/6にバインドされており、脱カプセル化（すべての拡張ヘッダーで外側のIPv6ヘッダーを除去）を実行し、DNに向かって転送します。
Note that the interworking mechanisms for IPv4/GTP-U and IPv6/GTP-U differ. This is due to the fact that IPv6/GTP-U can leverage the remote steering capabilities provided by the Segment Routing BSID. In IPv4, this construct is not available, and building a similar mechanism would require a significant address consumption.
IPv4/GTP-UおよびIPv6/GTP-Uのインターワーキングメカニズムは異なることに注意してください。これは、IPv6/GTP-UがBSIDをルーティングするセグメントによって提供されるリモートステアリング機能を活用できるという事実によるものです。IPv4では、このコンストラクトは利用できず、同様のメカニズムを構築するには大きな住所消費が必要です。
The downlink packet flow is as follows:
ダウンリンクパケットフローは次のとおりです。
UPF2_in : (Z,A) -> UPF2 maps flow with SID
<C1, S1,GW::SA:DA:TEID>
UPF2_out: (U2::1, C1)(GW::SA:DA:TEID, S1; SL=2)(Z,A) ->H.Encaps.Red
C1_out : (U2::1, S1)(GW::SA:DA:TEID, S1; SL=1)(Z,A)
S1_out : (U2::1, GW::SA:DA:TEID)(Z,A)
SRGW_out: (GW, gNB)(GTP: TEID=T)(Z,A) -> End.M.GTP4.E
gNB_out : (Z,A)
When a packet destined to A arrives at the UPF2, the UPF2 performs a lookup in the table associated to A and finds the SID list <C1, S1, SRGW::SA:DA:TEID>. The UPF2 performs an H.Encaps.Red operation, encapsulating the packet into a new IPv6 header with its corresponding SRH.
Aに運命づけられたパケットがUPF2に到着すると、UPF2はAに関連付けられたテーブルのルックアップを実行し、SIDリスト<C1、S1、SRGW :: SA：DA：TEID>を見つけます。UPF2はH.Encaps.RED操作を実行し、対応するSRHを使用してパケットを新しいIPv6ヘッダーにカプセル化します。
The nodes C1 and S1 perform their related Endpoint processing.
ノードC1とS1は、関連するエンドポイント処理を実行します。
Once the packet arrives at the SRGW, the SRGW identifies the active SID as an End.M.GTP4.E function. The SRGW removes the IPv6 header and all its extensions headers. The SRGW generates IPv4, UDP, and GTP-U headers. The IPv4 SA and DA are received as SID arguments. The TEID in the generated GTP-U header is the argument of the received End.M.GTP4.E SID. The SRGW pushes the headers to the packet and forwards the packet toward the gNB.
パケットがSRGWに到着すると、SRGWはアクティブなSIDをend.m.gtp4.e関数として識別します。SRGWは、IPv6ヘッダーとそのすべての拡張ヘッダーを削除します。SRGWは、IPv4、UDP、およびGTP-Uヘッダーを生成します。IPv4 SAとDAは、SIDの引数として受信されます。生成されたGTP-UヘッダーのTEIDは、受信したend.m.gtp4.e sidの引数です。SRGWはヘッダーをパケットに押し込み、パケットをGNBに向けます。
When the packet arrives at the gNB, the packet is a regular IPv4/ GTP-U packet. The gNB looks for the specific radio bearer for that TEID and forwards it on the bearer. This gNB behavior is not modified from current and previous generations.
パケットがGNBに到着すると、パケットは通常のIPv4/ GTP-Uパケットです。GNBは、そのTeidの特定のラジオベアラーを探し、Bearerに転送します。このGNBの動作は、現在および前世代から変更されていません。
For downlink traffic, the SRGW is stateless. All the state is in the SRH pushed by the UPF2. The UPF must have this UE-base state anyway (since it is its anchor point).
ダウンリンクトラフィックの場合、SRGWは無国籍です。すべての状態は、UPF2によってプッシュされたSRHにあります。とにかくUPFには、このUEベース状態が必要です（アンカーポイントであるため）。
For uplink traffic, the state at the SRGW is dedicated on a per-UE/ session basis according to a classification engine. There is state for steering the different sessions in the form of an SR Policy. However, SR Policies are shared among several UE/sessions.
アップリンクトラフィックの場合、SRGWの状態は、分類エンジンに応じて、UUE/セッションごとに捧げられています。さまざまなセッションをSRポリシーの形で操縦する状態があります。ただし、SRポリシーはいくつかのUE/セッションの間で共有されています。
This section presents two mechanisms for interworking with gNBs and UPFs that do not support SRv6. These mechanisms are used to support GTP-U over IPv4 and IPv6.
このセクションでは、SRV6をサポートしていないGNBとUPFSとの相互作用のための2つのメカニズムを紹介します。これらのメカニズムは、IPv4およびIPv6を超えるGTP-Uをサポートするために使用されます。
Even though these methods are presented as an extension to the Enhanced mode, they are also applicable to the Traditional mode.
これらのメソッドは拡張モードの拡張として表示されますが、従来のモードにも適用できます。
This section introduces another mode useful for legacy gNB and UPFs that still operate with GTP-U. This mode provides an SRv6-enabled user plane in between two GTP-U tunnel endpoints.
このセクションでは、GTP-Uで動作しているレガシーGNBとUPFSに役立つ別のモードを紹介します。このモードは、2つのGTP-Uトンネルエンドポイントの間にSRV6対応ユーザープレーンを提供します。
This mode employs two SRGWs that map GTP-U traffic to SRv6 and vice versa.
このモードは、GTP-UトラフィックをSRV6にマッピングする2つのSRGWを採用し、その逆も同様です。
Unlike other interworking modes, in this mode, both of the mobility overlay endpoints use GTP-U. Two SRGWs are deployed in either an N3 or N9 interface to realize an intermediate SR Policy.
他のインターワーキングモードとは異なり、このモードでは、モビリティオーバーレイエンドポイントの両方がGTP-Uを使用します。2つのSRGWがN3またはN9インターフェイスのいずれかに展開され、中間SRポリシーが実現されます。
+----+
-| S1 |-
+-----+ / +----+ \
| gNB |- SRv6 / SRv6 \ +----+ +--------+ +-----+
+-----+ \ / VNF -| C1 |---| SRGW-B |----| UPF |
GTP[N3]\ +--------+ / +----+ +--------+ +-----+
-| SRGW-A |- SRv6 SR Gateway-B GTP
+--------+ TE
SR Gateway-A
Figure 7: Example Topology for SRv6 Drop-In Mode
図7：SRV6ドロップインモードのトポロジの例
The packet flow of Figure 7 is as follows:
図7のパケットフローは次のとおりです。
gNB_out : (gNB, U::1)(GTP: TEID T)(A,Z)
GW-A_out: (GW-A, S1)(U::1, SGB::TEID, C1; SL=3)(A,Z)->U::1 is an
End.M.GTP6.D.Di
SID at SRGW-A
S1_out : (GW-A, C1)(U::1, SGB::TEID, C1; SL=2)(A,Z)
C1_out : (GW-A, SGB::TEID)(U::1, SGB::TEID, C1; SL=1)(A,Z)
GW-B_out: (GW-B, U::1)(GTP: TEID T)(A,Z) ->SGB::TEID is an
End.M.GTP6.E
SID at SRGW-B
UPF_out : (A,Z)
When a packet destined to Z is sent to the gNB, which is unmodified (control plane and user plane remain GTP-U), gNB performs encapsulation into new IP, UDP, and GTP-U headers. The IPv6 DA, U::1, and GTP-U TEID are the ones received at the N2 interface.
Zに運命づけられたパケットがGNBに送信されると、変更されていない（コントロールプレーンとユーザープレーンがGTP-Uのまま）、GNBは新しいIP、UDP、およびGTP-Uヘッダーにカプセル化を実行します。IPv6 DA、U :: 1、およびGTP-U TEIDは、N2インターフェイスで受信されたものです。
The IPv6 address that was signaled over the N2 interface for that PDU Session, U::1, is now the IPv6 DA. U::1 is an SRv6 Binding SID at SRGW-A. Hence, the packet is routed to the SRGW.
そのPDUセッションのN2インターフェイスで信号を送られたIPv6アドレス、u :: 1は、IPv6 Daになりました。U :: 1は、SRGW-AのSRV6バインドSIDです。したがって、パケットはSRGWにルーティングされます。
When the packet arrives at SRGW-A, the SRGW identifies U::1 as an End.M.GTP6.D.Di Binding SID (see Section 6.4). Hence, the SRGW removes the IPv6, UDP, and GTP-U headers and pushes an IPv6 header with its own SRH containing the SIDs bound to the SR Policy associated with this Binding SID. There is one instance of the End.M.GTP6.D.Di SID per PDU type.
パケットがSRGW-Aに到着すると、SRGWはu :: 1をend.m.gtp6.d.diバインディングSIDとして識別します（セクション6.4を参照）。したがって、SRGWはIPv6、UDP、およびGTP-Uヘッダーを削除し、この結合SIDに関連するSRポリシーに結合したSIDを含む独自のSRHを使用してIPv6ヘッダーをプッシュします。PDUタイプごとに、end.m.gtp6.d.di sidの1つのインスタンスがあります。
S1 and C1 perform their related Endpoint functionality and forward the packet.
S1とC1は、関連するエンドポイント機能を実行し、パケットを転送します。
Once the packet arrives at SRGW-B, the SRGW identifies the active SID as an End.M.GTP6.E function. The SRGW removes the IPv6 header and all its extensions headers. The SRGW generates new IPv6, UDP, and GTP headers. The new IPv6 DA is U::1, which is the last SID in the received SRH. The TEID in the generated GTP-U header is an argument of the received End.M.GTP6.E SID. The SRGW pushes the headers to the packet and forwards the packet toward UPF. There is one instance of the End.M.GTP6.E SID per PDU type.
パケットがSRGW-Bに到着すると、SRGWはアクティブなSIDをend.m.gtp6.e関数として識別します。SRGWは、IPv6ヘッダーとそのすべての拡張ヘッダーを削除します。SRGWは、新しいIPv6、UDP、およびGTPヘッダーを生成します。新しいIPv6 daはu :: 1であり、これは受信したSRHの最後のSIDです。生成されたGTP-UヘッダーのTEIDは、受信したend.m.gtp6.e sidの引数です。SRGWはヘッダーをパケットに押し込み、PacketをUPFに転送します。end.m.gtp6.e PDUタイプごとに1つのインスタンスがあります。
Once the packet arrives at UPF, the packet is a regular IPv6/GTP packet. The UPF looks for the specific rule for that TEID to forward the packet. This UPF behavior is not modified from current and previous generations.
パケットがUPFに到着すると、パケットは通常のIPv6/GTPパケットになります。UPFは、そのTeidがパケットを転送するための特定のルールを探します。このUPFの動作は、現在および前世代から変更されていません。
This section introduces new SRv6 Endpoint Behaviors for the mobile user plane. The behaviors described in this document are compatible with the NEXT and REPLACE flavors defined in [SRV6-SRH-COMPRESSION].
このセクションでは、モバイルユーザープレーンの新しいSRV6エンドポイントの動作を紹介します。このドキュメントで説明されている動作は次の文書と互換性があり、[srv6-srh-compression]で定義されているフレーバーを置き換えます。
Args.Mob.Session provides per-session information for charging, buffering, or other purposes required by some mobile nodes. The Args.Mob.Session argument format is used in combination with the End.Map, End.DT4/End.DT6/End.DT46, and End.DX4/End.DX6/End.DX2 behaviors. Note that proposed format is applicable for 5G networks, while similar formats could be used for legacy networks.
Args.mob.sessionは、一部のモバイルノードで必要な充電、バッファリング、またはその他の目的のためにセッションごとの情報を提供します。args.mob.session引数形式は、end.map、end.dt4/end.dt6/end.dt46、およびend.dx4/end.dx6/end.dx2動作と組み合わせて使用されます。提案された形式は5Gネットワークに適用され、同様の形式をレガシーネットワークに使用できることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| QFI |R|U| PDU Session ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|PDU Sess(cont')|
+-+-+-+-+-+-+-+-+
Figure 8: Args.Mob.Session Format
図8：args.mob.session形式
QFI:
QFI：
QoS Flow Identifier [TS.38415].
QoSフロー識別子[Ts.38415]。
R:
R：
Reflective QoS Indication [TS.23501]. This parameter indicates the activation of reflective QoS towards the UE for the transferred packet. Reflective QoS enables the UE to map uplink user-plane traffic to QoS flows without SMF-provided QoS rules.
反射QoS表示[Ts.23501]。このパラメーターは、転送されたパケットのUEに対する反射QoSのアクティブ化を示します。反射的なQoSを使用すると、UEはSMFが提供するQoSルールなしでUplinkユーザープレーントラフィックをQoSフローにマッピングできます。
U:
U：
Unused and for future use. MUST be 0 on transmission and ignored on receipt.
未使用と将来の使用のため。送信時に0であり、受領時に無視する必要があります。
PDU Session ID:
PDUセッションID：
Identifier of PDU Session. The GTP-U equivalent is TEID.
PDUセッションの識別子。GTP-U同等物はTeidです。
Args.Mob.Session is required in case one SID aggregates multiple PDU Sessions. Since the SRv6 SID is likely NOT to be instantiated per PDU Session, Args.Mob.Session helps the UPF to perform the behaviors that require granularity per QFI and/or per PDU Session.
Args.mob.Sessionは、1つのSIDが複数のPDUセッションを集約している場合に必要です。SRV6 SIDはPDUセッションごとにインスタンス化されていない可能性が高いため、Args.mob.Sessionは、UPFがQFIあたりおよび/またはPDUセッションごとに粒度を必要とする動作を実行するのに役立ちます。
Note that the encoding of user-plane messages (e.g., Echo Request, Echo Reply, Error Indication, and End Marker) is out of the scope of this document. [SRV6-UP-MSG-ENCODING] defines one possible encoding method.
ユーザー平面メッセージのエンコード（例：エコーリクエスト、エコー応答、エラー表示、およびエンドマーカー）は、このドキュメントの範囲外であることに注意してください。[srv6-up-msg-encoding] 1つの可能なエンコード方法を定義します。
End.MAP (Endpoint Behavior with SID mapping) is used in several scenarios. Particularly in mobility, End.MAP is used by the intermediate UPFs.
end.map（SIDマッピングによるエンドポイントの動作）は、いくつかのシナリオで使用されています。特にモビリティでは、end.mapは中間UPFSによって使用されます。
When node N receives a packet whose IPv6 DA is D and D is a local End.MAP SID, N does the following:
Node NがIPv6DaがDであり、DがローカルEND.MAP SIDであるパケットを受信した場合、Nは次のとおりです。
S01. If (IPv6 Hop Limit <= 1) {
S02. Send an ICMP Time Exceeded message to the Source Address with
Code 0 (Hop limit exceeded in transit),
interrupt packet processing, and discard the packet.
S03. }
S04. Decrement IPv6 Hop Limit by 1
S05. Update the IPv6 DA with the new mapped SID
S06. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
Note: The SRH is not modified (neither the SID nor the SL value).
注：SRHは変更されていません（SIDもSL値もありません）。
End.M.GTP6.D (Endpoint Behavior with IPv6/GTP-U decapsulation into SR Policy) is used in the interworking scenario for the uplink towards SRGW from the legacy gNB using IPv6/GTP. Any SID instance of this behavior is associated with an SR Policy B and an IPv6 Source Address S.
end.m.gtp6.d（IPv6/gtp-u脱カプセル化によるsrポリシーへのエンドポイントの動作）は、IPv6/GTPを使用してレガシーGNBからSRGWに向けたアップリンクのインターワーキングシナリオで使用されます。この動作のSIDインスタンスは、SRポリシーBおよびIPv6ソースアドレスSに関連付けられています。
When the SR Gateway node N receives a packet destined to D, and D is a local End.M.GTP6.D SID, N does the following:
SRゲートウェイノードnがDに運命づけられたパケットを受信し、DはローカルEND.M.GTP6.D SIDである場合、nは次を実行します。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address with
Code 0 (Erroneous header field encountered) and
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M.GTP6.D SID, N does the following:
end.m.gtp6.d sidとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上層ヘッダーを処理する場合、nは次を実行します。
S01. If (Next Header (NH) == UDP & UDP_Dest_port == GTP) {
S02. Copy the GTP-U TEID and QFI to buffer memory
S03. Pop the IPv6, UDP, and GTP-U headers
S04. Push a new IPv6 header with its own SRH containing B
S05. Set the outer IPv6 SA to S
S06. Set the outer IPv6 DA to the first SID of B
S07. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next Header (NH) fields
S08. Write in the SRH[0] the Args.Mob.Session based on
the information in buffer memory
S09. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S10. } Else {
S11. Process as per [RFC8986], Section 4.1.1
S12. }
Notes:
ノート：
* In line S07, the NH is set based on the SID parameter. There is one instantiation of the End.M.GTP6.D SID per PDU Session Type; hence, the NH is already known in advance. In addition, for the IPv4v6 PDU Session Type, the router inspects the first nibble of the PDU to know the NH value.
* ラインS07では、NHはSIDパラメーターに基づいて設定されています。PDUセッションタイプごとに、end.m.gtp6.d sidのインスタンス化が1つあります。したがって、NHは事前に既に知られています。さらに、IPv4v6 PDUセッションタイプの場合、ルーターはPDUの最初のニブルを検査してNH値を知ります。
* The last segment SHOULD be followed by an Args.Mob.Session argument space, which is used to provide the session identifiers, as shown in line S08.
* 最後のセグメントの後に、args.mob.session引数の引数スペースが続く必要があります。これは、行S08に示すように、セッション識別子を提供するために使用されます。
End.M.GTP6.D.Di (Endpoint Behavior with IPv6/GTP-U decapsulation into SR Policy for Drop-in Mode) is used in the SRv6 drop-in interworking scenario described in Section 5.4. The difference between End.M.GTP6.D as another variant of the IPv6/GTP decapsulation function is that the original IPv6 DA of the GTP-U packet is preserved as the last SID in SRH.
end.m.gtp6.d.di（ドロップインモードのためのSRポリシーへのIPv6/gtp-u脱カプセル化によるエンドポイントの動作）は、セクション5.4で説明されているSRV6ドロップインインターワーキングシナリオで使用されます。end.m.gtp6.dの違いは、IPv6/GTP脱カプセル化関数の別のバリアントとしての違いです。GTP-Uパケットの元のIPv6DAがSRHの最後のSIDとして保存されていることです。
Any SID instance of this behavior is associated with an SR Policy B and an IPv6 Source Address S.
この動作のSIDインスタンスは、SRポリシーBおよびIPv6ソースアドレスSに関連付けられています。
When the SR Gateway node N receives a packet destined to D, and D is a local End.M.GTP6.D.Di SID, N does the following:
SRゲートウェイノードnがDに向けられたパケットを受信し、DがローカルEND.M.GTP6.DI SIDである場合、Nは次のとおりです。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address with
Code 0 (Erroneous header field encountered) and
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M.GTP6.Di SID, N does the following:
end.m.gtp6.di sidとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上層ヘッダーを処理するとき、nは次のことを行います。
S01. If (Next Header = UDP & UDP_Dest_port = GTP) {
S02. Copy D to buffer memory
S03. Pop the IPv6, UDP, and GTP-U headers
S04. Push a new IPv6 header with its own SRH containing B
S05. Set the outer IPv6 SA to S
S06. Set the outer IPv6 DA to the first SID of B
S07. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next Header fields
S08. Prepend D to the SRH (as SRH[0]) and set SL accordingly
S09. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
S10. } Else {
S11. Process as per [RFC8986], Section 4.1.1
S12. }
Notes:
ノート：
* In line S07, the NH is set based on the SID parameter. There is one instantiation of the End.M.GTP6.Di SID per PDU Session Type; hence, the NH is already known in advance. In addition, for the IPv4v6 PDU Session Type, the router inspects the first nibble of the PDU to know the NH value.
* ラインS07では、NHはSIDパラメーターに基づいて設定されています。PDUセッションタイプごとに、end.m.gtp6.di sidのインスタンス化が1つあります。したがって、NHは事前に既に知られています。さらに、IPv4v6 PDUセッションタイプの場合、ルーターはPDUの最初のニブルを検査してNH値を知ります。
* S SHOULD be an End.M.GTP6.E SID instantiated at the SR Gateway.
* Sは、SRゲートウェイにインスタンス化されたend.m.gtp6.e Sidでなければなりません。
End.M.GTP6.E (Endpoint Behavior with encapsulation for IPv6/GTP-U tunnel" behavior) is used among others in the interworking scenario for the downlink toward the legacy gNB using IPv6/GTP.
end.m.gtp6.e（IPv6/gtp-uトンネルのカプセル化を伴うエンドポイントの動作 "動作）は、IPv6/gtpを使用してレガシーGNBに向けたダウンリンクのインターワーキングシナリオで使用されます。
The prefix of End.M.GTP6.E SID MUST be followed by the Args.Mob.Session argument space, which is used to provide the session identifiers.
end.m.gtp6.e sidのプレフィックスの後に、args.mob.session argumentスペースが続く必要があります。これは、セッション識別子を提供するために使用されます。
When the SR Gateway node N receives a packet destined to D, and D is a local End.M.GTP6.E SID, N does the following:
SRゲートウェイノードnがDに運命づけられたパケットを受信し、DはローカルEND.M.GTP6.E SIDである場合、nは次を実行します。
S01. When an SRH is processed {
S02. If (Segments Left != 1) {
S03. Send an ICMP Parameter Problem to the Source Address with
Code 0 (Erroneous header field encountered) and
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M.GTP6.E SID, N does the following:
end.m.gtp6.e sidとしてローカルにインスタンス化されたFIBエントリを一致させるパケットの上層ヘッダーを処理する場合、nは次のことを行います。
S01. Copy SRH[0] and D to buffer memory
S02. Pop the IPv6 header and all its extension headers
S03. Push a new IPv6 header with a UDP/GTP-U header
S04. Set the outer IPv6 SA to S
S05. Set the outer IPv6 DA from buffer memory
S06. Set the outer Payload Length, Traffic Class, Flow Label,
Hop Limit, and Next Header fields
S07. Set the GTP-U TEID (from buffer memory)
S08. Submit the packet to the egress IPv6 FIB lookup for
transmission to the new destination
Notes:
ノート：
* An End.M.GTP6.E SID MUST always be the penultimate SID. The TEID is extracted from the argument space of the current SID.
* end.m.gtp6.e sidは常に最後から2番目のsidでなければなりません。TEIDは、現在のSIDの引数空間から抽出されます。
* The source address S SHOULD be an End.M.GTP6.D SID instantiated at the egress SR Gateway.
* ソースアドレスsは、Engress SR Gatewayでインスタンス化されたend.m.gtp6.d Sidである必要があります。
End.M.GTP4.E (Endpoint Behavior with encapsulation for IPv4/GTP-U tunnel) is used in the downlink when doing interworking with legacy gNB using IPv4/GTP.
end.m.gtp4.e（IPv4/gtp-uトンネルのカプセル化を伴うエンドポイントの動作）は、IPv4/gtpを使用してレガシーGNBとの相互作用を行う際にダウンリンクで使用されます。
When the SR Gateway node N receives a packet destined to S, and S is a local End.M.GTP4.E SID, N does the following:
SRゲートウェイノードnがSに運命づけられたパケットを受信し、SがローカルEND.M.GTP4.E SIDである場合、nは次を実行します。
S01. When an SRH is processed {
S02. If (Segments Left != 0) {
S03. Send an ICMP Parameter Problem to the Source Address with
Code 0 (Erroneous header field encountered) and
Pointer set to the Segments Left field,
interrupt packet processing, and discard the packet.
S04. }
S05. Proceed to process the next header in the packet
S06. }
When processing the Upper-Layer header of a packet matching a FIB entry locally instantiated as an End.M.GTP4.E SID, N does the following:
end.m.gtp4.e sidとしてローカルにインスタンス化されたfibエントリを一致させるパケットの上層ヘッダーを処理する場合、nは次のことを行います。
S01. Store the IPv6 DA and SA in buffer memory
S02. Pop the IPv6 header and all its extension headers
S03. Push a new IPv4 header with a UDP/GTP-U header
S04. Set the outer IPv4 SA and DA (from buffer memory)
S05. Set the outer Total Length, DSCP, Time To Live, and
Next Header fields
S06. Set the GTP-U TEID (from buffer memory)
S07. Submit the packet to the egress IPv4 FIB lookup for
transmission to the new destination
Notes:
ノート：
* The End.M.GTP4.E SID in S has the following format:
* end.m.gtp4.e sid in sには、次の形式があります。
0 127
+-----------------------+-------+----------------+---------+
| SRGW-IPv6-LOC-FUNC |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
Figure 9: End.M.GTP4.E SID Encoding
図9：End.m.gtp4.e SIDエンコーディング
* The IPv6 Source Address has the following format:
* IPv6ソースアドレスには、次の形式があります。
0 127
+----------------------+--------+--------------------------+
| Source UPF Prefix |IPv4 SA | any bit pattern(ignored) |
+----------------------+--------+--------------------------+
128-a-b a b
Figure 10: IPv6 SA Encoding for End.M.GTP4.E
図10：end.m.gtp4.eのためのIPv6 SAエンコード
H.M.GTP4.D (SR Policy Headend with tunnel decapsulation and map to an SRv6 policy) is used in the direction from the legacy IPv4 user plane to the SRv6 user-plane network.
h.m.gtp4.d（トンネルの脱カプセル化を備えたSRポリシーヘッドエンドとSRV6ポリシーへのマップ）は、LEGACY IPv4ユーザープレーンからSRV6ユーザープレーンネットワークまでの方向に使用されます。
When the SR Gateway node N receives a packet destined to a SRGW-IPv4-Prefix, N does the following:
SRゲートウェイノードnがSRGW-IPV4-PREFIXに向けられたパケットを受信すると、Nは次のとおりです。
S01. IF Payload == UDP/GTP-U THEN
S02. Pop the outer IPv4 header and UDP/GTP-U headers
S03. Copy IPv4 DA and TEID to form SID B
S04. Copy IPv4 SA to form IPv6 SA B'
S05. Encapsulate the packet into a new IPv6 header
S06. Set the IPv6 DA = B
S07. Forward along the shortest path to B
S08. ELSE
S09. Drop the packet
The SID B has the following format:
SID Bには次の形式があります。
0 127
+-----------------------+-------+----------------+---------+
|Destination UPF Prefix |IPv4DA |Args.Mob.Session|0 Padded |
+-----------------------+-------+----------------+---------+
128-a-b-c a b c
Figure 11: H.M.GTP4.D SID Encoding
図11：H.M.GTP4.D SIDエンコーディング
The SID B MAY be an SRv6 Binding SID instantiated at the first UPF (U1) to bind an SR Policy [RFC9256].
SID Bは、最初のUPF（U1）にインスタンス化されたSRV6結合SIDであり、SRポリシー[RFC9256]に結合する可能性があります。
The mobile user plane requires a rate-limit feature. For this purpose, this document defines a new behavior, called "End.Limit". The "End.Limit" behavior encodes in its arguments the rate-limiting parameter that should be applied to this packet. Multiple flows of packets should have the same group identifier in the SID when those flows are in the same AMBR (Aggregate Maximum Bit Rate) group. The encoding format of the rate-limit segment SID is as follows:
モバイルユーザープレーンには、レートリミット機能が必要です。この目的のために、このドキュメントは「end.limit」と呼ばれる新しい動作を定義します。「end.limit」の動作は、このパケットに適用する必要があるレート制限パラメーターを引数でエンコードします。パケットの複数のフローは、これらのフローが同じAMBR（集約最大ビットレート）グループにある場合、SIDに同じグループ識別子を持つ必要があります。Rate-limitセグメントSIDのエンコード形式は次のとおりです。
+----------------------+----------+-----------+
| LOC+FUNC rate-limit | group-id | limit-rate|
+----------------------+----------+-----------+
128-i-j i j
Figure 12: End.Limit: Rate-Limiting Behavior Argument Format
図12：end.limit：レート制限行動引数形式
If the limit-rate bits are set to zero, the node should not do rate limiting unless static configuration or control plane sets the limit rate associated to the SID.
制限レートビットがゼロに設定されている場合、静的構成またはコントロールプレーンがSIDに関連付けられた制限レートを設定しない限り、ノードはレート制限を実行してはなりません。
The 3GPP [TS.23501] defines the following PDU Session Types:
3GPP [Ts.23501]は、次のPDUセッションタイプを定義します。
* IPv4
* IPv4
* IPv6
* IPv6
* IPv4v6
* IPv4v6
* Ethernet
* イーサネット
* Unstructured
* 非構造
SRv6 supports the 3GPP PDU Session Types without any protocol overhead by using the corresponding SRv6 behaviors:
SRV6は、対応するSRV6動作を使用して、プロトコルオーバーヘッドなしで3GPP PDUセッションタイプをサポートします。
* End.DX4 and End.DT4 for IPv4 PDU Sessions
* IPv4 PDUセッション用のend.dx4およびend.dt4
* End.DX6, End.DT6, and End.T for IPv6 PDU Sessions
* end.dx6、end.dt6、およびend.tのipv6 pduセッション
* End.DT46 for IPv4v6 PDU Sessions
* IPv4v6 PDUセッション用のend.dt46
* End.DX2 for L2 and Unstructured PDU Sessions
* L2および非構造化されたPDUセッション用のend.dx2
A mobile network may be required to implement "network slices", which logically separate network resources within the same SR domain.
「ネットワークスライス」を実装するためにモバイルネットワークが必要になる場合があります。これは、同じSRドメイン内のネットワークリソースを論理的に分離します。
[RFC9256] describes a solution to build basic network slices with SR. Depending on the requirements, these slices can be further refined by adopting the mechanisms from:
[RFC9256]は、SRで基本的なネットワークスライスを構築するソリューションを説明しています。要件に応じて、次のメカニズムを採用することにより、これらのスライスをさらに洗練させることができます。
* IGP Flex-Algo [RFC9350]
* IGP Flex-Algo [RFC9350]
* Inter-Domain policies [RFC9087]
* ドメイン間ポリシー[RFC9087]
Furthermore, these can be combined with ODN/AS (On-Demand Next Hop / Automated Steering) [RFC9256] for automated slice provisioning and traffic steering.
さらに、これらは、自動スライスプロビジョニングとトラフィックステアリングのために、ODN / AS（オンデマンドNext Hop / Automatedステアリング）[RFC9256] [RFC9256]と組み合わせることができます。
Further details on how these tools can be used to create end-to-end network slices are documented in [NETWORK-SLICE].
これらのツールを使用してエンドツーエンドのネットワークスライスを作成する方法の詳細は、[ネットワークスライス]で文書化されています。
This document focuses on user-plane behavior and its independence from the control plane. While the SRv6 mobile user-plane behaviors may be utilized in emerging architectures (for example, those described in [MFA] and [MUP-SR-ARCH]), this document does not impose any change to the existent mobility control plane.
このドキュメントは、ユーザー面の動作とコントロールプレーンからの独立性に焦点を当てています。SRV6モバイルユーザープレーンの動作は、新しいアーキテクチャ（たとえば、[MFA]および[MUP-SR-ARCH]に記載されているアーキテクチャ）で利用される場合がありますが、このドキュメントは既存のモビリティコントロールプレーンに変更を課しません。
Section 11 allocates SRv6 Endpoint Behavior codepoints for the new behaviors defined in this document.
セクション11では、このドキュメントで定義されている新しい動作のSRV6エンドポイントの動作コードポイントを割り当てます。
The security considerations for Segment Routing are discussed in [RFC8402]. More specifically, for SRv6, the security considerations and the mechanisms for securing an SR domain are discussed in [RFC8754]. Together, they describe the required security mechanisms that allow establishment of an SR domain of trust to operate SRv6-based services for internal traffic while preventing any external traffic from accessing or exploiting the SRv6-based services.
セグメントルーティングのセキュリティ上の考慮事項については、[RFC8402]で説明します。より具体的には、SRV6の場合、SRドメインを保護するためのセキュリティ上の考慮事項とメカニズムについて[RFC8754]で説明します。一緒に、SRV6ベースのサービスにアクセスまたは悪用するのを防ぎながら、SRV6ベースのサービスを内部トラフィック用にSRV6ベースのサービスを運用できるように、信頼のSRの確立を可能にする必要なセキュリティメカニズムを説明します。
The technology described in this document is applied to a mobile network that is within the SR domain. It's important to note the resemblance between the SR domain and the 3GPP Packet Core Domain.
このドキュメントで説明されている技術は、SRドメイン内にあるモバイルネットワークに適用されます。SRドメインと3GPPパケットコアドメインの類似性に注意することが重要です。
This document introduces new SRv6 Endpoint Behaviors. Those behaviors operate on control plane information, including information within the received SRH payload on which the behaviors operate. Altering the behaviors requires that an attacker alter the SR domain as defined in [RFC8754]. Those behaviors do not need any special security consideration given that they are deployed within that SR domain.
このドキュメントでは、新しいSRV6エンドポイントの動作を紹介します。これらの動作は、動作が動作する受信したSRHペイロード内の情報を含む、コントロールプレーン情報で動作します。動作を変更するには、攻撃者が[RFC8754]で定義されているようにSRドメインを変更する必要があります。これらの動作は、そのSRドメイン内に展開されていることを考えると、特別なセキュリティの考慮を必要としません。
The following values have been allocated in the "SRv6 Endpoint Behaviors" [RFC8986] subregistry within the top-level "Segment Routing Parameters" registry:
次の値は、「SRV6エンドポイント動作」[RFC8986]上位レベルの「セグメントルーティングパラメーター」レジストリ内のサブレジストリに割り当てられています。
+=======+========+===================+===========+============+
| Value | Hex | Endpoint Behavior | Reference | Change |
| | | | | Controller |
+=======+========+===================+===========+============+
| 40 | 0x0028 | End.MAP | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+
| 41 | 0x0029 | End.Limit | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+
| 69 | 0x0045 | End.M.GTP6.D | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+
| 70 | 0x0046 | End.M.GTP6.Di | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+
| 71 | 0x0047 | End.M.GTP6.E | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+
| 72 | 0x0048 | End.M.GTP4.E | RFC 9433 | IETF |
+-------+--------+-------------------+-----------+------------+
Table 1: SRv6 Mobile User-Plane Endpoint Behavior Types
表1：SRV6モバイルユーザープレーンエンドポイントの動作タイプ
[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>.
[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>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC9256] Filsfils, C., Talaulikar, K., Ed., Voyer, D., Bogdanov,
A., and P. Mattes, "Segment Routing Policy Architecture",
RFC 9256, DOI 10.17487/RFC9256, July 2022,
<https://www.rfc-editor.org/info/rfc9256>.
[TS.23501] 3GPP, "System architecture for the 5G System (5GS)",
Version 17.9.0, 3GPP TS 23.501, June 2023.
[MFA] Gundavelli, S., Liebsch, M., and S. Matsushima, "Mobility-
aware Floating Anchor (MFA)", Work in Progress, Internet-
Draft, draft-gundavelli-dmm-mfa-01, 19 September 2018,
<https://datatracker.ietf.org/doc/html/draft-gundavelli-
dmm-mfa-01>.
[MUP-SR-ARCH]
Matsushima, S., Horiba, K., Khan, A., Kawakami, Y.,
Murakami, T., Patel, K., Kohno, M., Kamata, T., Camarillo,
P., Horn, J., Voyer, D., Zadok, S., Meilik, I., Agrawal,
A., and K. Perumal, "Mobile User Plane Architecture using
Segment Routing for Distributed Mobility Management", Work
in Progress, Internet-Draft, draft-mhkk-dmm-srv6mup-
architecture-05, 13 March 2023,
<https://datatracker.ietf.org/doc/html/draft-mhkk-dmm-
srv6mup-architecture-05>.
[NETWORK-SLICE]
Ali, Z., Filsfils, C., Camarillo, P., Voyer, D.,
Matsushima, S., Rokui, R., Dhamija, A., and P. Maheshwari,
"Building blocks for Network Slice Realization in Segment
Routing Network", Work in Progress, Internet-Draft, draft-
ali-teas-spring-ns-building-blocks-03, 7 September 2022,
<https://datatracker.ietf.org/doc/html/draft-ali-teas-
spring-ns-building-blocks-03>.
[RFC9087] Filsfils, C., Ed., Previdi, S., Dawra, G., Ed., Aries, E.,
and D. Afanasiev, "Segment Routing Centralized BGP Egress
Peer Engineering", RFC 9087, DOI 10.17487/RFC9087, August
2021, <https://www.rfc-editor.org/info/rfc9087>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[SR-SERV-PROG]
Clad, F., Ed., Xu, X., Ed., Filsfils, C., Bernier, D., Li,
C., Decraene, B., Ma, S., Yadlapalli, C., Henderickx, W.,
and S. Salsano, "Service Programming with Segment
Routing", Work in Progress, Internet-Draft, draft-ietf-
spring-sr-service-programming-07, 15 February 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
sr-service-programming-07>.
[SRV6-DEPLOY-STAT]
Matsushima, S., Filsfils, C., Ali, Z., Li, Z., Rajaraman,
K., and A. Dhamija, "SRv6 Implementation and Deployment
Status", Work in Progress, Internet-Draft, draft-
matsushima-spring-srv6-deployment-status-15, 5 April 2022,
<https://datatracker.ietf.org/doc/html/draft-matsushima-
spring-srv6-deployment-status-15>.
[SRV6-MOB-ARCH-DISCUSS]
Kohno, M., Clad, F., Camarillo, P., and Z. Ali,
"Architecture Discussion on SRv6 Mobile User plane", Work
in Progress, Internet-Draft, draft-kohno-dmm-srv6mob-arch-
06, 9 March 2023, <https://datatracker.ietf.org/doc/html/
draft-kohno-dmm-srv6mob-arch-06>.
[SRV6-MOB-USECASES]
Camarillo, P., Ed., Filsfils, C., Elmalky, H., Ed.,
Matsushima, S., Voyer, D., Cui, A., and B. Peirens, "SRv6
Mobility Use-Cases", Work in Progress, Internet-Draft,
draft-camarilloelmalky-springdmm-srv6-mob-usecases-02, 15
August 2019, <https://datatracker.ietf.org/doc/html/draft-
camarilloelmalky-springdmm-srv6-mob-usecases-02>.
[SRV6-SRH-COMPRESSION]
Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding in SRH",
Work in Progress, Internet-Draft, draft-ietf-spring-srv6-
srh-compression-05, 20 June 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-spring-
srv6-srh-compression-05>.
[SRV6-UP-MSG-ENCODING]
Murakami, T., Matsushima, S., Ebisawa, K., Camarillo, P.,
and R. Shekhar, "User Plane Message Encoding", Work in
Progress, Internet-Draft, draft-murakami-dmm-user-plane-
message-encoding-05, 5 March 2022,
<https://datatracker.ietf.org/doc/html/draft-murakami-dmm-
user-plane-message-encoding-05>.
[TS.29281] 3GPP, "General Packet Radio System (GPRS) Tunnelling
Protocol User Plane (GTPv1-U)", Version 17.4.0, 3GPP
TS 29.281, September 2022.
[TS.38415] 3GPP, "PDU session user plane protocol", Version 17.0.0,
3GPP TS 38.415, April 2022.
The authors would like to thank Daisuke Yokota, Bart Peirens, Ryokichi Onishi, Kentaro Ebisawa, Peter Bosch, Darren Dukes, Francois Clad, Sri Gundavelli, Sridhar Bhaskaran, Arashmid Akhavain, Ravi Shekhar, Aeneas Dodd-Noble, Carlos Jesus Bernardos, Dirk von Hugo, and Jeffrey Zhang for their useful comments of this work.
著者は、横浜大臣、バート・ペイレンズ、オニシとヨキチ、ケンタロ・エビサワ、ピーター・ボッシュ、ダレン・デュークス、フランソワ・クラッド、スリ・ガンダヴェッリ、スリダル・バスカラン、アラシュミド・アカヴァイン、ラヴィ・ヴァンドゥ・ヴァン・ブナス・イエス・ヴァン・ブナス・イエス・ヴァン・ブナス・イエス・ヴァン・ブナス・イエス・ヴァン・バン・イエス・ヴァン・イエス・ヴァン・バン・ヴァン・イエス・ヴァン・バナに感謝したいと思います。Hugo、およびJeffrey Zhangは、この作品の有用なコメントをしてくれました。
Kentaro Ebisawa
Toyota Motor Corporation
Japan
Email: ebisawa@toyota-tokyo.tech
Tetsuya Murakami
Arrcus, Inc.
United States of America
Email: tetsuya.ietf@gmail.com
Charles E. Perkins
Lupin Lodge
United States of America
Email: charliep@computer.org
Jakub Horn
Cisco Systems, Inc.
United States of America
Email: jakuhorn@cisco.com
Satoru Matsushima (editor)
SoftBank
Japan
Email: satoru.matsushima@g.softbank.co.jp
Clarence Filsfils
Cisco Systems, Inc.
Belgium
Email: cf@cisco.com
Miya Kohno
Cisco Systems, Inc.
Japan
Email: mkohno@cisco.com
Pablo Camarillo Garvia (editor)
Cisco Systems, Inc.
Spain
Email: pcamaril@cisco.com
Daniel Voyer
Bell Canada
Canada
Email: daniel.voyer@bell.ca