[要約] RFC 7609は、IBMのSMC-Rプロトコルに関する要約であり、RDMAを介した共有メモリ通信を可能にすることを目的としています。
Independent Submission M. Fox
Request for Comments: 7609 C. Kassimis
Category: Informational J. Stevens
ISSN: 2070-1721 IBM
August 2015
IBM's Shared Memory Communications over RDMA (SMC-R) Protocol
IBMのShared Memory Communications over RDMA（SMC-R）プロトコル
Abstract
概要
This document describes IBM's Shared Memory Communications over RDMA (SMC-R) protocol. This protocol provides Remote Direct Memory Access (RDMA) communications to TCP endpoints in a manner that is transparent to socket applications. It further provides for dynamic discovery of partner RDMA capabilities and dynamic setup of RDMA connections, as well as transparent high availability and load balancing when redundant RDMA network paths are available. It maintains many of the traditional TCP/IP qualities of service such as filtering that enterprise users demand, as well as TCP socket semantics such as urgent data.
このドキュメントでは、RDMAを介したIBMの共有メモリ通信（SMC-R）プロトコルについて説明します。このプロトコルは、ソケットアプリケーションに対して透過的な方法で、TCPエンドポイントにリモートダイレクトメモリアクセス（RDMA）通信を提供します。さらに、パートナーのRDMA機能の動的な検出とRDMA接続の動的なセットアップ、および冗長なRDMAネットワークパスが利用可能な場合の透過的な高可用性と負荷分散を提供します。エンタープライズユーザーが要求するフィルタリングなどの従来のTCP / IPサービス品質の多くと、緊急データなどのTCPソケットセマンティクスを維持します。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7609.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7609で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................5
1.1. Protocol Overview ..........................................6
1.1.1. Hardware Requirements ...............................8
1.2. Definition of Common Terms .................................8
1.3. Conventions Used in This Document .........................11
2. Link Architecture ..............................................11
2.1. Remote Memory Buffers (RMBs) ..............................12
2.2. SMC-R Link Groups .........................................18
2.2.1. Link Group Types ...................................18
2.2.2. Maximum Number of Links in Link Group ..............21
2.2.3. Forming and Managing Link Groups ...................23
2.2.4. SMC-R Link Identifiers .............................24
2.3. SMC-R Resilience and Load Balancing .......................24
3. SMC-R Rendezvous Architecture ..................................26
3.1. TCP Options ...............................................26
3.2. Connection Layer Control (CLC) Messages ...................27
3.3. LLC Messages ..............................................27
3.4. CDC Messages ..............................................29
3.5. Rendezvous Flows ..........................................29
3.5.1. First Contact ......................................29
3.5.1.1. Pre-negotiation of TCP Options ............29
3.5.1.2. Client Proposal ...........................30
3.5.1.3. Server Acceptance .........................32
3.5.1.4. Client Confirmation .......................32
3.5.1.5. Link (QP) Confirmation ....................32
3.5.1.6. Second SMC-R Link Setup ...................35
3.5.1.6.1. Client Processing of ADD LINK
LLC Message from Server ........35
3.5.1.6.2. Server Processing of ADD LINK
Reply LLC Message from Client ..36
3.5.1.6.3. Exchange of RKeys on
Second SMC-R Link ..............38
3.5.1.6.4. Aborting SMC-R and
Falling Back to IP .............38
3.5.2. Subsequent Contact .................................38
3.5.2.1. SMC-R Proposal ............................39
3.5.2.2. SMC-R Acceptance ..........................40
3.5.2.3. SMC-R Confirmation ........................41
3.5.2.4. TCP Data Flow Race with SMC
Confirm CLC Message .......................41
3.5.3. First Contact Variation: Creating a
Parallel Link Group ................................42
3.5.4. Normal SMC-R Link Termination ......................43
3.5.5. Link Group Management Flows ........................44
3.5.5.1. Adding and Deleting Links in an
SMC-R Link Group ..........................44
3.5.5.1.1. Server-Initiated ADD
LINK Processing ................45
3.5.5.1.2. Client-Initiated ADD
LINK Processing ................45
3.5.5.1.3. Server-Initiated DELETE
LINK Processing ................46
3.5.5.1.4. Client-Initiated DELETE
LINK Request ...................48
3.5.5.2. Managing Multiple RKeys over
Multiple SMC-R Links in a Link Group ......49
3.5.5.2.1. Adding a New RMB to an
SMC-R Link Group ...............50
3.5.5.2.2. Deleting an RMB from an
SMC-R Link Group ...............53
3.5.5.2.3. Adding a New SMC-R Link to a
Link Group with Multiple RMBs ..54
3.5.5.3. Serialization of LLC Exchanges,
and Collisions ............................56
3.5.5.3.1. Collisions with ADD
LINK / CONFIRM LINK Exchange ...57
3.5.5.3.2. Collisions during
DELETE LINK Exchange ...........58
3.5.5.3.3. Collisions during
CONFIRM RKEY Exchange ..........59
4. SMC-R Memory-Sharing Architecture ..............................60
4.1. RMB Element Allocation Considerations .....................60
4.2. RMB and RMBE Format .......................................60
4.3. RMBE Control Information ..................................60
4.4. Use of RMBEs ..............................................61
4.4.1. Initializing and Accessing RMBEs ...................61
4.4.2. RMB Element Reuse and Conflict Resolution ..........62
4.5. SMC-R Protocol Considerations .............................63
4.5.1. SMC-R Protocol Optimized Window Size Updates .......63
4.5.2. Small Data Sends ...................................64
4.5.3. TCP Keepalive Processing ...........................65
4.6. TCP Connection Failover between SMC-R Links ...............67
4.6.1. Validating Data Integrity ..........................67
4.6.2. Resuming the TCP Connection on a New SMC-R Link ....68
4.7. RMB Data Flows ............................................69
4.7.1. Scenario 1: Send Flow, Window Size Unconstrained ...69
4.7.2. Scenario 2: Send/Receive Flow, Window Size
Unconstrained ......................................71
4.7.3. Scenario 3: Send Flow, Window Size Constrained .....72
4.7.4. Scenario 4: Large Send, Flow Control, Full
Window Size Writes .................................74
4.7.5. Scenario 5: Send Flow, Urgent Data, Window
Size Unconstrained .................................77
4.7.6. Scenario 6: Send Flow, Urgent Data, Window
Size Closed ........................................79
4.8. Connection Termination ....................................81
4.8.1. Normal SMC-R Connection Termination Flows ..........81
4.8.2. Abnormal SMC-R Connection Termination Flows ........86
4.8.3. Other SMC-R Connection Termination Conditions ......88
5. Security Considerations ........................................89
5.1. VLAN Considerations .......................................89
5.2. Firewall Considerations ...................................89
5.3. Host-Based IP Filters .....................................89
5.4. Intrusion Detection Services ..............................90
5.5. IP Security (IPsec) .......................................90
5.6. TLS/SSL ...................................................90
6. IANA Considerations ............................................90
7. Normative References ...........................................91
Appendix A. Formats ...............................................92
A.1. TCP Option .................................................92
A.2. CLC Messages ...............................................92
A.2.1. Peer ID Format ......................................93
A.2.2. SMC Proposal CLC Message Format .....................94
A.2.3. SMC Accept CLC Message Format .......................98
A.2.4. SMC Confirm CLC Message Format .....................102
A.2.5. SMC Decline CLC Message Format .....................105
A.3. LLC Messages ..............................................106
A.3.1. CONFIRM LINK LLC Message Format ....................107
A.3.2. ADD LINK LLC Message Format ........................109
A.3.3. ADD LINK CONTINUATION LLC Message Format ...........112
A.3.4. DELETE LINK LLC Message Format .....................115
A.3.5. CONFIRM RKEY LLC Message Format ....................117
A.3.6. CONFIRM RKEY CONTINUATION LLC Message Format .......120
A.3.7. DELETE RKEY LLC Message Format .....................122
A.3.8. TEST LINK LLC Message Format .......................124
A.4. Connection Data Control (CDC) Message Format ..............125
Appendix B. Socket API Considerations ............................129
B.1. setsockopt() / getsockopt() Considerations ................130
Appendix C. Rendezvous Error Scenarios ...........................131
C.1. SMC Decline during CLC Negotiation ........................131
C.2. SMC Decline during LLC Negotiation ........................131
C.3. The SMC Decline Window ....................................133
C.4. Out-of-Sync Conditions during SMC-R Negotiation ...........133
C.5. Timeouts during CLC Negotiation ...........................134
C.6. Protocol Errors during CLC Negotiation ....................134
C.7. Timeouts during LLC Negotiation ...........................135
C.7.1. Recovery Actions for LLC Timeouts and Failures .....136
C.8. Failure to Add Second SMC-R Link to a Link Group ..........142
Authors' Addresses ...............................................143
This document specifies IBM's Shared Memory Communications over RDMA (SMC-R) protocol. SMC-R is a protocol for Remote Direct Memory Access (RDMA) communication between TCP socket endpoints. SMC-R runs over networks that support RDMA over Converged Ethernet (RoCE). It is designed to permit existing TCP applications to benefit from RDMA without requiring modifications to the applications or predefinition of RDMA partners.
このドキュメントでは、IBMのRDMA経由の共有メモリ通信（SMC-R）プロトコルについて説明しています。 SMC-Rは、TCPソケットエンドポイント間のリモートダイレクトメモリアクセス（RDMA）通信用のプロトコルです。 SMC-Rは、RDMA over Converged Ethernet（RoCE）をサポートするネットワーク上で実行されます。アプリケーションへの変更やRDMAパートナーの事前定義を必要とせずに、既存のTCPアプリケーションがRDMAのメリットを享受できるように設計されています。
SMC-R provides dynamic discovery of the RDMA capabilities of TCP peers and automatic setup of RDMA connections that those peers can use. SMC-R also provides transparent high availability and load-balancing capabilities that are demanded by enterprise installations but are missing from current RDMA protocols. If redundant RoCE-capable hardware such as RDMA-capable Network Interface Cards (RNICs) and RoCE-capable switches is present, SMC-R can load-balance over that redundant hardware and can also non-disruptively move TCP traffic from failed paths to surviving paths, all seamlessly to the application and the sockets layer. Because SMC-R preserves socket semantics and the TCP three-way handshake, many TCP qualities of service such as filtering, load balancing, and Secure Socket Layer (SSL) encryption are preserved, as are TCP features such as urgent data.
SMC-Rは、TCPピアのRDMA機能の動的検出と、それらのピアが使用できるRDMA接続の自動セットアップを提供します。 SMC-Rは、企業のインストールで要求されているが、現在のRDMAプロトコルにはない透過的な高可用性とロードバランシング機能も提供します。 RDMA対応ネットワークインターフェースカード（RNIC）やRoCE対応スイッチなどの冗長RoCE対応ハードウェアが存在する場合、SMC-Rはその冗長ハードウェア上で負荷分散でき、障害のないパスから無停止で存続するTCPトラフィックを移動できます。パス、すべてシームレスにアプリケーションとソケットレイヤーに。 SMC-RはソケットのセマンティクスとTCP 3ウェイハンドシェイクを保持するため、緊急データなどのTCP機能と同様に、フィルタリング、ロードバランシング、Secure Socket Layer（SSL）暗号化などの多くのTCPサービス品質が保持されます。
Because of the dynamic discovery and setup of SMC-R connectivity between peers, no RDMA connection manager (RDMA-CM) is required. This also means that support for Unreliable Datagram (UD) Queue Pairs (QPs) is also not required.
ピア間のSMC-R接続の動的な検出とセットアップのため、RDMA接続マネージャー（RDMA-CM）は必要ありません。これは、信頼性の低いデータグラム（UD）キューペア（QP）のサポートも不要であることも意味します。
It is recommended that the SMC-R services be implemented in kernel space, which enables optimizations such as resource-sharing between connections across multiple processes and also permits applications using SMC-R to spawn multiple processes (e.g., fork) without losing SMC-R functionality. A user-space implementation is compatible with this architecture, but it may not support spawned processes (e.g., fork), which limits sharing and resource optimization to TCP connections that originate from the same process. This might be an appropriate design choice if the use case is a system that hosts a large single process application that creates many TCP connections to a peer host, or in implementations where a kernel-space implementation is not possible or introduces excessive overhead for "kernel space to user space" context switches.
SMC-Rサービスをカーネルスペースに実装することをお勧めします。これにより、複数のプロセス間での接続間のリソース共有などの最適化が可能になり、SMC-Rを使用するアプリケーションがSMC-Rを失うことなく複数のプロセス（forkなど）を生成できるようになります。機能性。ユーザー空間の実装はこのアーキテクチャと互換性がありますが、生成されたプロセス（フォークなど）をサポートしない場合があり、同じプロセスから発生するTCP接続への共有とリソースの最適化が制限されます。これは、ユースケースがピアホストへのTCP接続を多数作成する大規模な単一プロセスアプリケーションをホストするシステムである場合、またはカーネル空間の実装が不可能であるか、「カーネルスペースからユーザースペースへ」というコンテキストスイッチ。
SMC-R defines the concept of the SMC-R link, which is a logical point-to-point link using reliably connected queue pairs between TCP/IP stack peers over a RoCE fabric. An SMC-R link is bound to a specific hardware path, meaning a specific RNIC on each peer. SMC-R links are created and maintained by an SMC-R layer, which may reside in kernel space or user space, depending upon operating system and implementation requirements. The SMC-R layer resides below the sockets layer and directs data traffic for TCP connections between connected peers over the RoCE fabric using RDMA rather than over a TCP connection. The TCP/IP stack, with its requirements for fragmentation, packetization, etc., is bypassed, and the application data is moved between peers using RDMA.
SMC-Rは、SMC-Rリンクの概念を定義します。これは、RoCEファブリック上のTCP / IPスタックピア間で確実に接続されたキューペアを使用する論理的なポイントツーポイントリンクです。 SMC-Rリンクは特定のハードウェアパス、つまり各ピアの特定のRNICにバインドされています。 SMC-Rリンクは、オペレーティングシステムと実装の要件に応じて、カーネルスペースまたはユーザースペースに存在するSMC-Rレイヤーによって作成および維持されます。 SMC-Rレイヤーはソケットレイヤーの下にあり、TCP接続ではなくRDMAを使用してRoCEファブリック経由で接続されたピア間のTCP接続のデータトラフィックを送信します。フラグメンテーション、パケット化などの要件を持つTCP / IPスタックはバイパスされ、アプリケーションデータはRDMAを使用してピア間で移動されます。
Multiple SMC-R links between the same two TCP/IP stack peers are also supported. A set of SMC-R links called a link group can be logically bonded together to provide redundant connectivity. If there is redundant hardware -- for example, two RNICs on each peer -- separate SMC-R links are created between the peers to exploit that redundant hardware. The link group architecture with redundant links provides load balancing and increased bandwidth, as well as seamless failover.
同じ2つのTCP / IPスタックピア間の複数のSMC-Rリンクもサポートされています。リンクグループと呼ばれるSMC-Rリンクのセットを論理的に結合して、冗長接続を提供できます。冗長ハードウェア（各ピアに2つのRNICなど）がある場合、ピア間に個別のSMC-Rリンクが作成され、その冗長ハードウェアを利用します。冗長リンクを備えたリンクグループアーキテクチャは、ロードバランシングと増加した帯域幅、およびシームレスなフェイルオーバーを提供します。
Each SMC-R link group is associated with an area of memory called Remote Memory Buffers (RMBs), which are areas of memory that are available for SMC-R peers to write into using RDMA writes. Multiple TCP connections between peers may be multiplexed over a single SMC-R link, in which case the SMC-R layer manages the partitioning of the RMBs between the TCP connections. This multiplexing reduces the RDMA resources, such as QPs and RMBs, that are required to support multiple connections between peers, and it also reduces the processing and delays related to setting up QPs, pinning memory, and other RDMA setup tasks when new TCP connections are created. In a kernel-space SMC-R implementation in which the RMBs reside in kernel storage, this sharing and optimization works across multiple processes executing on the same host. In a user-space SMC-R implementation in which the RMBs reside in user space, this sharing and optimization is limited to multiple TCP connections created by a single process, as separate RMBs and QPs will be required for each process.
各SMC-Rリンクグループは、リモートメモリバッファー（RMB）と呼ばれるメモリの領域に関連付けられています。RMBは、SMC-RピアがRDMA書き込みを使用して書き込むことができるメモリの領域です。ピア間の複数のTCP接続は、単一のSMC-Rリンク上で多重化される場合があります。その場合、SMC-Rレイヤーは、TCP接続間のRMBの分割を管理します。この多重化により、ピア間の複数の接続をサポートするために必要なQPやRMBなどのRDMAリソースが削減され、QPのセットアップ、メモリのピン留め、および新しいTCP接続が存在する場合のその他のRDMAセットアップタスクに関連する処理と遅延も削減されます作成した。 RMBがカーネルストレージに存在するカーネル空間のSMC-R実装では、この共有と最適化は、同じホストで実行されている複数のプロセスにわたって機能します。ユーザー空間にRMBが存在するユーザー空間のSMC-R実装では、この共有と最適化は、プロセスごとに個別のRMBとQPが必要になるため、単一のプロセスによって作成された複数のTCP接続に制限されます。
SMC-R also introduces a rendezvous protocol that is used to dynamically discover the RDMA capabilities of TCP connection partners and exchange credentials necessary to exploit that capability if present. TCP connections are set up using the normal TCP three-way handshake [RFC793], with the addition of a new TCP option that indicates SMC-R capability. If both partners indicate SMC-R capability, then at the completion of the three-way TCP handshake the SMC-R layers in each peer take control of the TCP connection and use it to exchange additional Connection Layer Control (CLC) messages to negotiate SMC-R credentials such as QP information; addressability over the RoCE fabric; RMB buffer sizes; and keys and addresses for accessing RMBs over RDMA. If at any time during this negotiation a failure or decline occurs, the TCP connection falls back to using the IP fabric.
SMC-Rは、TCP接続パートナーのRDMA機能を動的に検出し、存在する場合はその機能を利用するために必要な資格情報を交換するために使用されるランデブープロトコルも導入します。 TCP接続は、SMC-R機能を示す新しいTCPオプションを追加して、通常のTCP 3ウェイハンドシェイク[RFC793]を使用してセットアップされます。両方のパートナーがSMC-R機能を示す場合、3ウェイTCPハンドシェイクの完了時に、各ピアのSMC-R層がTCP接続を制御し、それを使用して追加の接続層制御（CLC）メッセージを交換してSMCをネゴシエートします。 QP情報などの-R資格情報。 RoCEファブリックを介したアドレス可能度。 RMBバッファーサイズ。 RDMA経由でRMBにアクセスするためのキーとアドレス。このネゴシエーション中に障害または拒否が発生した場合、TCP接続はIPファブリックの使用にフォールバックします。
If the SMC-R negotiation succeeds and either a new SMC-R link is set up or an existing SMC-R link is chosen for the TCP connection, then the SMC-R layers open the sockets to the applications and the applications use the sockets as normal. The SMC-R layer intercepts the socket reads and writes and moves the TCP connection data over the SMC-R link, "out of band" to the TCP connection, which remains open and idle over the IP fabric, except for termination flows and possible keepalive flows. Regular TCP sequence numbering methods are used for the TCP flows that do occur; data flowing over RDMA does not use or affect TCP sequence numbers.
SMC-Rネゴシエーションが成功し、新しいSMC-Rリンクが設定されているか、既存のSMC-RリンクがTCP接続用に選択されている場合、SMC-Rレイヤーはアプリケーションにソケットを開き、アプリケーションはソケットを使用します普段通り。 SMC-Rレイヤーは、ソケットの読み取りと書き込みをインターセプトし、SMC-Rリンクを介してTCP接続データを「帯域外」のTCP接続に移動します。TCP接続は、終了フローと可能な場合を除いて、IPファブリック上で開いたままアイドルのままです。キープアライブフロー。通常のTCPシーケンス番号付け方法は、発生するTCPフローに使用されます。 RDMAを介して流れるデータは、TCPシーケンス番号を使用または影響しません。
This architecture does not support fallback of active SMC-R connections to IP. Once connection data has completed the switch to RDMA, a TCP connection cannot be switched back to IP and will reset if RDMA becomes unusable.
このアーキテクチャは、IPへのアクティブなSMC-R接続のフォールバックをサポートしていません。接続データがRDMAへの切り替えを完了すると、TCP接続をIPに戻すことができなくなり、RDMAが使用できなくなるとリセットされます。
The SMC-R protocol defines the format of the RMBs that are used to receive TCP connection data written over RDMA, as well as the semantics for managing and writing to these buffers using Connection Data Control (CDC) messages.
SMC-Rプロトコルは、RDMA経由で書き込まれたTCP接続データを受信するために使用されるRMBのフォーマット、および接続データ制御（CDC）メッセージを使用してこれらのバッファーを管理および書き込むためのセマンティクスを定義します。
Finally, SMC-R defines Link Layer Control (LLC) messages that are exchanged over the RoCE fabric between peer SMC-R layers to manage the SMC-R links and link groups. These include messages to test and confirm connectivity over an SMC-R link, add and delete SMC-R links to or from the link group, and exchange RMB addressability information.
最後に、SMC-Rは、SMC-Rリンクとリンクグループを管理するためにピアSMC-Rレイヤー間でRoCEファブリックを介して交換されるリンクレイヤーコントロール（LLC）メッセージを定義します。これらには、SMC-Rリンクを介した接続のテストと確認、リンクグループへのSMC-Rリンクの追加と削除、およびRMBアドレス可能度情報の交換を行うメッセージが含まれます。
SMC-R does not require full Converged Enhanced Ethernet switch functionality. SMC-R functions over standard Ethernet fabrics, provided that endpoint RNICs are provided and IEEE 802.3x Global Pause Frame is supported and enabled in the switch fabric.
SMC-Rは、統合型拡張イーサネットスイッチの完全な機能を必要としません。エンドポイントRNICが提供され、IEEE 802.3xグローバル一時停止フレームがスイッチファブリックでサポートおよび有効化されている場合、SMC-Rは標準のイーサネットファブリック上で機能します。
While SMC-R as specified in this document is designed to operate over RoCE fabrics, adjustments to the rendezvous methods could enable it to run over other RDMA fabrics, such as InfiniBand [RoCE] and iWARP.
このドキュメントで指定されているSMC-RはRoCEファブリック上で動作するように設計されていますが、ランデブーメソッドを調整すると、InfiniBand [RoCE]やiWARPなどの他のRDMAファブリック上で実行できるようになります。
This section provides definitions of terms that have a specific meaning to the SMC-R protocol and are used throughout this document.
このセクションでは、SMC-Rプロトコルに対して特定の意味を持ち、このドキュメント全体で使用される用語の定義を提供します。
SMC-R Link
SMC-Rリンク
An SMC-R link is a logical point-to-point connection over the RoCE fabric via specific physical adapters (Media Access Control / Global Identifier (MAC/GID)). The link is formed during the "first contact" sequence of the TCP/IP three-way handshake sequence that occurs over the IP fabric. During this handshake, an RDMA reliably connected queue pair (RC-QP) connection is formed between the two peer SMC hosts and is defined as the SMC-R link. The SMC-R link can then support multiple TCP connections between the two peers. An SMC-R link is associated with a single LAN (or VLAN) segment and is not routable.
SMC-Rリンクは、特定の物理アダプター（メディアアクセスコントロール/グローバル識別子（MAC / GID））を介したRoCEファブリック上の論理的なポイントツーポイント接続です。リンクは、IPファブリック上で発生するTCP / IP 3ウェイハンドシェイクシーケンスの「最初の接続」シーケンス中に形成されます。このハンドシェイク中に、2つのピアSMCホスト間でRDMAの確実に接続されたキューペア（RC-QP）接続が形成され、SMC-Rリンクとして定義されます。 SMC-Rリンクは、2つのピア間の複数のTCP接続をサポートできます。 SMC-Rリンクは単一のLAN（またはVLAN）セグメントに関連付けられており、ルーティングできません。
SMC-R Link Group
SMC-Rリンクグループ
An SMC-R link group is a group of SMC-R links between the same two SMC-R peers, typically with each link over unique RoCE adapters. Each link in the link group has equal characteristics, such as the same VLAN ID (if VLANs are in use), access to the same RMB(s), and access to the same TCP server/client.
SMC-Rリンクグループは、同じ2つのSMC-Rピア間のSMC-Rリンクのグループであり、通常、各リンクは一意のRoCEアダプター上にあります。リンクグループの各リンクは、同じVLAN ID（VLANが使用されている場合）、同じRMBへのアクセス、同じTCPサーバー/クライアントへのアクセスなど、同じ特性を持っています。
SMC-R Peer
SMC-Rピア
The SMC-R peer is the peer software stack within the peer operating system with respect to the Shared Memory Communications (messaging) protocol.
SMC-Rピアは、共有メモリ通信（メッセージング）プロトコルに関するピアオペレーティングシステム内のピアソフトウェアスタックです。
SMC-R Rendezvous
SMC-Rランデブー
SMC-R Rendezvous is the SMC-R peer discovery and handshake sequence that occurs transparently over the IP (Ethernet) fabric during and immediately after the TCP connection three-way handshake by exchanging the SMC-R capabilities and credentials using experimental TCP option and CLC messages.
SMC-R Rendezvousは、実験的なTCPオプションとCLCを使用してSMC-R機能と資格情報を交換することにより、TCP接続の3ウェイハンドシェイク中および直後にIP（イーサネット）ファブリックを介して透過的に発生するSMC-Rピア検出およびハンドシェイクシーケンスです。メッセージ。
RoCE SendMsg
RoCE SendMsg
RoCE SendMsg is a send operation posted to a reliably connected queue pair with inline data, for the purpose of transferring control information between peers.
RoCE SendMsgは、ピア間で制御情報を転送する目的で、インラインデータを使用して確実に接続されたキューペアに送信される送信操作です。
TCP Client
TCPクライアント
The TCP client is the TCP socket-based peer that initiates a TCP connection.
TCPクライアントは、TCP接続を開始するTCPソケットベースのピアです。
TCP Server
TCPサーバー
The TCP server is the TCP socket-based peer that accepts a TCP connection.
TCPサーバーは、TCP接続を受け入れるTCPソケットベースのピアです。
CLC Messages
CLCメッセージ
The SMC-R protocol defines a set of Connection Layer Control messages that flow over the TCP connection that are used to manage SMC-R link rendezvous at TCP connection setup time. This mechanism is analogous to SSL setup messages.
SMC-Rプロトコルは、TCP接続のセットアップ時にSMC-Rリンクランデブーを管理するために使用される、TCP接続を介して流れる一連の接続層制御メッセージを定義します。このメカニズムは、SSLセットアップメッセージに似ています。
LLC Commands
LLCコマンド
The SMC-R protocol defines a set of RoCE Link Layer Control commands that flow over the RoCE fabric using RoCE SendMsg, that are used to manage SMC-R links, SMC-R link groups, and SMC-R link group RMB expansion and contraction.
SMC-Rプロトコルは、RoCE SendMsgを使用してRoCEファブリック上を流れる一連のRoCEリンク層制御コマンドを定義します。これらのコマンドは、SMC-Rリンク、SMC-Rリンクグループ、およびSMC-RリンクグループのRMB拡張および縮小を管理するために使用されます。
CDC Message
CDCメッセージ
The SMC-R protocol defines a Connection Data Control message that flows over the RoCE fabric using RoCE SendMsg that is used to manage the SMC-R connection data. This message provides information about data being transferred over the out-of-band RDMA connection, such as data cursors, sequence numbers, and data flags (for example, urgent data). The receipt of this message also provides an interrupt to inform the receiver that it has received RDMA data.
SMC-Rプロトコルは、SMC-R接続データの管理に使用されるRoCE SendMsgを使用してRoCEファブリックを流れる接続データ制御メッセージを定義します。このメッセージは、データカーソル、シーケンス番号、データフラグ（緊急データなど）など、帯域外RDMA接続を介して転送されるデータに関する情報を提供します。このメッセージを受信すると、RDMAデータを受信したことを受信者に通知するための割り込みも提供されます。
RMB
人民元
A Remote (RDMA) Memory Buffer is a fixed or pinned buffer allocated in each of the peer hosts for a TCP (via SMC-R) connection. The RMB is registered to the RNIC and allows remote access by the remote peer using RDMA semantics. Each host is passed the peer's RMB-specific access information (RMB Key (RKey) and RMB element offset) during the SMC-R Rendezvous process. The host stores socket application user data directly into the peer's RMB using RDMA over RoCE.
リモート（RDMA）メモリーバッファーは、TCP（SMC-R経由）接続用の各ピアホストに割り当てられた固定または固定されたバッファーです。 RMBはRNICに登録され、RDMAセマンティクスを使用してリモートピアによるリモートアクセスを許可します。各ホストには、SMC-Rランデブープロセス中にピアのRMB固有のアクセス情報（RMBキー（RKey）およびRMB要素のオフセット）が渡されます。ホストは、RoCE over RoCEを使用して、ソケットアプリケーションのユーザーデータをピアのRMBに直接保存します。
RToken
Rとけん
The RToken is the combination of an RMB's RKey and RDMA virtual address. An RToken provides RMB addressability information to an RDMA peer.
RTokenは、RMBのRKeyおよびRDMA仮想アドレスの組み合わせです。 RTokenは、RMBピアにRMBアドレス可能度情報を提供します。
RMBE
RMBE
The Remote Memory Buffer Element (RMBE) is an area of an RMB that is allocated to a specific TCP connection. The RMBE contains data for the TCP connection. The RMBE represents the TCP receive buffer, whereby the remote peer writes into the RMBE and the local peer reads from the local RMBE. The alert token resolves to a specific RMBE.
リモートメモリバッファエレメント（RMBE）は、特定のTCP接続に割り当てられるRMBの領域です。 RMBEには、TCP接続のデータが含まれています。 RMBEはTCP受信バッファを表します。これにより、リモートピアがRMBEに書き込み、ローカルピアがローカルRMBEから読み取ります。アラートトークンは特定のRMBEに解決されます。
Alert Token
アラートトークン
The SMC-R alert token is a 4-byte value that uniquely identifies the TCP connection over an SMC-R connection. The alert token allows the SMC peer to quickly identify the target TCP connection that now has new work. The format of the token is defined by the owning SMC-R endpoint and is considered opaque to the remote peer. However, the token should not simply be an index to an RMBE; it should reference a TCP connection and be able to be validated to avoid reading data from stale connections.
SMC-Rアラートトークンは、SMC-R接続上のTCP接続を一意に識別する4バイトの値です。アラートトークンにより、SMCピアは、新しい作業が行われたターゲットTCP接続をすばやく識別できます。トークンの形式は、所有するSMC-Rエンドポイントによって定義され、リモートピアに対して不透明と見なされます。ただし、トークンは単にRMBEへのインデックスであってはなりません。 TCP接続を参照し、古くなった接続からのデータの読み取りを回避するために検証できる必要があります。
RNIC
RNIC
The RDMA-capable Network Interface Card (RNIC) is an Ethernet NIC that supports RDMA semantics and verbs using RoCE.
RDMA対応のネットワークインターフェイスカード（RNIC）は、RoCEを使用したRDMAセマンティクスと動詞をサポートするイーサネットNICです。
First Contact
第一接触
"First contact" describes an SMC-R negotiation to set up the first link in a link group.
「最初の連絡先」は、リンクグループ内の最初のリンクを設定するためのSMC-Rネゴシエーションについて説明しています。
Subsequent Contact
次の連絡先
"Subsequent contact" describes an SMC-R negotiation between peers who are using an already-existing SMC-R link group.
「後続の連絡先」は、既存のSMC-Rリンクグループを使用しているピア間のSMC-Rネゴシエーションについて説明しています。
In the rendezvous flow diagrams, dashed lines (----) are used to
indicate flows over the TCP/IP fabric and dotted lines (....) are
used to indicate flows over the RoCE fabric.
In the data transfer ladder diagrams, dashed lines (----) are used to
indicate RDMA write operations and dotted lines (....) are used to
indicate CDC messages, which are RDMA messages with inline data that
contain control information for the connection.
An SMC-R link is based on reliably connected queue pairs (QPs) that form a "logical point-to-point link" between the two SMC-R peers over a RoCE fabric. An SMC-R link extends from SMC-R peer to SMC-R peer, where typically each peer would be a TCP/IP stack and would reside on separate hosts.
SMC-Rリンクは、RoCEファブリック上の2つのSMC-Rピア間で「論理ポイントツーポイントリンク」を形成する、確実に接続されたキューペア（QP）に基づいています。 SMC-Rリンクは、SMC-RピアからSMC-Rピアに拡張されます。通常、各ピアはTCP / IPスタックであり、別々のホストに存在します。
,,.--..,_
+----+ _-`` `-, +-----+
|QP 8| - RoCE ', |QP 64|
| | / VLAN M . | |
+----+--------+/ \+-------+-----+
| RNIC 1 | SMC-R Link | RNIC 2 |
| |<--------------------->| |
+------------+ , /+------------+
MAC A (GID A) MAC B (GID B)
. .`
`', ,-`
``''--''``
Figure 1: SMC-R Link Overview
図1：SMC-Rリンクの概要
Figure 1 illustrates an overview of the basic concepts of SMC-R peer-to-peer connectivity; this is called the SMC-R link. The SMC-R link forms a logical point-to-point connection between two SMC-R peers via RoCE. The SMC-R link is defined and identified by the following attributes:
図1は、SMC-Rピアツーピア接続の基本概念の概要を示しています。これはSMC-Rリンクと呼ばれます。 SMC-Rリンクは、RoCEを介して2つのSMC-Rピア間の論理的なポイントツーポイント接続を形成します。 SMC-Rリンクは、次の属性によって定義および識別されます。
SMC-R link = RC QPs (source VMAC GID QP + target VMAC GID QP + VLAN ID)
SMC-Rリンク= RC QP（ソースVMAC GID QP +ターゲットVMAC GID QP + VLAN ID）
The SMC-R link can optionally be associated with a VLAN ID. If VLANs are in use for the associated IP (LAN) connection, then the VLAN attribute is carried over on the SMC-R link. When VLANs are in use, each SMC-R link group is associated with a single and specific VLAN. The RoCE fabric is the same physical Ethernet LAN used for standard TCP/IP-over-Ethernet communications, with switches as described in Section 1.1.1.
SMC-Rリンクは、オプションでVLAN IDに関連付けることができます。関連するIP（LAN）接続にVLANが使用されている場合、VLAN属性はSMC-Rリンクに引き継がれます。 VLANが使用されている場合、各SMC-Rリンクグループは単一の特定のVLANに関連付けられます。 RoCEファブリックは、標準のTCP / IP-over-Ethernet通信に使用されるものと同じ物理イーサネットLANであり、セクション1.1.1で説明されているスイッチを備えています。
An SMC-R link is designed to support multiple TCP connections between the same two peers. An SMC-R link is intended to be long lived, while the underlying TCP connections can dynamically come and go. The associated RMBs can also be dynamically added and removed from the link as needed. The first TCP connection between the peers establishes the SMC-R link. Subsequent TCP connections then use the previously established link. When the last TCP connection terminates, the link can then be terminated, typically after an implementation-defined idle timeout period has elapsed. The TCP server is responsible for initiating and terminating the SMC-R link.
SMC-Rリンクは、同じ2つのピア間の複数のTCP接続をサポートするように設計されています。 SMC-Rリンクは、根本的なTCP接続が動的に行き来できる一方で、長寿命を意図しています。関連するRMBは、必要に応じて動的にリンクに追加したり、リンクから削除したりすることもできます。ピア間の最初のTCP接続は、SMC-Rリンクを確立します。その後のTCP接続では、以前に確立されたリンクが使用されます。最後のTCP接続が終了すると、通常は実装定義のアイドルタイムアウト期間が経過した後、リンクを終了できます。 TCPサーバーは、SMC-Rリンクの開始と終了を担当します。
Figure 2 shows the hosts -- Hosts X and Y -- and their associated RMBs within each host. With the SMC-R link, and the associated RKeys and RDMA virtual addresses, each SMC-R-enabled TCP/IP stack can remotely access its peer's RMBs using RDMA. The RKeys and virtual addresses are exchanged during the rendezvous processing when the link is established. The combination of the RKey and the virtual address is the RToken. Note that the SMC-R link ends at the QP providing access to the RMB (via the link + RToken).
図2は、ホスト（ホストXおよびY）と、各ホスト内のそれらに関連付けられたRMBを示しています。 SMC-Rリンク、および関連するRKeyとRDMA仮想アドレスにより、SMC-R対応の各TCP / IPスタックは、RDMAを使用してピアのRMBにリモートアクセスできます。 RKeyと仮想アドレスは、リンクが確立されるランデブ処理中に交換されます。 RKeyと仮想アドレスの組み合わせはRTokenです。 SMC-Rリンクは、（リンク+ RTokenを介して）RMBへのアクセスを提供するQPで終了することに注意してください。
Host X Host Y
+-------------------+ ,.--.,_ +-------------------+
| | .'` '. | |
| Protection | ,' `, | Protection |
| Domain X | / \ | Domain Y |
| +------+ / \ +------+ |
| QP 8 |RNIC 1| | SMC-R Link | |RNIC 2| QP 64 |
| | | |<-------------------->| | | |
| | | || || | | |
| | +------+| VLAN A |+------+ | |
| | || || | |
| | | | RoCE | | | |
| |RToken X | \ / |RToken Y | |
| | | \ / | | |
| V | `. ,' | V |
| +--------+ | '._ ,' | +--------+ |
| | | | `''-'`` | | | |
| | RMB | | | | RMB | |
| | | | | | | |
| +--------+ | | +--------+ |
+-------------------+ +-------------------+
Figure 2: SMC-R Link and RMBs
図2：SMC-RリンクとRMB
An SMC-R link can support multiple RMBs that are independently managed by each peer. The number and the size of RMBs are managed by the peers based on the host's unique memory management requirements; however, the maximum number of RMBs that can be associated to a link group on one peer is 255. The QP has a single protection domain, but each RMB has a unique RToken. All RTokens must be exchanged with the peer.
SMC-Rリンクは、各ピアによって個別に管理される複数のRMBをサポートできます。 RMBの数とサイズは、ホストの一意のメモリ管理要件に基づいてピアによって管理されます。ただし、1つのピアのリンクグループに関連付けることができるRMBの最大数は255です。QPには単一の保護ドメインがありますが、各RMBには一意のRTokenがあります。すべてのRTokenをピアと交換する必要があります。
Each peer manages the RMBs in its local memory for its remote SMC-R peer by sharing access to the RMBs via RTokens with its peers. The remote peer writes into the RMBs via RDMA, and the local peer (RMB owner) then reads from the RMBs.
各ピアは、RTokenを介してRMBへのアクセスをピアと共有することにより、リモートSMC-Rピアのローカルメモリ内のRMBを管理します。リモートピアはRDMA経由でRMBに書き込み、ローカルピア（RMB所有者）はRMBから読み取ります。
When two peers decide to use SMC-R for a given TCP connection, they each allocate a local RMB element for the TCP connection and communicate the location of this local RMB element during rendezvous processing. To that end, RMB elements are created in pairs, with one RMB element allocated locally on each peer of the SMC-R link.
2つのピアが特定のTCP接続にSMC-Rを使用することを決定すると、それぞれがTCP接続にローカルRMB要素を割り当て、ランデブー処理中にこのローカルRMB要素の場所を伝えます。そのために、RMB要素はペアで作成され、SMC-Rリンクの各ピアにローカルに1つのRMB要素が割り当てられます。
--- +------------+---------------+
/\ |Eye Catcher | |
| +------------+ |
| | |
RMB Element 1 | |
| | Receive Buffer |
| | |
| | |
\/ | |
--- +------------+---------------+
/\ |Eye Catcher | |
| +------------+ |
| | |
RMB Element 2 | |
| | Receive Buffer |
| | |
| | |
\/ | |
--- +----------------------------+
| . |
| . |
| . |
| . |
| (up to 255 elements) |
+----------------------------+
Figure 3: RMB Format
図3：RMBフォーマット
Figure 3 illustrates the basic format of an RMB. The RMB is a virtual memory buffer whose backing real memory is pinned, which can support up to 255 TCP connections to exactly one remote SMC-R peer. Each RMB is therefore associated with the SMC-R links within a link group for the two peers and a specific RoCE Protection Domain. Other than the two peers identified by the SMC-R link, no other SMC-R peers can have RDMA access to an RMB; this requires a unique Protection Domain for every SMC-R link. This is critical to ensure integrity of SMC-R communications.
図3は、RMBの基本フォーマットを示しています。 RMBは、バッキング実メモリーが固定されている仮想メモリー・バッファーであり、正確に1つのリモートSMC-Rピアへの最大255個のTCP接続をサポートできます。したがって、各RMBは、2つのピアのリンクグループ内のSMC-Rリンクと特定のRoCE保護ドメインに関連付けられます。 SMC-Rリンクによって識別される2つのピアを除いて、他のSMC-RピアはRMBへのRDMAアクセスを持つことができません。これには、SMC-Rリンクごとに一意の保護ドメインが必要です。これは、SMC-R通信の整合性を確保するために重要です。
RMBs are subdivided into multiple elements for efficiency, with each RMB Element (RMBE) associated with a single TCP connection. Therefore, multiple TCP connections across an SMC-R link group can share the same memory for RDMA purposes, reducing the overhead of having to register additional memory with the RNIC for every new TCP connection. The number of elements in an RMB and the size of each RMBE are entirely governed by the owning peer, subject to the SMC-R architecture rules; however, all RMB elements within a given RMB must be the same size. Each peer can decide the level of resource-sharing that is desirable across TCP connections based on local constraints, such as available system memory. An RMB element is identified to the remote SMC-R peer via an RMB Element Token, which consists of the following:
RMBは、効率を上げるために複数の要素に分割され、各RMB要素（RMBE）は単一のTCP接続に関連付けられています。したがって、SMC-Rリンクグループ全体の複数のTCP接続は、RDMAの目的で同じメモリを共有でき、新しいTCP接続ごとにRNICに追加のメモリを登録する必要があるオーバーヘッドを削減します。 RMBの要素数と各RMBEのサイズは、SMC-Rアーキテクチャルールに従って、所有ピアによって完全に管理されます。ただし、指定されたRMB内のすべてのRMB要素は同じサイズでなければなりません。各ピアは、使用可能なシステムメモリなどのローカル制約に基づいて、TCP接続全体で望ましいリソース共有のレベルを決定できます。 RMB要素は、以下で構成されるRMB要素トークンを介してリモートSMC-Rピアに識別されます。
o RMB RToken: The combination of the RKey and virtual address provided by the RNIC that identifies the start of the RMB for RDMA operations.
o RMB RToken：RDMA操作のRMBの開始を識別する、RNICによって提供されるRKeyと仮想アドレスの組み合わせ。
o RMB Index: Identifies the RMB element index in the RMB. Used to locate a specific RMB element within an RMB. Valid value range is 1-255.
o RMBインデックス：RMB内のRMB要素インデックスを識別します。 RMB内の特定のRMB要素を見つけるために使用されます。有効な値の範囲は1〜255です。
o RMB Element Length: The length of the RMB element's eye catcher plus the length of the receive buffer. This length is equal for all RMB elements in a given RMB. This length can be variable across different RMBs.
o RMBエレメントの長さ：RMBエレメントのアイキャッチャーの長さに受信バッファーの長さを加えた長さ。この長さは、指定されたRMBのすべてのRMB要素で同じです。この長さは、さまざまなRMBで可変です。
Multiple RMBs can be associated to an SMC-R link group, and each peer in an SMC-R link group manages allocation of its RMBs. RMB allocation can be asymmetric. For example, Server X can allocate two RMBs to an SMC-R link group while Server Y allocates five. This provides maximum implementation flexibility to allow hosts to optimize RMB management for their own local requirements. The maximum number of RMBs that can be allocated on one peer to a link group is 255. If more RMBs are required, the peer may fall back to IP for subsequent connections or, if the peer is the server, create a parallel link group.
複数のRMBをSMC-Rリンクグループに関連付けることができ、SMC-Rリンクグループの各ピアがそのRMBの割り当てを管理します。 RMBの割り当ては非対称にすることができます。たとえば、サーバーXはSMC-Rリンクグループに2つのRMBを割り当てることができ、サーバーYは5つを割り当てます。これにより、実装の柔軟性が最大限に高まり、ホストはローカルの要件に合わせてRMB管理を最適化できます。 1つのピアでリンクグループに割り当てることができるRMBの最大数は255です。さらに多くのRMBが必要な場合、ピアは後続の接続のためにIPにフォールバックするか、ピアがサーバーの場合は並列リンクグループを作成します。
One use case for multiple RMBs is multiple receive buffer sizes. Since every element in an RMB must be the same size, multiple RMBs with different element sizes can be allocated if varying receive buffer sizes are required.
複数のRMBの使用例の1つは、複数の受信バッファーサイズです。 RMB内のすべてのエレメントは同じサイズでなければならないため、さまざまな受信バッファーサイズが必要な場合は、エレメントサイズが異なる複数のRMBを割り当てることができます。
Also, since the maximum number of TCP connections whose receive buffers can be allocated to an RMB is 255, multiple RMBs may be required to provide capacity for large numbers of TCP connections between two peers.
また、RMBに受信バッファーを割り当てることができるTCP接続の最大数は255であるため、2つのピア間の多数のTCP接続に容量を提供するには、複数のRMBが必要になる場合があります。
Separately from the RMB, the TCP/IP stack that owns each RMB maintains control data for each RMB element within its local control structures. The control data contains flags for maintaining the state of the TCP data (for example, urgent data indicator) and, most importantly, the following two cursors, which are illustrated below in Figure 4:
RMBとは別に、各RMBを所有するTCP / IPスタックは、ローカル制御構造内の各RMB要素の制御データを維持します。制御データには、TCPデータの状態を維持するためのフラグ（たとえば、緊急データインジケーター）と、最も重要なのは、以下の図4に示す2つのカーソルです。
o The peer producer cursor: This is a wrapping offset into the RMB element's receive buffer that points to the next byte of data to be written by the remote peer. This cursor is provided by the remote peer in a Connection Data Control (CDC) message, which is sent using RoCE SendMsg processing, and tells the local peer how far it can consume data in the RMBE buffer.
o ピアプロデューサーカーソル：これは、リモートピアによって書き込まれるデータの次のバイトを指す、RMB要素の受信バッファーへの折り返しオフセットです。このカーソルは、RoCE SendMsg処理を使用して送信される接続データ制御（CDC）メッセージでリモートピアによって提供され、RMBEバッファー内のデータを消費できる距離をローカルピアに通知します。
o The peer consumer cursor: This is a wrapping offset into the remote peer's RMB element's receive buffer that points to the next byte of data to be consumed by the remote peer in its own RMBE. The local peer cannot write into the remote peer's RMBE beyond this point without causing data loss. This cursor is also provided by the peer using a Connection Data Control message.
o ピアコンシューマカーソル：これは、リモートピアが自身のRMBEで消費するデータの次のバイトを指す、リモートピアのRMB要素の受信バッファへの折り返しオフセットです。ローカルピアは、データの損失を引き起こすことなく、このポイントを超えてリモートピアのRMBEに書き込むことはできません。このカーソルは、接続データ制御メッセージを使用してピアからも提供されます。
Each TCP connection peer maintains its cursors for a TCP connection's RMBE in its local control structures. In other words, the peer who writes into a remote peer's RMBE provides its producer cursor to the peer whose RMBE it has written into. The peer who reads from its RMBE provides its consumer cursor to the writing peer. In this manner, the reads and writes between peers are kept coordinated.
各TCP接続ピアは、ローカル制御構造でTCP接続のRMBEのカーソルを維持します。つまり、リモートピアのRMBEに書き込むピアは、RMBEを書き込んだピアにプロデューサーカーソルを提供します。 RMBEから読み取るピアは、コンシューマカーソルを書き込みピアに提供します。このようにして、ピア間の読み取りと書き込みが調整されます。
For example, referring to Figure 4, Peer B writes the hashed data into the receive buffer of Peer A's RMBE. After that write completes, Peer B uses a CDC message to update its producer cursor to Peer A, to indicate to Peer A how much data is available for Peer A to consume. The CDC message that Peer B sends to Peer A wakes up Peer A and notifies it that there is data to be consumed.
たとえば、図4を参照すると、ピアBはハッシュされたデータをピアAのRMBEの受信バッファに書き込みます。その書き込みが完了すると、ピアBはCDCメッセージを使用して、プロデューサーカーソルをピアAに更新し、ピアAが消費できるデータ量をピアAに示します。ピアBがピアAに送信するCDCメッセージは、ピアAを起動し、消費するデータがあることを通知します。
Similarly, when Peer A consumes data written by Peer B, it uses a CDC message to update its consumer cursor to Peer B to let Peer B know how much data it has consumed, so Peer B knows how much space is available for further writes. If Peer B were to write enough data to Peer A that it would wrap the RMBE receive buffer and exceed the consumer cursor, data loss would result.
同様に、ピアAは、ピアBによって書き込まれたデータを使用する場合、CDCメッセージを使用して、そのコンシューマーカーソルをピアBに更新し、ピアBに消費したデータ量を通知します。これにより、ピアBは、以降の書き込みに使用できる容量を認識します。ピアBがピアAに十分なデータを書き込んで、RMBE受信バッファーをラップし、コンシューマーカーソルを超えると、データが失われます。
Note that this is a simplistic description of the control flows, and they are optimized to minimize the number of CDC messages required, as described in Section 4.7 ("RMB Data Flows").
これは制御フローの簡単な説明であり、セクション4.7（「RMBデータフロー」）で説明されているように、必要なCDCメッセージの数を最小限に抑えるように最適化されていることに注意してください。
Peer A's RMBE Control Info Peer B's RMBE Control Info
+--------------------------+ +--------------------------+
| | | |
/----Peer producer cursor | +-----+-Peer consumer cursor |
/| | | | |
| +--------------------------+ | +--------------------------+
| Peer A's RMBE |
| +--------------------------+ |
| | +------------------+
| | | |
| | \/ |
| | +------------|
| |-------------+/////////// |
| |//RDMA data written by ///|
| |/// Peer B that is ////// |
| |/available to be consumed/|
| |///////////////////////// |
| |///////// +---------------|
| |----------+/\ |
| | | |
\| | |
\ / |
|\---------/ |
| |
| |
Figure 4: RMBE Cursors
図4：RMBEカーソル
Additional flags and indicators are communicated between peers. In all cases, these flags and indicators are updated by the peer using CDC messages, which are sent using RoCE SendMsg. More details on these additional flags and indicators are described in Section 4.3 ("RMBE Control Information").
追加のフラグとインジケーターがピア間で通信されます。すべての場合において、これらのフラグとインジケーターは、RoCE SendMsgを使用して送信されるCDCメッセージを使用してピアによって更新されます。これらの追加のフラグとインジケータの詳細については、セクション4.3（「RMBE制御情報」）で説明します。
SMC-R links are logically grouped together to form an SMC-R link group. The purpose of the link group is for supporting multiple links between the same two peers to provide for:
SMC-Rリンクは論理的にグループ化され、SMC-Rリンクグループを形成します。リンクグループの目的は、同じ2つのピア間の複数のリンクをサポートして、以下を提供することです。
o Resilience: Provides transparent and dynamic switching of the link used by existing TCP connections during link failures, typically hardware related. TCP traffic using the failing link can be switched to an active link within the link group, thereby avoiding disruptions to application workloads.
o 回復力：リンク障害時に既存のTCP接続によって使用されるリンクの透過的で動的な切り替えを提供します。通常、ハードウェアに関連しています。障害のあるリンクを使用するTCPトラフィックは、リンクグループ内のアクティブリンクに切り替えることができるため、アプリケーションのワークロードの中断を回避できます。
o Link utilization: Provides an active/active link usage model allowing TCP traffic to be balanced across the links, which increases bandwidth and also avoids hardware imbalances and bottlenecks. Note that both adapter and switch utilization can become potential resource constraint issues.
o リンク使用率：アクティブ/アクティブリンクの使用モデルを提供し、TCPトラフィックをリンク間で分散できるようにします。これにより、帯域幅が増加し、ハードウェアの不均衡とボトルネックも回避されます。アダプターとスイッチの両方の使用率が潜在的なリソース制約の問題になる可能性があることに注意してください。
SMC-R link group support is required. Resilience is not optional. However, the user can elect to provision a single RNIC (on one or both hosts).
SMC-Rリンクグループのサポートが必要です。回復力はオプションではありません。ただし、ユーザーは（一方または両方のホストで）単一のRNICをプロビジョニングすることを選択できます。
Multiple links that are formed between the same two peers fall into two distinct categories:
同じ2つのピア間で形成される複数のリンクは、2つの異なるカテゴリに分類されます。
1. Equal Links: Links providing equal access to the same RMB(s) at both endpoints, whereby all TCP connections associated with the links must have the same VLAN ID and have the same TCP server and TCP client roles or relationship.
1. 等しいリンク：両方のエンドポイントで同じRMBへの等しいアクセスを提供するリンク。これにより、リンクに関連付けられたすべてのTCP接続は、同じVLAN IDを持ち、同じTCPサーバーとTCPクライアントの役割または関係を持つ必要があります。
2. Unequal Links: Links providing access to unique, unrelated and isolated RMB(s) (i.e., for unique VLANs or unique and isolated application workloads, etc.) or having unique TCP server or client roles.
2. 等しくないリンク：一意で無関係で分離されたRMBへのアクセスを提供するリンク（つまり、一意のVLANまたは一意で分離されたアプリケーションワークロードなど）、または一意のTCPサーバーまたはクライアントの役割を持つリンク。
Links that are logically grouped together forming an SMC-R link group must be equal links.
SMC-Rリンクグループを形成する論理的にグループ化されたリンクは、等しいリンクである必要があります。
Equal links within a link group also have another "Link Group Type" attribute based on the link's associated underlying physical path. The following SMC-R link types are defined:
リンクグループ内の同等のリンクには、リンクに関連付けられた基礎となる物理パスに基づく別の「リンクグループタイプ」属性もあります。次のSMC-Rリンクタイプが定義されています。
1. Single link: the only active link within a link group
1. 単一リンク：リンクグループ内の唯一のアクティブなリンク
2. Parallel link: not allowed -- SMC-R links having the same physical RNIC at both hosts
2. 並列リンク：許可されていません-両方のホストで同じ物理RNICを持つSMC-Rリンク
3. Asymmetric link: links that have unique RNIC adapters at one host but share a single adapter at the peer host
3. 非対称リンク：1つのホストに固有のRNICアダプターがあるが、ピアホストで1つのアダプターを共有するリンク
4. Symmetric link: links that have unique RNIC adapters at both hosts
4. 対称リンク：両方のホストに固有のRNICアダプターがあるリンク
These link group types are further explained in the following figures and descriptions.
これらのリンクグループタイプについては、次の図と説明で詳しく説明します。
Figure 2 above shows the single-link case. The single link illustrated in Figure 2 also establishes the SMC-R link group. Link groups are supposed to have multiple links, but when only one RNIC is available at both hosts then only a single link can be created. This is expected to be a transient case.
上記の図2は、単一リンクの場合を示しています。図2に示されている単一のリンクは、SMC-Rリンクグループも確立します。リンクグループには複数のリンクがあるはずですが、両方のホストで使用できるRNICが1つだけの場合は、1つのリンクしか作成できません。これは一時的なケースであると予想されます。
Figure 5 shows the symmetric-link case. Both hosts have unique and redundant RNIC adapters. This configuration meets the objectives for providing full RoCE redundancy required to provide the level of resilience required for high availability for SMC-R. While this configuration is not required, it is a strongly recommended "best practice" for the exploitation of SMC-R. Single and asymmetric links must be supported but are intended to provide for short-term transient conditions -- for example, during a temporary outage or recycle of an RNIC.
図5は、対称リンクの場合を示しています。どちらのホストにも、一意で冗長なRNICアダプターがあります。この構成は、SMC-Rの高可用性に必要なレベルの復元力を提供するために必要な完全なRoCE冗長性を提供する目的を満たします。この構成は必須ではありませんが、SMC-Rの活用のために強く推奨される「ベストプラクティス」です。単一の非対称リンクをサポートする必要がありますが、一時的な停止やRNICのリサイクル中など、短期的な一時的な状態を提供することを目的としています。
Host X Host Y
+-------------------+ +-------------------+
| | | |
| Protection | | Protection |
| Domain X | | Domain Y |
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 64 |
|RToken X| | |<-------------------->| | | |
| | | | | | |RToken Y|
| \/ +------+ +------+ \/ |
|+--------+ | | +--------+ |
|| | | | | | |
|| RMB | | | | RMB | |
|| | | | | | |
|+--------+ | | +--------+ |
| /\ +------+ +------+ /\ |
|RToken Z| | | SMC-R Link 2 | | |RToken W|
| | |RNIC 3|<-------------------->|RNIC 4| | |
| QP 9 | | | | QP 65 |
| +------+ +------+ |
+-------------------+ +-------------------+
Figure 5: Symmetric SMC-R Links
図5：対称SMC-Rリンク
Host X Host Y
+-------------------+ +-------------------+
| | | |
| Protection | | Protection |
| Domain X | | Domain Y |
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 64 |
|RToken X| | |<-------------------->| | | |
| | | | .->| | |RToken Y|
| \/ +------+ .` +------+ \/ |
|+--------+ | .` | +--------+ |
|| | | .` | | | |
|| RMB | | .` | | RMB | |
|| | | .`SMC-R | | | |
|+--------+ | .` Link 2 | +--------+ |
| /\ +------+ .` +------+ |
|RToken Z| | | .` | |down or |
| | |RNIC 3|<-` |RNIC 4|unavailable |
| QP 9 | | | | |
| +------+ +------+ |
+-------------------+ +-------------------+
Figure 6: Asymmetric SMC-R Links
図6：非対称SMC-Rリンク
In the example provided by Figure 6, Host X has two RNICs but Host Y only has one RNIC because RNIC 4 is not available. This configuration allows for the creation of an asymmetric link. While an asymmetric link will provide some resilience (for example, when RNIC 1 fails), ideally each host should provide two redundant RNICs. This should be a transient case, and when RNIC 4 becomes available, this configuration must transition to a symmetric-link configuration. This transition is accomplished by first creating the new symmetric link and then deleting the asymmetric link with reason code "Asymmetric link no longer needed" specified in the DELETE LINK LLC message.
図6の例では、RNIC 4が使用できないため、ホストXには2つのRNICがありますが、ホストYには1つのRNICしかありません。この構成により、非対称リンクを作成できます。非対称リンクはある程度の回復力を提供しますが（たとえば、RNIC 1に障害が発生した場合）、各ホストは2つの冗長RNICを提供するのが理想的です。これは一時的なケースであり、RNIC 4が使用可能になったときに、この構成を対称リンク構成に移行する必要があります。この移行は、最初に新しい対称リンクを作成してから、DELETE LINK LLCメッセージで指定された理由コード「非対称リンクはもう必要ありません」で非対称リンクを削除することによって行われます。
Host X Host Y
+-------------------+ +-------------------+
| | | |
| Protection | | Protection |
| Domain X | | Domain Y |
| +------+ SMC-R Link 1 +------+ |
| QP 8 |RNIC 1|<-------------------->|RNIC 2| QP 64 |
|RToken X| | | | | | |
| | | |<-------------------->| | |RToken Y|
| \/ +------+ SMC-R Link 2 +------+ \/ |
|+--------+ QP 9 | | QP 65 +--------+ |
|| | | | | | | | |
|| RMB |<-- + | | +---->| RMB | |
|| | | | | | |
|+--------+ | | +--------+ |
| +------+ +------+ |
| down or| | | |down or |
| unavailable|RNIC 3| |RNIC 4|unavailable |
| | | | | |
| +------+ +------+ |
+-------------------+ +-------------------+
Figure 7: SMC-R Parallel Links (Not Supported)
図7：SMC-Rパラレルリンク（サポートされていません）
Figure 7 shows parallel links, which are two links in the link group that use the same hardware. This configuration is not permitted. Because SMC-R multiplexes multiple TCP connections over an SMC-R link and both links are using the exact same hardware, there is no additional redundancy or capacity benefit obtained from this configuration. In addition to providing no real benefit, this configuration adds the unnecessary overhead of additional queue pairs, generation of additional RKeys, etc.
図7は、同じハードウェアを使用するリンクグループ内の2つのリンクであるパラレルリンクを示しています。この構成は許可されていません。 SMC-RはSMC-Rリンクを介して複数のTCP接続を多重化し、両方のリンクがまったく同じハードウェアを使用しているため、この構成から得られる追加の冗長性や容量の利点はありません。実際のメリットはありませんが、この構成では、追加のキューペアの不要なオーバーヘッド、追加のRKeyの生成などが追加されます。
The SMC-R protocol defines a maximum of eight symmetric SMC-R links within a single SMC-R link group. This allows for support for up to eight unique physical paths between peer hosts. However, in terms of meeting the basic requirements for redundancy, support for at least two symmetric links must be implemented. Supporting more than two links also simplifies implementation for practical matters relating to dynamically adding and removing links -- for example, starting a third SMC-R link prior to taking down one of the two existing links. Recall that all links within a link group must have equal access to all associated RMBs.
SMC-Rプロトコルは、単一のSMC-Rリンクグループ内に最大8つの対称SMC-Rリンクを定義します。これにより、ピアホスト間の最大8つの一意の物理パスをサポートできます。ただし、冗長性の基本要件を満たすという点では、少なくとも2つの対称リンクのサポートを実装する必要があります。 2つを超えるリンクをサポートすると、リンクの動的な追加と削除に関連する実際的な問題の実装も簡素化されます。たとえば、既存の2つのリンクの1つを削除する前に3番目のSMC-Rリンクを開始します。リンクグループ内のすべてのリンクは、関連付けられたすべてのRMBに同等にアクセスできる必要があることを思い出してください。
The SMC-R protocol allows an implementation to assign an implementation-specific and appropriate value for maximum symmetric links. The implementation value must not exceed the architecture limit of 8; also, the value must not be lower than 2, because the SMC-R protocol requires redundancy. This does not mean that two RNICs are physically required to enable SMC-R connectivity, but at least two RNICs for redundancy are strongly recommended.
SMC-Rプロトコルを使用すると、実装は、最大対称リンクに実装固有の適切な値を割り当てることができます。実装値は、アーキテクチャの制限である8を超えてはなりません。また、SMC-Rプロトコルは冗長性を必要とするため、この値は2以上でなければなりません。これは、SMC-R接続を有効にするために2つのRNICが物理的に必要であることを意味しませんが、冗長性のために少なくとも2つのRNICを強くお勧めします。
The SMC-R peers exchange their implementation maximum link values during the link group establishment using the defined maximum link value in the CONFIRM LINK LLC command. Once the initial exchange completes, the value is set for the life of the link group. The maximum link value can be provided by both the server and client. The server must supply a value, whereas the client maximum link value is optional. When the client does not supply a value, it indicates that the client accepts the server-supplied maximum value. If the client provides a value, it cannot exceed the server-supplied maximum value. If the client passes a lower value, this lower value then becomes the final negotiated maximum number of symmetric links for this link group. Again, the minimum value is 2.
SMC-Rピアは、CONFIRM LINK LLCコマンドで定義された最大リンク値を使用して、リンクグループの確立中に実装の最大リンク値を交換します。最初の交換が完了すると、リンクグループの存続期間中の値が設定されます。最大リンク値は、サーバーとクライアントの両方で提供できます。サーバーは値を提供する必要がありますが、クライアントの最大リンク値はオプションです。クライアントが値を提供しない場合、クライアントがサーバー提供の最大値を受け入れることを示します。クライアントが値を提供する場合、サーバーが提供する最大値を超えることはできません。クライアントが低い値を渡すと、この低い値が、このリンクグループの対称リンクの最終的なネゴシエートされた最大数になります。この場合も、最小値は2です。
During run time, the client must never request that the server add a symmetric link to a link group that would exceed the negotiated maximum link value. Likewise, the server must never attempt to add a symmetric link to a link group that would exceed the negotiated maximum value.
実行時に、クライアントは、ネゴシエートされた最大リンク値を超える対称リンクをリンクグループに追加することをサーバーに要求してはなりません。同様に、サーバーは、ネゴシエートされた最大値を超える対称リンクをリンクグループに追加しないでください。
In terms of counting the number of active links within a link group, the initial link (or the only/last) link is always counted as 1. Then, as additional links are added, they are either symmetric or asymmetric links.
リンクグループ内のアクティブリンクの数をカウントすることに関して、最初のリンク（または唯一/最後）のリンクは常に1としてカウントされます。次に、追加のリンクが追加されると、それらは対称リンクまたは非対称リンクになります。
With regards to enforcing the maximum link rules, asymmetric links are an exception having a unique set of rules:
最大リンクルールの適用に関して、非対称リンクは、固有のルールセットを持つ例外です。
o Asymmetric links are always limited to one asymmetric link allowed per link group.
o 非対称リンクは常に、リンクグループごとに許可される1つの非対称リンクに制限されます。
o Asymmetric links must not be counted in the maximum symmetric-link count calculation. When tracking the current count or enforcing the negotiated maximum number of links, an asymmetric link is not to be counted.
o 非対称リンクは、対称リンクの最大数の計算に含めないでください。現在のカウントを追跡するか、ネゴシエートされたリンクの最大数を適用する場合、非対称リンクはカウントされません。
SMC-R link groups are self-defining. The first SMC-R link in a link group is created using TCP option flows on the TCP three-way handshake followed by CLC message flows over the TCP connection. Subsequent SMC-R links in the link group are created by sending LLC messages over an SMC-R link that already exists in the link group. Once an SMC-R link group is created, no additional SMC-R links in that group are created using TCP and CLC negotiation. Because subsequent SMC-R links are created exclusively by sending LLC messages over an existing SMC-R link in a link group, the membership of SMC-R links in a link group is self-defining.
SMC-Rリンクグループは自己定義型です。リンクグループの最初のSMC-Rリンクは、TCP 3ウェイハンドシェイクでTCPオプションフローを使用して作成され、その後にTCP接続を介したCLCメッセージフローが続きます。リンクグループ内の後続のSMC-Rリンクは、すでにリンクグループに存在するSMC-Rリンクを介してLLCメッセージを送信することによって作成されます。 SMC-Rリンクグループが作成されると、そのグループ内の追加のSMC-Rリンクは、TCPおよびCLCネゴシエーションを使用して作成されません。後続のSMC-Rリンクは、リンクグループの既存のSMC-Rリンクを介してLLCメッセージを送信することによって排他的に作成されるため、リンクグループのSMC-Rリンクのメンバーシップは自己定義です。
This architecture does not define a specific identifier for an SMC-R link group. This identification may be useful for network management and may be assigned in a platform-specific manner, or in an extension to this architecture.
このアーキテクチャは、SMC-Rリンクグループの特定の識別子を定義していません。この識別は、ネットワーク管理に役立ち、プラットフォーム固有の方法で、またはこのアーキテクチャの拡張で割り当てることができます。
In each SMC-R link group, one peer is the server for all TCP connections and the other peer is the client. If there are additional TCP connections between the peers that use SMC-R and have the client and server roles reversed, another SMC-R link group is set up between them with the opposite client-server relationship.
各SMC-Rリンクグループでは、1つのピアがすべてのTCP接続のサーバーであり、もう1つのピアがクライアントです。 SMC-Rを使用し、クライアントとサーバーの役割が逆になっているピア間に追加のTCP接続がある場合、別のSMC-Rリンクグループが、反対のクライアント/サーバー関係でそれらの間に設定されます。
This is required because there are specific responsibilities divided between the client and server in the management of an SMC-R link group.
これは、SMC-Rリンクグループの管理において、クライアントとサーバーの間で特定の責任が分担されているために必要です。
In this architecture, the decision of whether to use an existing SMC-R link group or create a new SMC-R link group for a TCP connection is made exclusively by the server.
このアーキテクチャでは、既存のSMC-Rリンクグループを使用するか、TCP接続用に新しいSMC-Rリンクグループを作成するかは、サーバーのみが決定します。
Management of the links in an SMC-R link group is also a server responsibility. The server is responsible for adding and deleting links in a link group. The client may request that the server take certain actions, but the final responsibility is the server's.
SMC-Rリンクグループ内のリンクの管理もサーバーの責任です。サーバーは、リンクグループ内のリンクを追加および削除します。クライアントはサーバーに特定のアクションを実行するように要求できますが、最終的な責任はサーバーの責任です。
This architecture defines multiple identifiers to identify SMC-R links and peers.
このアーキテクチャは、SMC-Rリンクとピアを識別するために複数の識別子を定義します。
o Link number: This is a 1-byte value that identifies an SMC-R link within a link group. Both the server and the client use this number to distinguish an SMC-R link from other links within the same link group. It is only unique within a link group. In order to prevent timing windows that may occur when a server creates a new link while the client is still cleaning up a previously existing link, link numbers cannot be reused until the entire link numbering space has been exhausted.
o リンク番号：これは、リンクグループ内のSMC-Rリンクを識別する1バイトの値です。サーバーとクライアントの両方がこの番号を使用して、SMC-Rリンクを同じリンクグループ内の他のリンクと区別します。リンクグループ内でのみ一意です。クライアントが既存のリンクをクリーンアップしている間にサーバーが新しいリンクを作成するときに発生する可能性のあるタイミングウィンドウを防ぐために、リンク番号付けスペース全体がなくなるまでリンク番号を再利用できません。
o Link user ID: This is an architecturally opaque 4-byte value that a peer uses to uniquely define an SMC-R link within its own space. This means that a link user ID is unique within one peer only. Each peer defines its own link user ID for a link. The peers exchange this information once during link setup, and it is never used architecturally again. The purpose of this identifier is for network management, display, and debugging. For example, an operator on a client could provide the operator on the server with the server's link user ID if he requires the server's operator to check on the operation of a link that the client is having trouble with.
o リンクユーザーID：これは、ピアが自身のスペース内でSMC-Rリンクを一意に定義するために使用する、アーキテクチャ上不透明な4バイトの値です。つまり、リンクユーザーIDは1つのピア内でのみ一意です。各ピアは、リンクの独自のリンクユーザーIDを定義します。ピアは、リンクのセットアップ中にこの情報を1回交換し、アーキテクチャで再び使用されることはありません。この識別子の目的は、ネットワーク管理、表示、およびデバッグ用です。たとえば、クライアントのオペレーターは、サーバーのオペレーターがクライアントに問題のあるリンクの操作を確認する必要がある場合、サーバーのオペレーターにサーバーのリンクユーザーIDを提供できます。
o Peer ID: The SMC-R peer ID uniquely identifies a specific instance of a specific TCP/IP stack. It is required because in clustered and load-balancing environments, an IP address does not uniquely identify a TCP/IP stack. An RNIC's MAC/GID also doesn't uniquely or reliably identify a TCP/IP stack, because RNICs can go up and down and even be redeployed to other TCP/IP stacks in a multiple-partitioned or virtualized environment. The peer ID is not only unique per TCP/IP stack but is also unique per instance of a TCP/IP stack, meaning that if a TCP/IP stack is restarted, its peer ID changes.
o ピアID：SMC-RピアIDは、特定のTCP / IPスタックの特定のインスタンスを一意に識別します。クラスター化された負荷分散環境では、IPアドレスはTCP / IPスタックを一意に識別しないため、これが必要です。また、RNICのMAC / GIDは、TCP / IPスタックを一意的または確実に識別しません。これは、RNICが上下に移動したり、複数パーティションまたは仮想化環境で他のTCP / IPスタックに再デプロイしたりできるためです。ピアIDは、TCP / IPスタックごとに一意であるだけでなく、TCP / IPスタックのインスタンスごとにも一意です。つまり、TCP / IPスタックが再起動されると、ピアIDが変更されます。
The SMC-R multilink architecture provides resilience for network high availability via failover capability to an alternate RoCE adapter.
SMC-Rマルチリンクアーキテクチャは、代替RoCEアダプターへのフェイルオーバー機能を介して、ネットワークの高可用性に回復力を提供します。
The SMC-R multilink architecture does not define primary, secondary, or alternate roles to the links. Instead, there are multiple active links representing multiple redundant RoCE paths over the same LAN.
SMC-Rマルチリンクアーキテクチャは、リンクに対するプライマリ、セカンダリ、または代替の役割を定義していません。代わりに、同じLAN上の複数の冗長RoCEパスを表す複数のアクティブリンクがあります。
Assignment of TCP connections to links is unidirectional and asymmetric. This means that the client and server may each choose a separate link for their RDMA writes associated with a specific TCP connection.
リンクへのTCP接続の割り当ては、単方向で非対称です。つまり、クライアントとサーバーはそれぞれ、特定のTCP接続に関連付けられたRDMA書き込み用に個別のリンクを選択できます。
If a hardware failure occurs or a QP failure associated with an individual link occurs, then the TCP connections that were associated with the failing link are dynamically and transparently switched to use another available link. The server or the client can detect a failure, immediately move their TCP connections, and then notify their peer via the DELETE LINK LLC command. While the client can notify the server of an apparent link failure with the DELETE LINK LLC command, the server performs the actual link deletion.
ハードウェア障害が発生した場合、または個々のリンクに関連付けられたQP障害が発生した場合、障害のあるリンクに関連付けられていたTCP接続は、別の使用可能なリンクを使用するように動的かつ透過的に切り替えられます。サーバーまたはクライアントは障害を検出し、TCP接続をすぐに移動して、DELETE LINK LLCコマンドを介してピアに通知できます。クライアントはDELETE LINK LLCコマンドで明らかなリンク障害をサーバーに通知できますが、サーバーは実際のリンク削除を実行します。
The movement of TCP connections to another link can be accomplished with minimal coordination between the peers. The TCP connection movement is also transparent to, and non-disruptive to, the TCP socket application workloads for most failure scenarios. After a failure, the surviving links and all associated hardware must handle the link group's workload.
TCP接続を別のリンクに移動するには、ピア間の調整を最小限に抑えます。 TCP接続の動きは、ほとんどの障害シナリオで、TCPソケットアプリケーションのワークロードに対して透過的であり、中断することもありません。障害発生後、残っているリンクと関連するすべてのハードウェアがリンクグループのワークロードを処理する必要があります。
As each SMC-R peer begins to move active TCP connections to another link, all current RDMA write operations must be allowed to complete. The moving peer then sends a signal to verify receipt of the last successful write by its peer. If this verification fails, the TCP connection must be reset. Once this verification is complete, all writes that failed may then be retried, in order, over the new link. Any data writes or CDC messages for which the sender did not receive write completion must be replayed before any subsequent data or CDC write operations are sent. LLC messages are not retried over the new link, because they are dependent on a known link configuration, which has just changed because of the failure. The initiator of an LLC message exchange that fails will be responsible for retrying once the link group configuration stabilizes.
各SMC-RピアがアクティブなTCP接続を別のリンクに移動し始めると、現在のすべてのRDMA書き込み操作を完了する必要があります。次に、移動ピアは信号を送信して、ピアによる最後の正常な書き込みの受信を確認します。この検証が失敗した場合は、TCP接続をリセットする必要があります。この検証が完了すると、失敗したすべての書き込みが新しいリンクで順番に再試行されます。送信者が書き込み完了を受信しなかったデータ書き込みまたはCDCメッセージは、後続のデータまたはCDC書き込み操作が送信される前に再生する必要があります。 LLCメッセージは、既知のリンク構成に依存しているため、新しいリンクでは再試行されません。既知のリンク構成は、障害のために変更されたばかりです。失敗したLLCメッセージ交換のイニシエーターは、リンクグループの構成が安定したら、再試行する責任があります。
When a new link becomes available and is re-added to the link group, each peer is free to rebalance its current TCP connections as needed or only assign new TCP connections to the newly added link. Both the server and client are free to manage TCP connections across the link group as needed. TCP connection movement does not have to be stimulated by a link failure.
新しいリンクが利用可能になり、リンクグループに再度追加されると、各ピアは現在のTCP接続を必要に応じて再調整するか、新しく追加されたリンクに新しいTCP接続のみを割り当てることができます。サーバーとクライアントの両方が、必要に応じてリンクグループ全体のTCP接続を自由に管理できます。 TCP接続の移動は、リンク障害によって引き起こされる必要はありません。
The SMC-R architecture also defines orderly versus disorderly failover. The type of failover is communicated in the LLC DELETE LINK command and is simply a means to indicate that the link has terminated (disorderly) or link termination is imminent (orderly). The orderly link deletion could be initiated via operator command or programmatically to bring down an idle link. For example, an operator command could initiate orderly shutdown of an adapter for service. Implementation of the two types is based on implementation requirements and is beyond the scope of the SMC-R architecture.
SMC-Rアーキテクチャは、秩序だったフェイルオーバーと無秩序なフェイルオーバーも定義します。フェイルオーバーのタイプは、LLC DELETE LINKコマンドで通知され、リンクが終了した（順不同）、またはリンクの終了が差し迫っていること（順不同）を示す手段にすぎません。秩序だったリンクの削除は、オペレーターコマンドを介して、またはプログラムでアイドルリンクを停止するために開始できます。たとえば、オペレータコマンドは、サービス用のアダプタの正常なシャットダウンを開始できます。 2つのタイプの実装は実装要件に基づいており、SMC-Rアーキテクチャの範囲を超えています。
"Rendezvous" is the process that SMC-R-capable peers use to dynamically discover each others' capabilities, negotiate SMC-R connections, set up SMC-R links and link groups, and manage those link groups. A key aspect of SMC-R Rendezvous is that it occurs dynamically and automatically, without requiring SMC-R link configuration to be defined by an administrator.
「ランデブー」は、SMC-R対応ピアが動的に互いの機能を発見し、SMC-R接続をネゴシエートし、SMC-Rリンクとリンクグループを設定し、それらのリンクグループを管理するために使用するプロセスです。 SMC-R Rendezvousの重要な点は、SMC-Rリンク構成を管理者が定義する必要なく、動的かつ自動的に発生することです。
SMC-R Rendezvous starts with the TCP/IP three-way handshake, during which connection peers use TCP options to announce their SMC-R capabilities. If both endpoints are SMC-R capable, then Connection Layer Control (CLC) messages are exchanged between the peers' SMC-R layers over the newly established TCP connection to negotiate SMC-R credentials. The CLC message mechanism is analogous to the messages exchanged by SSL for its handshake processing.
SMC-R Rendezvousは、TCP / IP 3ウェイハンドシェイクから始まります。この間に、接続ピアはTCPオプションを使用してSMC-R機能を通知します。両方のエンドポイントがSMC-R対応の場合、新しく確立されたTCP接続を介してピアのSMC-R層の間で接続層制御（CLC）メッセージが交換され、SMC-R資格がネゴシエートされます。 CLCメッセージメカニズムは、SSLによってハンドシェイク処理のために交換されるメッセージに類似しています。
If a new SMC-R link is being set up, Link Layer Control (LLC) messages are used to confirm RDMA connectivity. LLC messages are also used by the SMC-R layers at each peer to manage the links and link groups.
新しいSMC-Rリンクがセットアップされている場合は、Link Layer Control（LLC）メッセージを使用してRDMA接続を確認します。 LLCメッセージは、各ピアのSMC-R層でもリンクとリンクグループを管理するために使用されます。
Once an SMC-R link is set up or agreed to by the peers, the TCP sockets are passed to the peer applications, which use them as normal. The SMC-R layer, which resides under the sockets layer, transmits the socket data between peers over RDMA using the SMC-R protocol, bypassing the TCP/IP stack.
SMC-Rリンクが設定されるか、ピアによって合意されると、TCPソケットはピアアプリケーションに渡され、通常どおり使用されます。ソケット層の下にあるSMC-R層は、TCP / IPスタックをバイパスして、SMC-Rプロトコルを使用してRDMA経由でピア間でソケットデータを送信します。
During the TCP/IP three-way handshake, the client and server indicate their support for SMC-R by including experimental TCP option 254 on the three-way handshake flows, in accordance with [RFC6994] ("Shared Use of Experimental TCP Options"). The Experiment Identifier (ExID) value used is the string "SMCR" in EBCDIC (IBM-1047) encoding (0xE2D4C3D9). This ExID has been registered in the "TCP Experimental Option Experiment Identifiers (TCP ExIDs)" registry maintained by IANA.
TCP / IP 3ウェイハンドシェイク中に、クライアントとサーバーは、[RFC6994]（「実験的TCPオプションの共有使用」）に従って、3ウェイハンドシェイクフローに実験的TCPオプション254を含めることにより、SMC-Rのサポートを示します。 ）。使用される実験識別子（ExID）値は、EBCDIC（IBM-1047）エンコード（0xE2D4C3D9）のストリング「SMCR」です。このExIDは、IANAによって維持されている「TCP試験的オプションの実験識別子（TCP ExID）」レジストリに登録されています。
After completion of the three-way TCP handshake, each peer queries its peer's options. If both peers set the TCP option on the three-way handshake, inline SMC-R negotiation occurs using CLC messages. If neither peer, or only one peer, sets the TCP option, SMC-R cannot be used for the TCP connection, and the TCP connection completes the setup using the IP fabric.
3ウェイTCPハンドシェイクの完了後、各ピアはピアのオプションを照会します。両方のピアが3ウェイハンドシェイクでTCPオプションを設定した場合、インラインSMC-RネゴシエーションはCLCメッセージを使用して行われます。どちらのピアも、または1つのピアのみがTCPオプションを設定する場合、SMC-RはTCP接続に使用できず、TCP接続はIPファブリックを使用してセットアップを完了します。
CLC messages are sent as data payload over the IP network using the TCP connection between SMC-R layers at the peers. They are analogous to the messages used to exchange parameters for SSL.
CLCメッセージは、ピアのSMC-Rレイヤー間のTCP接続を使用して、IPネットワーク経由でデータペイロードとして送信されます。これらは、SSLのパラメーターを交換するために使用されるメッセージに類似しています。
The use of CLC messages is detailed in the following sections. The following list provides a summary of the defined CLC messages and their purposes:
CLCメッセージの使用については、次のセクションで詳しく説明します。以下のリストは、定義されたCLCメッセージとその目的の要約を提供します。
o SMC Proposal: Sent from the client to propose that this TCP connection is eligible to be moved to SMC-R. The client identifies itself and its subnet to the server and passes the SMC-R elements for a suggested RoCE path via the MAC and GID.
o SMCプロポーザル：このTCP接続がSMC-Rに移動する資格があることを提案するためにクライアントから送信されます。クライアントはそれ自体とそのサブネットをサーバーに識別し、推奨されるRoCEパスのSMC-R要素をMACおよびGID経由で渡します。
o SMC Accept: Sent from the server to accept the client's TCP connection SMC Proposal. The server responds to the client's proposal by identifying itself to the client and passing the elements of a RoCE path that the client can use to perform RDMA writes to the server. This consists of such SMC-R link elements as RoCE MAC, GID, and RMB information.
o SMC Accept：サーバーから送信され、クライアントのTCP接続SMC Proposalを受け入れます。サーバーは、クライアントに対して自分自身を識別し、クライアントがサーバーへのRDMA書き込みを実行するために使用できるRoCEパスの要素を渡すことによって、クライアントの提案に応答します。これは、RoCE MAC、GID、およびRMB情報などのSMC-Rリンク要素で構成されます。
o SMC Confirm: Sent from the client to confirm the server's acceptance of the SMC connection. The client responds to the server's acceptance by passing the elements of a RoCE path that the server can use to perform RDMA writes to the client. This consists of such SMC-R link elements as RoCE MAC, GID, and RMB information.
o SMC確認：サーバーがSMC接続を受け入れたことを確認するためにクライアントから送信されます。クライアントは、サーバーがクライアントへのRDMA書き込みを実行するために使用できるRoCEパスの要素を渡すことにより、サーバーの受け入れに応答します。これは、RoCE MAC、GID、およびRMB情報などのSMC-Rリンク要素で構成されます。
o SMC Decline: Sent from either the server or the client to reject the SMC connection, indicating the reason the peer must decline the SMC Proposal and allowing the TCP connection to revert back to IP connectivity.
o SMC拒否：SMC接続を拒否するためにサーバーまたはクライアントから送信され、ピアがSMCプロポーザルを拒否する必要がある理由を示し、TCP接続がIP接続に戻ることを許可します。
Link Layer Control (LLC) messages are sent between peer SMC-R layers over an SMC-R link to manage the link or the link group. LLC messages are sent using RoCE SendMsg and are 44 bytes long. The 44-byte size is based on what can fit into a RoCE Work Queue Element (WQE) without requiring the posting of receive buffers.
リンク層制御（LLC）メッセージは、SMC-Rリンクを介してピアSMC-R層の間で送信され、リンクまたはリンクグループを管理します。 LLCメッセージはRoCE SendMsgを使用して送信され、長さは44バイトです。 44バイトのサイズは、受信バッファーの通知を必要とせずにRoCEワークキューエレメント（WQE）に収まるサイズに基づいています。
LLC messages generally follow a request-reply semantic. Each message has a request flavor and a reply flavor, and each request must be confirmed with a reply, except where otherwise noted. The use of LLC messages is detailed in the following sections. The following list provides a summary of the defined LLC messages and their purposes:
LLCメッセージは通常、要求と応答のセマンティックに従います。各メッセージにはリクエストフレーバーと返信フレーバーがあり、特に明記されていない限り、各リクエストは返信で確認する必要があります。 LLCメッセージの使用については、次のセクションで詳しく説明します。以下のリストは、定義されたLLCメッセージとその目的の要約を示しています。
o ADD LINK: Used to add a new link to a link group. Sent from the server to the client to initiate addition of a new link to the link group, or from the client to the server to request that the server initiate addition of a new link.
o リンクの追加：リンクグループに新しいリンクを追加するために使用します。リンクグループへの新しいリンクの追加を開始するためにサーバーからクライアントに送信されるか、サーバーが新しいリンクの追加を開始することを要求するためにクライアントからサーバーに送信されます。
o ADD LINK CONTINUATION: A continuation of ADD LINK that allows the ADD LINK to span multiple commands, because all of the link information cannot be contained in a single ADD LINK message.
o ADD LINK CONTINUATION：すべてのリンク情報を単一のADD LINKメッセージに含めることができないため、ADD LINKが複数のコマンドにまたがることを可能にするADD LINKの続き。
o CONFIRM LINK: Used to confirm that RoCE connectivity over a newly created SMC-R link is working correctly. Initiated by the server. Both this message and its reply must flow over the SMC-R link being confirmed.
o CONFIRM LINK：新しく作成されたSMC-Rリンクを介したRoCE接続が正しく機能していることを確認するために使用されます。サーバーによって開始されます。このメッセージとその応答の両方が、確認中のSMC-Rリンク上を流れる必要があります。
o DELETE LINK: When initiated by the server, deletes a specific link from the link group or deletes the entire link group. When initiated by the client, requests that the server delete a specific link or the entire link group.
o リンクの削除：サーバーによって開始されると、リンクグループから特定のリンクを削除するか、リンクグループ全体を削除します。クライアントによって開始されると、サーバーが特定のリンクまたはリンクグループ全体を削除するように要求します。
o CONFIRM RKEY: Informs the peer on the SMC-R link of the addition of an RMB to the link group.
o CONFIRM RKEY：RMCがリンクグループに追加されたことをSMC-Rリンク上のピアに通知します。
o CONFIRM RKEY CONTINUATION: A continuation of CONFIRM RKEY that allows the CONFIRM RKEY to span multiple commands, in the event that all of the information cannot be contained in a single CONFIRM RKEY message.
o CONFIRM RKEY CONTINUATION：すべての情報を単一のCONFIRM RKEYメッセージに含めることができない場合に、CONFIRM RKEYが複数のコマンドにまたがることを可能にするCONFIRM RKEYの続き。
o DELETE RKEY: Informs the peer on the SMC-R link of the deletion of one or more RMBs from the link group.
o DELETE RKEY：SMC-Rリンク上のピアに、リンクグループからの1つ以上のRMBの削除を通知します。
o TEST LINK: Verifies that an already-active SMC-R link is active and healthy.
o テストリンク：すでにアクティブなSMC-Rリンクがアクティブで正常であることを確認します。
o Optional LLC message: Any LLC message in which the two high-order bits of the opcode are b'10'. This optional message must be silently discarded by a receiving peer that does not support the opcode. No such messages are defined in this version of the architecture; however, the concept is defined to allow for toleration of possible advanced, optional functions.
o オプションのLLCメッセージ：オペコードの上位2ビットがb'10 'であるLLCメッセージ。このオプションのメッセージは、オペコードをサポートしていない受信側ピアによって静かに破棄される必要があります。このバージョンのアーキテクチャでは、そのようなメッセージは定義されていません。ただし、考えられる高度でオプションの機能を許容できるように概念が定義されています。
CONFIRM LINK and TEST LINK are sensitive to which link they flow on and must flow on the link being confirmed or tested. The other flows may flow over any active link in the link group. When there are multiple links in a link group, a response to an LLC message must flow over the same link that the original message flowed over, with the following exceptions:
CONFIRM LINKとTEST LINKは、それらがどのリンク上を流れるかに敏感であり、確認またはテストされるリンク上を流れる必要があります。他のフローは、リンクグループ内の任意のアクティブリンク上を流れる場合があります。リンクグループに複数のリンクがある場合、LLCメッセージへの応答は、次の例外を除いて、元のメッセージが流れたリンクと同じリンクを流れる必要があります。
o ADD LINK request from a server in response to an ADD LINK from a client.
o クライアントからのADD LINKへの応答としてのサーバーからのADD LINK要求。
o DELETE LINK request from a server in response to a DELETE LINK from a client.
o クライアントからのDELETE LINKへの応答としてのサーバーからのDELETE LINK要求。
Connection Data Control (CDC) messages are sent over the RoCE fabric between peers using RoCE SendMsg and are 44 bytes long. The 44-byte size is based on the size that can fit into a RoCE WQE without requiring the posting of receive buffers. CDC messages are used to describe the socket application data passed via RDMA write operations, as well as TCP connection state information, including producer cursors and consumer cursors, RMBE state information, and failover data validation.
接続データ制御（CDC）メッセージは、RoCE SendMsgを使用してピア間でRoCEファブリック経由で送信され、長さは44バイトです。 44バイトのサイズは、受信バッファーの通知を必要とせずにRoCE WQEに収まるサイズに基づいています。 CDCメッセージは、RDMA書き込み操作を介して渡されるソケットアプリケーションデータ、およびプロデューサーカーソルとコンシューマーカーソルを含むTCP接続状態情報、RMBE状態情報、およびフェイルオーバーデータ検証を記述するために使用されます。
Rendezvous information for SMC-R is exchanged as TCP options on the TCP three-way handshake flows to indicate capability, followed by inline TCP negotiation messages to actually do the SMC-R setup. Formats of all rendezvous options and messages discussed in this section are detailed in Appendix A.
SMC-Rのランデブー情報は、機能を示すためにTCP 3ウェイハンドシェイクフローのTCPオプションとして交換され、インラインTCPネゴシエーションメッセージが続いて実際にSMC-Rセットアップを実行します。このセクションで説明するすべてのランデブーオプションとメッセージの形式については、付録Aで詳しく説明しています。
First contact between RoCE peers occurs when a new SMC-R link group is being set up. This could be because no SMC-R links already exist between the peers, or the server decides to create a new SMC-R link group in parallel with an existing one.
RoCEピア間の最初の接続は、新しいSMC-Rリンクグループがセットアップされるときに行われます。これは、ピア間にSMC-Rリンクが存在しないか、サーバーが既存のSMC-Rリンクグループと並行して新しいSMC-Rリンクグループを作成することを決定したことが原因である可能性があります。
The client and server indicate their SMC-R capability to each other using TCP option 254 on the TCP three-way handshake flows.
クライアントとサーバーは、TCP 3ウェイハンドシェイクフローでTCPオプション254を使用して、SMC-R機能を相互に示します。
A client who wishes to do SMC-R will include TCP option 254 using an ExID equal to the EBCDIC (codepage IBM-1047) encoding of "SMCR" on its SYN flow.
SMC-Rを実行するクライアントには、SYNフローで「SMCR」のEBCDIC（コードページIBM-1047）エンコーディングに等しいExIDを使用するTCPオプション254が含まれます。
A server that supports SMC-R will include TCP option 254 with the ExID value of EBCDIC "SMCR" on its SYN-ACK flow. Because the server is listening for connections and does not know where client connections will come from, the server implementation may choose to unconditionally include this TCP option if it supports SMC-R. This may be required for server implementations where extensions to the TCP stack are not practical. For server implementations that can add code to examine and react to packets during the three-way handshake, the server should only include the SMC-R TCP option on the SYN-ACK if the client included it on its SYN packet.
SMC-Rをサポートするサーバーには、SYN-ACKフローにExID値がEBCDIC "SMCR"のTCPオプション254が含まれます。サーバーは接続をリッスンしていて、クライアント接続がどこから来るのかわからないため、サーバーの実装は、SMC-Rをサポートしている場合、無条件にこのTCPオプションを含めることを選択できます。これは、TCPスタックへの拡張が実用的でないサーバー実装で必要になる場合があります。 3ウェイハンドシェイク中にパケットを調べてパケットに反応するコードを追加できるサーバー実装では、クライアントがSYNパケットにSMC-R TCPオプションを含めた場合にのみ、サーバーはSYN-ACKにSMC-R TCPオプションを含める必要があります。
A client who supports SMC-R and meets the three conditions outlined above may optionally include the TCP option for SMC-R on its ACK flow, regardless of whether or not the server included it on its SYN-ACK flow. Some TCP/IP stacks may have to include it if the SMC-R layer cannot modify the options on the socket until the three-way handshake completes. Proprietary servers should not include this option on the ACK flow, since including it on the SYN flow was sufficient to indicate the client's capabilities.
SMC-Rをサポートし、上記の3つの条件を満たすクライアントは、サーバーがSYN-ACKフローにSMC-Rを含めたかどうかに関係なく、オプションでSMC-RのTCPオプションをACKフローに含めることができます。 3ウェイハンドシェイクが完了するまでSMC-Rレイヤーがソケットのオプションを変更できない場合、一部のTCP / IPスタックにこれを含める必要がある場合があります。独自のサーバーでは、このオプションをACKフローに含めないでください。SYNフローに含めることで、クライアントの機能を示すのに十分です。
Once the initial three-way TCP handshake is completed, each peer examines the socket options. SMC-R implementations may do this by examining what was actually provided on the SYN and SYN-ACK packets or by performing a getsockopt() operation to determine the options sent by the peer. If neither peer, or only one peer, specified the TCP option for SMC-R, then SMC-R cannot be used on this connection and it proceeds using normal IP flows and processing.
最初の3方向TCPハンドシェイクが完了すると、各ピアはソケットオプションを調べます。 SMC-R実装は、SYNおよびSYN-ACKパケットで実際に提供されたものを調べるか、getsockopt()操作を実行して、ピアから送信されたオプションを判別することにより、これを行うことができます。どちらのピアも、または1つのピアのみがSMC-RのTCPオプションを指定した場合、SMC-Rはこの接続で使用できず、通常のIPフローと処理を使用して続行されます。
If both peers specified the TCP option for SMC-R, then the TCP connection is not started yet and the peers proceed to SMC-R negotiation using inline data flows. The socket is not yet turned over to the applications; instead, the respective SMC layers exchange CLC messages over the newly formed TCP connection.
両方のピアがSMC-RのTCPオプションを指定した場合、TCP接続はまだ開始されておらず、ピアはインラインデータフローを使用してSMC-Rネゴシエーションに進みます。ソケットはまだアプリケーションに引き渡されていません。代わりに、それぞれのSMC層は、新しく形成されたTCP接続を介してCLCメッセージを交換します。
If SMC-R is supported by both peers, the client sends an SMC Proposal CLC message to the server. It is not immediately apparent on this flow from client to server whether this is a new or existing SMC-R link, because in clustered environments a single IP address may represent multiple hosts. This type of cluster virtual IP address can be owned by a network-based or host-based Layer 4 load balancer that distributes incoming TCP connections across a cluster of servers/hosts. For purposes of high availability, other clustered environments may also support the movement of a virtual IP address dynamically from one host in the cluster to another. In summary, the client cannot predetermine that a connection is targeting the same host by simply matching the destination IP address for outgoing TCP connections. Therefore, it cannot predetermine the SMC-R link that will be used for a new TCP connection. This information will be dynamically learned, and the appropriate actions will be taken as the SMC-R negotiation handshake unfolds.
SMC-Rが両方のピアでサポートされている場合、クライアントはSMCプロポーザルCLCメッセージをサーバーに送信します。クラスタ化された環境では単一のIPアドレスが複数のホストを表す場合があるため、これが新規または既存のSMC-Rリンクであるかどうかは、クライアントからサーバーへのこのフローではすぐにはわかりません。このタイプのクラスター仮想IPアドレスは、着信TCP接続をサーバー/ホストのクラスター全体に分散するネットワークベースまたはホストベースのレイヤー4ロードバランサーが所有できます。高可用性を目的として、他のクラスター環境でも、クラスター内の1つのホストから別のホストへの仮想IPアドレスの動的な移動がサポートされている場合があります。要約すると、クライアントは、発信TCP接続の宛先IPアドレスを単に照合するだけでは、接続が同じホストをターゲットにしていることを事前に判断できません。したがって、新しいTCP接続に使用されるSMC-Rリンクを事前に決定することはできません。この情報は動的に学習され、SMC-Rネゴシエーションハンドシェイクが展開するにつれて適切なアクションが実行されます。
In the SMC-R proposal message, the initiator (client) proposes the use of SMC-R by including its peer ID, GID, and MAC addresses, as well as the IP subnet number of the outgoing interface (if IPv4) or the IP prefix list for the network over which the proposal is sent (if IPv6). At this point in the flow, the client makes no local commitments of resources for SMC-R.
SMC-R提案メッセージでは、イニシエーター（クライアント）は、ピアID、GID、MACアドレス、および発信インターフェース（IPv4の場合）またはIPのIPサブネット番号を含めることにより、SMC-Rの使用を提案します。プロポーザルが送信されるネットワークのプレフィックスリスト（IPv6の場合）。フローのこの時点では、クライアントはSMC-Rのリソースをローカルでコミットしません。
When the server receives the SMC Proposal CLC message, it uses the peer ID provided by the client, plus subnet or prefix information provided by the client, to determine if it already has a usable SMC-R link with this SMC-R peer. If there are one or more existing SMC-R links with this SMC-R peer, the server then decides which SMC-R link it will use for this TCP connection. See Sections 3.5.2 and 3.5.3 for the cases of reusing an existing SMC-R link or creating a parallel SMC-R link group between SMC-R peers.
サーバーは、SMCプロポーザルCLCメッセージを受信すると、クライアントから提供されたピアIDに加えて、クライアントから提供されたサブネットまたはプレフィックス情報を使用して、このSMC-Rピアとの使用可能なSMC-Rリンクがすでにあるかどうかを判断します。このSMC-Rピアとの既存のSMC-Rリンクが1つ以上ある場合、サーバーはこのTCP接続に使用するSMC-Rリンクを決定します。既存のSMC-Rリンクを再利用する場合、またはSMC-Rピア間に並列SMC-Rリンクグループを作成する場合については、セクション3.5.2および3.5.3を参照してください。
If this is a first contact between SMC-R peers, the server must validate that it is on the same LAN as the client before continuing. For IPv4, the server does this by verifying that it has an interface with an IP subnet number that matches the subnet number sent by the client in the SMC Proposal. For IPv6, it does this by verifying that it is directly attached to at least one IP prefix that was listed by the client in its SMC Proposal message.
これがSMC-Rピア間の最初の接続である場合、サーバーは続行する前に、クライアントと同じLAN上にあることを検証する必要があります。 IPv4の場合、サーバーは、SMCプロポーザルでクライアントから送信されたサブネット番号と一致するIPサブネット番号を持つインターフェースがあることを確認することでこれを行います。 IPv6の場合は、クライアントがSMCプロポーザルメッセージでリストした少なくとも1つのIPプレフィックスに直接接続されていることを確認することでこれを行います。
If the server agrees to use SMC-R, the server begins the setup of a new SMC-R link by allocating local QP and RMB resources (setting its QP state to INIT) and providing its full SMC-R information in an SMC Accept CLC message to the client over the TCP connection, along with a flag set indicating that this is a first contact flow. While the SMC Accept message could flow over any IP route back to the client depending upon Layer 3 IP routing, the SMC-R credentials provided must be for the common subnet or prefix between the server and client, as determined above. If the server cannot or does not want to do SMC-R with the client, it sends an SMC Decline CLC message to the client, and the connection data may begin flowing using normal TCP/IP flows.
サーバーがSMC-Rの使用に同意した場合、サーバーはローカルQPおよびRMBリソースを割り当て（QP状態をINITに設定）、SMC Accept CLCで完全なSMC-R情報を提供することにより、新しいSMC-Rリンクのセットアップを開始します。これが最初のコンタクトフローであることを示すフラグセットとともに、TCP接続を介してクライアントにメッセージを送信します。 SMC Acceptメッセージは、レイヤー3 IPルーティングに応じて、任意のIPルートを経由してクライアントに戻ることができますが、提供されるSMC-R資格は、サーバーとクライアント間の共通サブネットまたはプレフィックス用である必要があります。サーバーがクライアントでSMC-Rを実行できない、または実行したくない場合、サーバーはSMC Decline CLCメッセージをクライアントに送信し、接続データは通常のTCP / IPフローを使用して流れ始める場合があります。
When the client receives the SMC Accept from the server, it determines whether this is a new or existing SMC-R link, using the combination of the following: the first contact flag, its MAC/GID and the MAC/GID returned by the server, the VLAN over which the connection is setting up, and the QP number provided by the server.
クライアントは、サーバーからSMC Acceptを受信すると、次の組み合わせを使用して、これが新規または既存のSMC-Rリンクかどうかを判断します。最初の連絡フラグ、そのMAC / GID、およびサーバーから返されたMAC / GID 、接続が設定されているVLAN、およびサーバーから提供されたQP番号。
If it is an existing SMC-R link and the client agrees to use that link for the TCP connection, see Section 3.5.2 ("Subsequent Contact") below. If it is a new SMC-R link between peers that already have an SMC-R link, then the server is starting a new SMC-R link group.
それが既存のSMC-Rリンクであり、クライアントがTCP接続にそのリンクを使用することに同意する場合は、以下のセクション3.5.2（「後続の連絡先」）を参照してください。それがすでにSMC-Rリンクを持っているピア間の新しいSMC-Rリンクである場合、サーバーは新しいSMC-Rリンクグループを開始しています。
Assuming that either (1) this is a first contact between peers or (2) the server is starting a new SMC-R link group, the client now allocates local QP and RMB resources for the SMC-R link (setting the QP state to RTR (ready to receive)), associates them with the server QP as learned from the SMC Accept CLC message, and sends an SMC Confirm CLC message to the server over the TCP connection with its SMC-R link information included. The client also starts a timer to wait for the server to confirm the reliably connected queue pair, as described below.
（1）これがピア間の最初の連絡であるか、（2）サーバーが新しいSMC-Rリンクグループを開始していると仮定すると、クライアントはSMC-RリンクにローカルQPおよびRMBリソースを割り当てます（QP状態をRTR（ready to receive））、SMC Accept CLCメッセージから学習したようにそれらをサーバーQPに関連付け、SMC-Rリンク情報を含むTCP接続を介してSMC Confirm CLCメッセージをサーバーに送信します。以下で説明するように、クライアントはタイマーを開始して、サーバーが確実に接続されたキューのペアを確認するのを待ちます。
Upon receipt of the client's SMC Confirm CLC message, the server associates its QP for this SMC-R link with the client's QP as learned from the SMC Confirm CLC message and sets its QP state to RTS (ready to send). The client and the server now have reliably connected queue pairs.
サーバーは、クライアントのSMC確認CLCメッセージを受信すると、SMC確認CLCメッセージから学習したこのSMC-RリンクのQPをクライアントのQPに関連付け、QP状態をRTS（送信準備完了）に設定します。これで、クライアントとサーバーは確実に接続されたキューのペアを持っています。
Since setting up the SMC-R link and its QPs did not require any network flows on the RoCE fabric, the client and server must now confirm connectivity over the RoCE fabric. To accomplish this, the server will send a CONFIRM LINK Link Layer Control (LLC) message to the client over the newly created SMC-R link, using the RoCE fabric. The CONFIRM LINK LLC message will provide the server's MAC, GID, and QP information for the connection, allow each partner to communicate the maximum number of links it can tolerate in this link group (the "link limit"), and will additionally provide two link IDs:
SMC-RリンクとそのQPのセットアップにはRoCEファブリックでのネットワークフローは必要なかったため、クライアントとサーバーはRoCEファブリック経由の接続を確認する必要があります。これを達成するために、サーバーは、RoCEファブリックを使用して、新しく作成されたSMC-Rリンクを介してクライアントにCONFIRM LINKリンク層制御（LLC）メッセージを送信します。 CONFIRM LINK LLCメッセージは、サーバーのMAC、GID、およびQP情報を接続に提供し、各パートナーがこのリンクグループで許容できるリンクの最大数（「リンク制限」）を通信できるようにし、さらに2つを提供しますリンクID：
o a 1-byte server-assigned link number that is used by both peers to identify the link within the link group and is only unique within a link group.
o 両方のピアがリンクグループ内のリンクを識別するために使用し、リンクグループ内でのみ一意である、1バイトのサーバー割り当てリンク番号。
o a 4-byte link user ID. This opaque value is assigned by the server for the server's local use and is provided to the client for management purposes -- for example, to use in network management displays and products.
o 4バイトのリンクユーザーID。この不透明な値は、サーバーがローカルで使用するためにサーバーによって割り当てられ、ネットワーク管理ディスプレイや製品で使用するなどの管理目的でクライアントに提供されます。
When the server sends this message, it will set a timer for receiving confirmation from the client.
サーバーがこのメッセージを送信すると、クライアントからの確認を受信するためのタイマーが設定されます。
When the client receives the server's confirmation in the form of a CONFIRM LINK LLC message, it will cancel the confirmation timer it set when it sent the SMC Confirm message. The client will also advance its QP state to RTS and respond over the RoCE fabric with a CONFIRM LINK response LLC message that (1) provides its MAC, GID, QP number, and link limit, (2) confirms the 1-byte link number sent by the server, and (3) provides its own 4-byte link user ID to the server.
クライアントがCONFIRM LINK LLCメッセージの形式でサーバーの確認を受信すると、SMC確認メッセージを送信したときに設定した確認タイマーをキャンセルします。クライアントはまた、QP状態をRTSに進め、RoCEファブリックを介してCONFIRM LINK応答LLCメッセージで応答します。これは、（1）MAC、GID、QP番号、およびリンク制限を提供します、（2）1バイトのリンク番号を確認しますサーバーから送信され、（3）サーバーに独自の4バイトのリンクユーザーIDを提供します。
Host X -- Server Host Y -- Client
+-------------------+ +-------------------+
| Peer ID = PS1 | | Peer ID = PC1 |
| +------+ +------+ |
| QP 8 |RNIC 1| |RNIC 2| QP 64 |
|RToken X| |MAC MA| |MAC MB| | |
| | |GID GA| |GID GB| |RToken Y|
| \/ +------+ (Subnet S1) +------+ \/ |
|+--------+ | | +--------+ |
|| RMB | | | | RMB | |
|+--------+ | | +--------+ |
| +------+ +------+ |
| |RNIC 3| |RNIC 4| |
| |MAC MC| |MAC MD| |
| |GID GC| |GID GD| |
| +------+ +------+ |
+-------------------+ +-------------------+
SYN TCP options(254,"SMCR")
<---------------------------------------------------------
SYN-ACK TCP options(254,"SMCR")
--------------------------------------------------------->
ACK [TCP options(254,"SMCR")]
<--------------------------------------------------------
SMC Proposal(PC1,MB,GB,S1)
<--------------------------------------------------------
SMC Accept(PS1,first contact,MA,GA,MTU,QP8,RToken=X,RMB elem index)
--------------------------------------------------------->
SMC Confirm(PC1,MB,GB,MTU,QP64,RToken=Y,RMB element index)
<--------------------------------------------------------
CONFIRM LINK(MA,GA,QP8, link lim, server link user ID, linknum)
.........................................................>
CONFIRM LINK rsp(MB,GB,QP64, link lim, client link user ID, linknum)
<........................................................
Legend:
------------ TCP/IP and CLC flows
............ RoCE (LLC) flows
Square brackets ("[ ]") indicate optional information
Figure 8: First Contact Rendezvous Flows
図8：ファーストコンタクトランデブーフロー
Technically, the data for the TCP connection could now flow over the RoCE path. However, if this is a first contact, there is no alternate for this recently established RoCE path. Since in the current architecture there is no failover from RoCE to IP once connection data starts flowing, this means that a failure of this path would disrupt the TCP connection, meaning that the level of redundancy and failover is less than that provided by IP. If the network has alternate RoCE paths available, they would not be usable at this point. This situation would be unacceptable.
技術的には、TCP接続のデータはRoCEパス上を流れることができます。ただし、これが最初の連絡先である場合、この最近確立されたRoCEパスの代替はありません。現在のアーキテクチャでは、接続データが流れ始めるとRoCEからIPへのフェールオーバーは行われないため、このパスの障害によりTCP接続が中断され、冗長性とフェールオーバーのレベルがIPによって提供されるレベルよりも低くなります。ネットワークで代替RoCEパスが利用できる場合、それらは現時点では使用できません。この状況は許容できません。
Because of the unacceptable situation described above, TCP data will not be allowed to flow on the newly established SMC-R link until a second path has been set up, or at least attempted.
上記の許容できない状況のため、2番目のパスがセットアップされるか、少なくとも試行されるまで、TCPデータは新しく確立されたSMC-Rリンク上を流れることができません。
If the server has a second RNIC available on the same LAN, it attempts to set up the second SMC-R link over that second RNIC. If it only has one RNIC available on the LAN, it will attempt to set up the second SMC-R link over that one RNIC. In the latter case, the server is attempting to set up an asymmetric link, in case the client does have a second RNIC on the LAN.
同じLANで使用可能な2番目のRNICがサーバーにある場合、サーバーはその2番目のRNICを介して2番目のSMC-Rリンクをセットアップしようとします。 LANで使用可能なRNICが1つしかない場合は、その1つのRNICを介して2番目のSMC-Rリンクをセットアップしようとします。後者の場合、クライアントがLANに2番目のRNICを持っている場合に備えて、サーバーは非対称リンクをセットアップしようとしています。
In either case, the server allocates a new QP over the RNIC it is attempting to use for the second link and assigns a link number to the new link; the server also creates an RToken for the RMB over this second QP (note that this means that the first and second QP each have their own RToken to represent the same RMB). The server provides this information, as well as the MAC and GID of the RNIC over which it is attempting to set up the second link, in an ADD LINK LLC message that it sends to the client over the SMC-R link that is already set up.
どちらの場合も、サーバーは2番目のリンクに使用しようとしているRNICを介して新しいQPを割り当て、リンク番号を新しいリンクに割り当てます。サーバーは、この2番目のQPを介してRMBのRTokenも作成します（これは、1番目と2番目のQPがそれぞれ、同じRMBを表す独自のRTokenを持っていることを意味します）。サーバーは、この情報と、2番目のリンクを設定しようとしているRNICのMACおよびGIDを、すでに設定されているSMC-Rリンクを介してクライアントに送信するADD LINK LLCメッセージで提供します。アップ。
When the client receives the server's ADD LINK LLC message, it examines the GID and MAC provided by the server to determine whether the server is attempting to use the same server-side RNIC as the existing SMC-R link or a different one.
クライアントはサーバーのADD LINK LLCメッセージを受信すると、サーバーから提供されたGIDとMACを調べて、サーバーが既存のSMC-Rリンクと同じサーバー側RNICを使用しようとしているのか、それとも別のRNICを使用しようとしているのかを判断します。
If the server is attempting to use the same server-side RNIC as the existing SMC-R link, then the client verifies that it has a second RNIC on the same LAN. If it does not, the client rejects the ADD LINK request from the server, because the resulting link would be a parallel link, which is not supported within a link group. If the client does have a second RNIC on the same LAN, it accepts the request, and an asymmetric link will be set up.
サーバーが既存のSMC-Rリンクと同じサーバー側のRNICを使用しようとしている場合、クライアントは同じLAN上に2番目のRNICがあることを確認します。そうでない場合、リンクはリンクグループ内でサポートされないパラレルリンクになるため、クライアントはサーバーからのADD LINK要求を拒否します。クライアントが同じLAN上に2番目のRNICを持っている場合、クライアントは要求を受け入れ、非対称リンクがセットアップされます。
If the server is using a different server-side RNIC from the existing SMC-R link, then the client will accept the request and a second SMC-R link will be set up in this SMC-R link group. If the client has a second RNIC on the same LAN, that second RNIC will be used for the second SMC-R link, creating symmetric links. If the client does not have a second RNIC on the same LAN, it will use the same RNIC as was used for the initial SMC-R link, resulting in the setup of an asymmetric link in the SMC-R link group.
サーバーが既存のSMC-Rリンクとは異なるサーバー側RNICを使用している場合、クライアントは要求を受け入れ、このSMC-Rリンクグループに2番目のSMC-Rリンクが設定されます。クライアントが同じLAN上に2つ目のRNICを持っている場合、その2つ目のRNICは2つ目のSMC-Rリンクに使用され、対称リンクを作成します。クライアントが同じLAN上に2番目のRNICを持たない場合、クライアントは最初のSMC-Rリンクに使用されたものと同じRNICを使用し、SMC-Rリンクグループに非対称リンクを設定します。
In either case, when the client accepts the server's ADD LINK request, it allocates a new QP on the chosen RNIC and creates an RKey over that new QP for the client-side RMB for the SMC-R link group, then sends an ADD LINK reply LLC message to the server providing that information as well as echoing the link number that was sent by the server.
どちらの場合も、クライアントがサーバーのADD LINK要求を受け入れると、選択したRNICに新しいQPを割り当て、SMC-Rリンクグループのクライアント側RMBの新しいQPを介してRKeyを作成し、ADD LINKを送信します。サーバーに送信されたリンク番号をエコーするだけでなく、その情報を提供するサーバーにLLCメッセージを返信します。
If the client rejects the server's ADD LINK request, it sends an ADD LINK reply LLC message to the server with the reason code for the rejection.
クライアントがサーバーのADD LINK要求を拒否した場合、クライアントは拒否の理由コードとともにADD LINK応答LLCメッセージをサーバーに送信します。
If the client sends a negative response to the server or no reply is received, the server frees the RoCE resources it had allocated for the new link. Having a single link in an SMC-R link group is undesirable. The server's recovery is detailed in Appendix C.8 ("Failure to Add Second SMC-R Link to a Link Group").
クライアントがサーバーに否定応答を送信するか、応答を受信しない場合、サーバーは新しいリンクに割り当てたRoCEリソースを解放します。 SMC-Rリンクグループに単一のリンクがあることは望ましくありません。サーバーの回復については、付録C.8（「2番目のSMC-Rリンクをリンクグループに追加できない」）で詳しく説明しています。
If the client sends a positive reply to the server with MAC/GID/QP/RKey information, the server associates its QP for the new SMC-R link to the QP that the client provided. Now, the new SMC-R link is in the same situation that the first was in after the client sent its ACK packet -- there is a reliably connected queue pair over the new RoCE path, but there have been no RoCE flows to confirm that it's actually usable. So, at this point, the client and server will exchange CONFIRM LINK LLC messages just like they did on the first SMC-R link.
クライアントがMAC / GID / QP / RKey情報を含む肯定的な応答をサーバーに送信すると、サーバーは新しいSMC-RリンクのQPをクライアントが提供したQPに関連付けます。これで、新しいSMC-Rリンクは、最初のクライアントがACKパケットを送信した後と同じ状況にあります。新しいRoCEパスを介して確実に接続されたキューペアがありますが、確認するRoCEフローがありません実際に使用できます。したがって、この時点で、クライアントとサーバーは、最初のSMC-Rリンクと同じようにCONFIRM LINK LLCメッセージを交換します。
If either peer receives a failure during this second CONFIRM LINK LLC exchange (either an immediate failure -- which implies that the message did not reach the partner -- or a timeout), it sends a DELETE LINK LLC message to the partner over the first (and now only) link in the link group. This DELETE LINK LLC message must be acknowledged before data can flow on the single link in the link group.
この2番目のCONFIRM LINK LLC交換中にいずれかのピアが障害（即時の障害（メッセージがパートナーに到達しなかったことを意味する）またはタイムアウト）を受信した場合、最初の経由でDELETE LINK LLCメッセージをパートナーに送信します（そして今のみ）リンクグループのリンク。このDELETE LINK LLCメッセージは、データがリンクグループ内の単一のリンク上を流れる前に確認する必要があります。
Host X -- Server Host Y -- Client
+-------------------+ +-------------------+
| Peer ID = PS1 | | Peer ID = PC1 |
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 64 |
|RToken X| |MAC MA|<-------------------->|MAC MB| | |
| | |GID GA| |GID GB| |RToken Y|
| \/ +------+ +------+ \/ |
|+--------+ | | +--------+ |
|| | | | | | |
|| RMB | | | | RMB | |
|| | | | | | |
|+--------+ | | +--------+ |
| /\ +------+ +------+ /\ |
| | |RNIC 3| SMC-R Link 2 |RNIC 4| | |
|RToken Z| |MAC MC|<-------------------->|MAC MD| |RToken W |
| QP 9 |GID GC| (being added) |GID GD| QP 65 |
| +------+ +------+ |
+-------------------+ +-------------------+
First SMC-R link setup as shown in Figure 8 <-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.->
図8に示す最初のSMC-Rリンクのセットアップ<-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-.-。 -.-.->
ADD LINK request(QP9,MC,GC, link number = 2)
............................................>
ADD LINK response(QP65,MD,GD, link number = 2)
<............................................
ADD LINK CONTINUATION request(RToken=Z)
............................................>
ADD LINK CONTINUATION response(RToken=W)
<............................................
CONFIRM LINK(MC,GC,QP9, link number = 2, link user ID)
.............................................>
CONFIRM LINK response(MD,GD,QP65, link number = 2, link user ID)
<.............................................
Legend:
------------ TCP/IP and CLC flows
............ RoCE (LLC) flows
Figure 9: First Contact, Second Link Setup
図9：最初の連絡先、2番目のリンクの設定
Note that in the scenario described here -- first contact -- there is only one RMB RKey to exchange on the second SMC-R link, and it is exchanged in the ADD LINK CONTINUATION request and reply. In scenarios other than first contact -- for example, adding a new SMC-R link to a longstanding link group with multiple RMBs -- additional flows will be required to exchange additional RMB RKeys. See Section 3.5.5.2.3 ("Adding a New SMC-R Link to a Link Group with Multiple RMBs") for more details on these flows.
ここで説明するシナリオ（最初の連絡先）では、2番目のSMC-Rリンクで交換するRMB RKeyは1つだけで、ADD LINK CONTINUATION要求と応答で交換されることに注意してください。最初の連絡以外のシナリオ（たとえば、新しいSMC-Rリンクを複数のRMBを持つ長年のリンクグループに追加する）では、追加のRMB RKeyを交換するために追加のフローが必要になります。これらのフローの詳細については、セクション3.5.5.2.3（「複数のRMBを持つリンクグループへの新しいSMC-Rリンクの追加」）を参照してください。
If both partners don't provide the SMC-R TCP option during the three-way TCP handshake, the connection falls back to normal TCP/IP. During the SMC-R negotiation that occurs after the three-way TCP handshake, either partner may break off SMC-R by sending an SMC Decline CLC message. The SMC Decline CLC message may be sent in place of any expected message and may also be sent during the CONFIRM LINK LLC exchange if there is a failure before any application data has flowed over the RoCE fabric. For more details on exactly when an SMC Decline can flow during link group setup, see Appendices C.1 ("SMC Decline during CLC Negotiation") and C.2 ("SMC Decline during LLC Negotiation").
3方向のTCPハンドシェイク中に両方のパートナーがSMC-R TCPオプションを提供しない場合、接続は通常のTCP / IPにフォールバックします。 3ウェイTCPハンドシェイクの後に発生するSMC-Rネゴシエーション中に、いずれかのパートナーがSMC Decline CLCメッセージを送信してSMC-Rを切断する場合があります。 SMC Decline CLCメッセージは、予想されるメッセージの代わりに送信される場合があり、アプリケーションデータがRoCEファブリック上を流れる前に障害が発生した場合、CONFIRM LINK LLC交換中に送信される場合もあります。リンクグループのセットアップ中にSMC拒否がいつフローするかについての詳細は、付録C.1（「CLCネゴシエーション中のSMC拒否」）およびC.2（「LLCネゴシエーション中のSMC拒否」）を参照してください。
If this fallback to IP happens while setting up a new SMC-R link group, the RoCE resources allocated for this SMC-R link group relationship are torn down, and it will be retried as a new SMC-R link group next time a connection starts between these peers with SMC-R proposed. Note that if this happens because one side doesn't support SMC-R, there will be very little to tear down, as the TCP option will have failed to flow on either the initial SYN or the SYN-ACK before either side had reserved any local RoCE resources.
新しいSMC-Rリンクグループのセットアップ中にこのIPへのフォールバックが発生した場合、このSMC-Rリンクグループ関係に割り当てられたRoCEリソースは破棄され、次回接続時に新しいSMC-Rリンクグループとして再試行されますこれらのピア間で開始され、SMC-Rが提案されています。片方がSMC-Rをサポートしていないためにこれが発生した場合、片方がいずれかの側を予約する前にTCPオプションが最初のSYNまたはSYN-ACKのいずれかでフローできなかったため、破棄することはほとんどありません。ローカルRoCEリソース。
"Subsequent contact" means setting up a new TCP connection between two peers that already have an SMC-R link group between them and reusing the existing SMC-R link group. In this case, it is not necessary to allocate new QPs. However, it is possible that a new RMB has been allocated for this TCP connection, if the previous TCP connection used the last element available in the previously used RMB, or for any other implementation-dependent reason. For this reason, and for convenience and error checking, the same TCP option 254, followed by the inline negotiation method described for initial contact, will be used for subsequent contact, but the processing differs in some ways. That processing is described below.
「後続の連絡先」とは、SMC-Rリンクグループが既に存在する2つのピア間に新しいTCP接続を設定し、既存のSMC-Rリンクグループを再利用することを意味します。この場合、新しいQPを割り当てる必要はありません。ただし、以前のTCP接続が以前に使用されたRMBで利用可能な最後の要素を使用した場合、またはその他の実装依存の理由により、このTCP接続に新しいRMBが割り当てられた可能性があります。このため、利便性とエラーチェックのために、同じTCPオプション254に続けて、最初のコンタクトで説明したインラインネゴシエーションメソッドが後続のコンタクトに使用されますが、処理はいくつかの点で異なります。その処理を以下に説明します。
When the client begins the inline negotiation with the server, it does not know if this is a first contact or a subsequent contact. The client cannot know this information until it sees the server's peer ID, to determine whether or not it already has an SMC-R link with this peer that it can use. There are several reasons why it is not sufficient to use the partner IP address, subnet, VLAN, or other IP information to make this determination. The most obvious reason is distributed systems: if the server IP address is actually a virtual IP address representing a distributed cluster, the actual host serving this TCP connection may not be the same as the host that served the last TCP connection to this same IP address.
クライアントがサーバーとのインラインネゴシエーションを開始するとき、これが最初の連絡であるか、後続の連絡であるかはわかりません。クライアントは、サーバーのピアIDを確認して、使用できるこのピアとのSMC-Rリンクがすでにあるかどうかを判断するまで、この情報を知ることができません。この判断を行うためにパートナーのIPアドレス、サブネット、VLAN、またはその他のIP情報を使用するだけでは不十分である理由はいくつかあります。最も明白な理由は分散システムです。サーバーのIPアドレスが実際に分散クラスターを表す仮想IPアドレスである場合、このTCP接続を提供する実際のホストは、この同じIPアドレスへの最後のTCP接続を提供するホストと同じではない可能性があります。
After the TCP three-way handshake, assuming that both partners indicate SMC-R capability, the client builds and sends the SMC Proposal CLC message to the server in exactly the same manner as it does in the "first contact" case, and in fact at this point doesn't know if it's a first contact or a subsequent contact. As in the "first contact" case, the client sends its peer ID value, suggested RNIC MAC/GID, and IP subnet or prefix information.
TCPの3ウェイハンドシェイクの後、両方のパートナーがSMC-R機能を示していると仮定すると、クライアントは、SMCプロポーザルCLCメッセージを構築して、「最初の連絡」の場合とまったく同じ方法でサーバーに送信します。この時点では、それが最初の連絡先であるか後続の連絡先であるかはわかりません。 「最初の連絡」の場合と同様に、クライアントはピアID値、推奨されるRNIC MAC / GID、およびIPサブネットまたはプレフィックス情報を送信します。
Upon receiving the client's proposal, the server looks up the provided peer ID to determine if it already has a usable SMC-R link group with this peer. If it does already have a usable SMC-R link group, the server then needs to decide whether it will use the existing SMC-R link group or create a new link group. For the case of the new link group, see Section 3.5.3 ("First Contact Variation: Creating a Parallel Link Group") below.
クライアントの提案を受信すると、サーバーは提供されたピアIDを検索して、このピアとの使用可能なSMC-Rリンクグループがすでにあるかどうかを判断します。すでに使用可能なSMC-Rリンクグループがある場合、サーバーは既存のSMC-Rリンクグループを使用するか、新しいリンクグループを作成するかを決定する必要があります。新しいリンクグループの場合については、以下のセクション3.5.3（「最初の接触のバリエーション：並列リンクグループの作成」）を参照してください。
For this discussion, assume that the server decides to use the existing SMC-R link group for the TCP connection, which is expected to be the most common case. The server is responsible for making this decision. The server then needs to communicate that information to the client, but it is not necessary to allocate, associate, and confirm QPs for the chosen SMC-R link. All that remains to be done is to set up RMB space for this TCP connection.
この説明では、サーバーがTCP接続に既存のSMC-Rリンクグループを使用することを決定すると想定します。これは、最も一般的なケースであると予想されます。サーバーは、この決定を行う責任があります。次に、サーバーはその情報をクライアントに通信する必要がありますが、選択したSMC-RリンクにQPを割り当て、関連付け、確認する必要はありません。あとは、このTCP接続用にRMBスペースをセットアップするだけです。
If one of the RMBs already in use for this SMC-R link group has an available element that uses the appropriate buffer size, the server merely chooses one for this TCP connection and then sends an SMC Accept CLC message providing the full RoCE information for the chosen SMC-R link to the client, using the same format as the SMC Accept CLC message described in Section 3.5.1 ("First Contact") above.
このSMC-Rリンクグループですでに使用されているRMBの1つに、適切なバッファーサイズを使用する使用可能な要素がある場合、サーバーはこのTCP接続用に1つを選択し、SMC Accept CLCメッセージを送信して、完全なRoCE情報を提供します。上記のセクション3.5.1（「最初の連絡先」）で説明されているSMC Accept CLCメッセージと同じ形式を使用して、クライアントへの選択されたSMC-Rリンク。
The server may choose to use the SMC-R link that matches the suggested MAC/GID provided by the client in the SMC Proposal for its RDMA writes but is not obligated to do so. The final decision on which specific SMC-R link to assign a TCP connection to is an independent server and client decision.
サーバーは、RDMA書き込み用にSMCプロポーザルでクライアントから提供された推奨MAC / GIDと一致するSMC-Rリンクを使用することを選択できますが、そうする義務はありません。 TCP接続を割り当てる特定のSMC-Rリンクの最終決定は、独立したサーバーとクライアントの決定です。
It may be necessary for the server to allocate a new RMB for this connection. The reasons for this are implementation dependent and could include the following:
サーバーがこの接続に新しいRMBを割り当てる必要がある場合があります。この理由は実装に依存し、次のようなものがあります。
o no available space in existing RMB or RMBs, or
o 既存のRMBに使用可能なスペースがない、または
o desire to allocate a new RMB that uses a different buffer size from the ones already created, or
o すでに作成されたものとは異なるバッファーサイズを使用する新しいRMBを割り当てたい、または
o any other implementation-dependent reason
o その他の実装依存の理由
In this case, the server will allocate the new RMB and then perform the flows described in Section 3.5.5.2.1 ("Adding a New RMB to an SMC-R Link Group"). Once that processing is complete, the server then provides the full RoCE information, including the new RKey, for this connection in an SMC Confirm CLC message to the client.
この場合、サーバーは新しいRMBを割り当て、セクション3.5.5.2.1（「SMC-Rリンクグループへの新しいRMBの追加」）で説明されているフローを実行します。その処理が完了すると、サーバーは、SMC確認CLCメッセージでこの接続の新しいRKeyを含む完全なRoCE情報をクライアントに提供します。
Upon receiving the SMC Accept CLC message from the server, the client examines the RoCE information provided by the server to determine whether this is a first contact for a new SMC-R link group or a subsequent contact for an existing SMC-R link group. It is a subsequent contact if the server-side peer ID, GID, MAC, and QP number provided in the packet match a known SMC-R link, and the first contact flag is not set. If this is not the case -- for example, the GID and MAC match but the QP is new -- then the server is creating a new, parallel SMC-R link group, and this is treated as a first contact.
サーバーからSMC Accept CLCメッセージを受信すると、クライアントはサーバーから提供されたRoCE情報を調べて、これが新しいSMC-Rリンクグループの最初の連絡先であるか、既存のSMC-Rリンクグループの後続の連絡先であるかを判断します。パケットで提供されたサーバー側のピアID、GID、MAC、およびQP番号が既知のSMC-Rリンクと一致し、最初の連絡フラグが設定されていない場合、これは後続の連絡です。これが当てはまらない場合（たとえば、GIDとMACは一致するが、QPは新しい場合）、サーバーは新しい並列SMC-Rリンクグループを作成しており、これは最初の連絡先として扱われます。
A different RMB RToken does not indicate a first contact, as the server may have allocated a new RMB or may be using several RMBs for this SMC-R link. The client needs the server's RMB information only for its RDMA writes to the server, and since there is no requirement for symmetric RMBs, this information is simply control information for the RDMA writes on this SMC-R link.
サーバーが新しいRMBを割り当てたか、このSMC-Rリンクに複数のRMBを使用している可能性があるため、別のRMB RTokenは最初の連絡を示していません。クライアントは、サーバーへのRDMA書き込みについてのみサーバーのRMB情報を必要とします。対称RMBは必要ないため、この情報は、このSMC-RリンクでのRDMA書き込みの制御情報です。
The client must validate that the RMB element being provided by the server is not in use by another TCP connection on this SMC-R link group. This validation must validate the new <rtoken, index> across all known <rtoken, index> on this link group. See Section 4.4.2 ("RMB Element Reuse and Conflict Resolution") for the case in which the server tries to use an RMB element that is already in use on this link group.
クライアントは、サーバーによって提供されているRMB要素が、このSMC-Rリンクグループ上の別のTCP接続によって使用されていないことを検証する必要があります。この検証では、このリンクグループのすべての既知の<rtoken、index>で新しい<rtoken、index>を検証する必要があります。サーバーがこのリンクグループですでに使用されているRMB要素を使用しようとする場合については、セクション4.4.2（「RMB要素の再利用と競合の解決」）を参照してください。
Once the client has determined that this TCP connection is a subsequent contact over an existing SMC-R link, it performs an RMB allocation process similar to what the server did: it either (1) allocates an element from an RMB already associated with this SMC-R link or (2) allocates a new RMB, associates it with this SMC-R link, and then chooses an element out of it.
このTCP接続が既存のSMC-Rリンクを介した後続の接続であるとクライアントが判断すると、サーバーが行ったのと同様のRMB割り当てプロセスを実行します。（1）このSMCに既に関連付けられているRMBから要素を割り当てる-Rリンクまたは（2）新しいRMBを割り当て、それをこのSMC-Rリンクに関連付けてから、そこからエレメントを選択します。
If the client allocates a new RMB for this TCP connection, it performs the processing described in Section 3.5.5.2.1 ("Adding a New RMB to an SMC-R Link Group"). Once that processing is complete, the client provides its full RoCE information for this TCP connection in an SMC Confirm CLC message.
クライアントがこのTCP接続に新しいRMBを割り当てる場合、クライアントはセクション3.5.5.2.1（「SMC-Rリンクグループへの新しいRMBの追加」）で説明されている処理を実行します。その処理が完了すると、クライアントは、SMC確認CLCメッセージでこのTCP接続の完全なRoCE情報を提供します。
Because an SMC-R link with a verified connected QP already exists and is being reused, there is no need for verification or alternate QP selection flows or timers.
検証済みの接続されたQPを持つSMC-Rリンクはすでに存在し、再利用されているため、検証や代替のQP選択フローまたはタイマーは必要ありません。
When the server receives the client's SMC Confirm CLC message on a subsequent contact, it verifies the following:
サーバーは、後続の連絡先でクライアントのSMC確認CLCメッセージを受信すると、次のことを確認します。
o The RMB element provided by the client is not already in use by another TCP connection on this SMC-R link group (see Section 4.4.2 ("RMB Element Reuse and Conflict Resolution") for the case in which it is).
o クライアントから提供されたRMB要素は、このSMC-Rリンクグループ上の別のTCP接続でまだ使用されていません（使用されている場合は、4.4.2項（「RMB要素の再利用と競合の解決」を参照）。
o The MAC/GID/QP information provided by the client matches an active link within the link group. The client is free to select any valid/active link. The client is not required to select the same link as the server.
o クライアントから提供されたMAC / GID / QP情報は、リンクグループ内のアクティブリンクと一致します。クライアントは、有効/アクティブなリンクを自由に選択できます。クライアントは、サーバーと同じリンクを選択する必要はありません。
If this validation passes, the server stores the client's RMB information for this connection, and the RoCE setup of the TCP connection is complete.
この検証に合格すると、サーバーはこの接続に関するクライアントのRMB情報を保存し、TCP接続のRoCEセットアップが完了します。
On a subsequent contact TCP/IP connection, a peer may send data as soon as it has received the peer RMB information for the connection. There are no additional RoCE confirmation flows, since the QPs on the SMC-R link are already reliably connected and verified.
その後のコンタクトTCP / IP接続では、ピアは、接続のピアRMB情報を受信するとすぐにデータを送信できます。 SMC-Rリンク上のQPはすでに確実に接続および検証されているため、追加のRoCE確認フローはありません。
In the majority of cases, the first data will flow from the client to the server. The client must send the SMC Confirm CLC message before sending any connection data over the chosen SMC-R link; however, the client need not wait for confirmation of this message, and in fact there will be no such confirmation. Since the server is required to have the RMB fully set up and ready to receive data from the client before sending an SMC Accept CLC message, the client can begin sending data over the SMC-R link immediately upon completing the send of the SMC Confirm CLC message.
ほとんどの場合、最初のデータはクライアントからサーバーに流れます。クライアントは、選択されたSMC-Rリンクを介して接続データを送信する前に、SMC確認CLCメッセージを送信する必要があります。ただし、クライアントはこのメッセージの確認を待つ必要はなく、実際にはそのような確認はありません。サーバーは、RMBが完全にセットアップされ、SMC Accept CLCメッセージを送信する前にクライアントからデータを受信する準備ができている必要があるため、SMC確認CLCの送信が完了するとすぐに、クライアントはSMC-Rリンクを介してデータの送信を開始できます。メッセージ。
It is possible that data from the client will arrive at the server-side RMB before the SMC Confirm CLC message from the client has been processed. In this case, the server must handle this race condition and not provide the arrived TCP data to the socket application until the SMC Confirm CLC message has been received and fully processed, opening the socket.
クライアントからのSMC確認CLCメッセージが処理される前に、クライアントからのデータがサーバー側のRMBに到着する可能性があります。この場合、サーバーはこの競合状態を処理し、SMC確認CLCメッセージが受信されて完全に処理されてソケットを開くまで、到着したTCPデータをソケットアプリケーションに提供しないでください。
If the server has initial data to send to the client that is not a response to the client (this case should be rare), it can send the data immediately upon receiving and processing the SMC Confirm CLC message from the client. The client must have opened the TCP socket to the client application upon sending the SMC Confirm CLC message so the client will be ready to process data from the server.
サーバーがクライアントに送信する初期データをクライアントへの応答ではない場合（これはまれなケースです）、サーバーはクライアントからのSMC確認CLCメッセージを受信して処理するとすぐにデータを送信できます。クライアントは、SMC確認CLCメッセージを送信するときにクライアントアプリケーションへのTCPソケットを開いている必要があります。これにより、クライアントはサーバーからのデータを処理できるようになります。
Recall that parallel SMC-R links within an SMC-R link group are not supported. These are multiple SMC-R links within a link group that use the same network path. However, multiple SMC-R link groups between the same peers are supported. This means that if multiple SMC-R links over the same RoCE path are desired, it is necessary to use multiple SMC-R link groups. While not a recommended practice, this could be done for platform-specific reasons, like QP separation of different workloads. Only the server can drive the creation of multiple SMC-R link groups between peers.
SMC-Rリンクグループ内の並列SMC-Rリンクはサポートされていないことを思い出してください。これらは、同じネットワークパスを使用するリンクグループ内の複数のSMC-Rリンクです。ただし、同じピア間の複数のSMC-Rリンクグループがサポートされています。つまり、同じRoCEパス上の複数のSMC-Rリンクが必要な場合は、複数のSMC-Rリンクグループを使用する必要があります。これは推奨される方法ではありませんが、さまざまなワークロードのQP分離など、プラットフォーム固有の理由で行うことができます。サーバーのみが、ピア間の複数のSMC-Rリンクグループの作成を実行できます。
At a high level, when the server decides to create an additional SMC-R link group with a client with which it already has an SMC-R link group, the flows are basically the same as the normal "first contact" case described above. The following text provides more detail and clarification of processing in this case.
大まかに言えば、サーバーがSMC-Rリンクグループを既に持っているクライアントで追加のSMC-Rリンクグループを作成することを決定した場合、フローは上記の通常の「最初の連絡」ケースと基本的に同じです。次のテキストは、この場合の処理の詳細と説明を提供します。
When the server receives the SMC Proposal CLC message from the client and, using the MAC/GID information, determines that it already has an SMC-R link group with this client, the server can either reuse the existing SMC-R link group (detailed in Section 3.5.2 ("Subsequent Contact") above) or create a new SMC-R link group in addition to the existing one.
サーバーがクライアントからSMCプロポーザルCLCメッセージを受信し、MAC / GID情報を使用して、このクライアントとのSMC-Rリンクグループがすでにあると判断した場合、サーバーは既存のSMC-Rリンクグループを再利用できます（詳細セクション3.5.2（「後続の連絡先」）で）、または既存のグループに加えて新しいSMC-Rリンクグループを作成します。
If the server decides to create a new SMC-R link group, it does the same processing it would have done for first contact: allocate QP and RMB resources as well as alternate QP resources, and communicate the QP and RMB information to the client in the SMC Accept CLC message with the first contact flag set.
サーバーが新しいSMC-Rリンクグループを作成することを決定した場合、サーバーは最初の連絡で行ったのと同じ処理を実行します。QPおよびRMBリソースと代替QPリソースを割り当て、QPおよびRMB情報をクライアントに通知します。最初の連絡フラグが設定されたSMC Accept CLCメッセージ。
When the client receives the server's SMC Accept CLC message with the new QP information and the first contact flag set, it knows that the server is creating a new SMC-R link group even though it already has an SMC-R link group with the server. In this case, the client will also allocate a new QP for this new SMC-R link, allocate an RMB for it, and generate an RKey for it.
クライアントは、新しいQP情報と最初の連絡フラグが設定されたサーバーのSMC Accept CLCメッセージを受信すると、サーバーに既にSMC-Rリンクグループがあるにもかかわらず、サーバーが新しいSMC-Rリンクグループを作成していることを認識します。 。この場合、クライアントはこの新しいSMC-Rリンクに新しいQPを割り当て、それにRMBを割り当て、それにRKeyを生成します。
Note that multiple SMC-R link groups between the same peers must access different RMB resources, so new RMBs will be required. Using the same RMBs that are in use in another SMC-R link group is not permitted.
同じピア間の複数のSMC-Rリンクグループは異なるRMBリソースにアクセスする必要があるため、新しいRMBが必要になることに注意してください。別のSMC-Rリンクグループで使用されているものと同じRMBを使用することはできません。
The client then associates its new QP with the server's new QP and sends its SMC Confirm CLC message back to the server providing the new QP/RMB information, and then sets its confirmation timer for the new SMC-R link.
次に、クライアントは新しいQPをサーバーの新しいQPに関連付け、SMC確認CLCメッセージをサーバーに送信して新しいQP / RMB情報を提供し、確認タイマーを新しいSMC-Rリンクに設定します。
When the server receives the client's SMC Confirm CLC message, it associates its QP with the client's QP as learned from the SMC Confirm CLC message and sends a confirmation LLC message. The rest of the flow, with the confirmation QP and setup of additional SMC-R links, unfolds just like the "first contact" case.
サーバーは、クライアントのSMC確認CLCメッセージを受信すると、SMC確認CLCメッセージから学習したように、そのQPをクライアントのQPに関連付け、確認LLCメッセージを送信します。残りのフローは、確認のQPと追加のSMC-Rリンクの設定により、「最初の連絡」の場合と同様に展開されます。
The normal socket API trigger points are used by the SMC-R layer to initiate SMC-R connection termination flows. The main design point for SMC-R normal connection flows is to use the SMC-R protocol to first shut down the SMC-R connection and free up any SMC-R RDMA resources, and then allow the normal TCP connection termination protocol (i.e., FIN processing) to drive cleanup of the TCP connection that exists on the IP fabric. This design point is very important in ensuring that RDMA resources such as the RMBEs are only freed and reused when both SMC-R endpoints are completely done with their RDMA write operations to the partner's RMBE.
通常のソケットAPIトリガーポイントは、SMC-RレイヤーがSMC-R接続終了フローを開始するために使用します。 SMC-Rの通常の接続フローの主な設計ポイントは、SMC-Rプロトコルを使用して最初にSMC-R接続をシャットダウンし、SMC-R RDMAリソースを解放してから、通常のTCP接続終了プロトコル（つまり、 FIN処理）を使用して、IPファブリックに存在するTCP接続のクリーンアップを実行します。この設計ポイントは、RMBEなどのRDMAリソースが解放され、再利用されるのは、両方のSMC-RエンドポイントがパートナーのRMBEへのRDMA書き込み操作で完全に完了した場合にのみ重要です。
When the last TCP connection over an SMC-R link group terminates, the link group can be terminated. Similar to creation of SMC-R links and link groups, the primary responsibility for determining that normal termination is needed and initiating it lies with the server.
SMC-Rリンクグループを介した最後のTCP接続が終了すると、リンクグループを終了できます。 SMC-Rリンクおよびリンクグループの作成と同様に、正常終了が必要であると判断して開始する主な責任はサーバーにあります。
Implementations may opt to set timers to keep SMC-R link groups up for a specified time after the last TCP connection ends, to avoid churn in cases where TCP connections come and go regularly.
実装は、最後のTCP接続が終了した後、指定された時間SMC-Rリンクグループを維持するようにタイマーを設定して、TCP接続が定期的に行き来する場合のチャーンを回避することを選択できます。
The link or link group may also be terminated as a result of a command initiated by the operator. This command can be entered at either the client or the server. If entered at the client, the client requests that the server perform link or link group termination, and the responsibility for doing so ultimately lies with the server.
リンクまたはリンクグループは、オペレータが開始したコマンドの結果として終了する場合もあります。このコマンドは、クライアントまたはサーバーで入力できます。クライアントで入力した場合、クライアントはサーバーにリンクまたはリンクグループの終了を実行するように要求します。これを実行する責任は最終的にサーバーにあります。
When the server determines that the SMC-R link group is to be terminated, it sends a DELETE LINK LLC message to the client, with a flag set indicating that all links in the link group are to be terminated. After receiving confirmation from the adapter that the DELETE LINK LLC message has been sent, the server can clean up its end of the link group (QPs, RMBs, etc.). Upon receipt of the DELETE LINK message from the server, the client must immediately comply and clean up its end of the link group. Any TCP connections that the client believes to be active on the link group must be immediately terminated.
サーバーは、SMC-Rリンクグループを終了する必要があると判断すると、リンクグループ内のすべてのリンクを終了することを示すフラグを設定したDELETE LINK LLCメッセージをクライアントに送信します。 DELETE LINK LLCメッセージが送信されたというアダプターからの確認を受け取った後、サーバーはリンクグループの最後（QP、RMBなど）をクリーンアップできます。クライアントは、サーバーからDELETE LINKメッセージを受信すると、ただちに準拠し、リンクグループの末尾をクリーンアップする必要があります。クライアントがリンクグループでアクティブであると考えるTCP接続は、直ちに終了する必要があります。
The client can request that the server delete the link group as well. The client does this by sending a DELETE LINK message to the server, indicating that cleanup of all links is requested. The server must comply by sending a DELETE LINK to the client and processing as described in the previous paragraph. If there are TCP connections active on the link group when the server receives this request, they are immediately terminated by sending a RST flow over the IP fabric.
クライアントは、サーバーがリンクグループも削除することを要求できます。クライアントは、サーバーにDELETE LINKメッセージを送信してこれを行い、すべてのリンクのクリーンアップが要求されていることを示します。サーバーは、DELETE LINKをクライアントに送信し、前の段落で説明したように処理することにより、準拠する必要があります。サーバーがこの要求を受信したときにリンクグループでアクティブなTCP接続がある場合、それらはIPファブリックを介してRSTフローを送信することによって直ちに終了されます。
The server has the lead role in managing the composition of the link group. Links are added to the link group by the server. The client may notify the server of new conditions that may result in the server adding a new link, but the server is ultimately responsible. In general, links are deleted from the link group by the server; however, in certain error cases the client may inform the server that a link must be deleted and treat it as deleted without waiting for action from the server. These flows are detailed in the sections that follow.
サーバーは、リンクグループの構成の管理において主導的な役割を果たします。リンクは、サーバーによってリンクグループに追加されます。クライアントは、サーバーに新しいリンクを追加する可能性のある新しい条件をサーバーに通知しますが、サーバーが最終的に責任を負います。一般に、リンクはサーバーによってリンクグループから削除されます。ただし、特定のエラーの場合、クライアントはサーバーにリンクを削除する必要があることをサーバーに通知し、サーバーからのアクションを待たずにリンクを削除済みとして処理する場合があります。これらのフローについては、以降のセクションで詳しく説明します。
As described in previous sections, the server initiates an ADD LINK exchange to create redundancy in a newly created link group. Once a link group is established, the server may also initiate ADD LINK for other reasons, including:
前のセクションで説明したように、サーバーはADD LINK交換を開始して、新しく作成されたリンクグループに冗長性を作成します。リンクグループが確立されると、サーバーは次のような他の理由でADD LINKを開始する場合もあります。
o Availability of additional resources on the server host to support an additional SMC-R link. This may include the provisioning of an additional RNIC, more storage becoming available to support additional QP resources, operator command, or any other implementation-dependent reason. Note that in order to be available for an existing link group a new RNIC must be attached to the same RoCE LAN that the link group is using.
o 追加のSMC-Rリンクをサポートするためのサーバーホスト上の追加リソースの可用性。これには、追加のRNICのプロビジョニング、追加のQPリソース、オペレーターコマンド、またはその他の実装に依存する理由をサポートするために利用可能なストレージの増加が含まれる場合があります。既存のリンクグループで使用できるようにするには、リンクグループが使用しているのと同じRoCE LANに新しいRNICを接続する必要があることに注意してください。
o Receipt of notification from the client that additional resources on the client are available to support an additional SMC-R link. See Section 3.5.5.1.2 ("Client-Initiated ADD LINK Processing").
o 追加のSMC-Rリンクをサポートするためにクライアント上の追加のリソースが利用可能であるというクライアントからの通知の受信。セクション3.5.5.1.2（「クライアントが開始するADD LINK処理」）を参照してください。
Server-initiated ADD LINK processing in an established SMC-R link group is the same as the ADD LINK processing described in Section 3.5.1.6 ("Second SMC-R Link Setup"), with the following changes:
確立されたSMC-Rリンクグループでのサーバー起動のADD LINK処理は、セクション3.5.1.6（「2番目のSMC-Rリンクの設定」）で説明されているADD LINK処理と同じですが、次の変更点があります。
o If an asymmetric SMC-R link already exists in the link group, a second asymmetric link will not be created. Only one asymmetric link is permitted in a link group.
o 非対称SMC-Rリンクがリンクグループに既に存在する場合、2番目の非対称リンクは作成されません。リンクグループで許可される非対称リンクは1つだけです。
o TCP data flow on already-existing link(s) in the link group is not halted or otherwise affected during the process of setting up the additional link.
o リンクグループ内の既存のリンク上のTCPデータフローは、追加リンクのセットアッププロセス中に停止されたり、影響を受けたりすることはありません。
The server will not initiate ADD LINK processing if the link group already has the maximum number of links negotiated by the partners.
リンクグループがパートナーによってネゴシエートされたリンクの最大数を既に持っている場合、サーバーはADD LINK処理を開始しません。
If an additional RNIC becomes available for an existing SMC-R link group on the client's side, the client notifies the server by sending an ADD LINK request LLC message to the server. Unlike an ADD LINK request sent by the server to the client, this ADD LINK request merely informs the server that the client has a new RNIC. If the link group lacks redundancy or has redundancy only on an asymmetric link with a single RNIC on the client side, the server must initiate an ADD LINK exchange in response to this message, to create or improve the link group's redundancy.
追加のRNICがクライアント側の既存のSMC-Rリンクグループで利用可能になると、クライアントはサーバーにADD LINK要求LLCメッセージを送信してサーバーに通知します。サーバーからクライアントに送信されるADD LINK要求とは異なり、このADD LINK要求は、クライアントに新しいRNICがあることをサーバーに通知するだけです。リンクグループに冗長性がないか、クライアント側に単一のRNICを持つ非対称リンクでのみ冗長性がある場合、サーバーはこのメッセージに応答してADD LINK交換を開始し、リンクグループの冗長性を作成または改善する必要があります。
If the link group already has symmetric-link redundancy but has fewer than the negotiated maximum number of links, the server may respond by initiating an ADD LINK exchange to create a new link using the client's new resource but is not required to do so.
リンクグループに既に対称リンクの冗長性があるが、ネゴシエートされたリンクの最大数よりも少ない場合、サーバーはADD LINK交換を開始することで応答し、クライアントの新しいリソースを使用して新しいリンクを作成しますが、そうする必要はありません。
If the link group already has the negotiated maximum number of links, the server must ignore the client's ADD LINK request LLC message.
リンクグループに既にネゴシエートされたリンクの最大数がある場合、サーバーはクライアントのADD LINK要求LLCメッセージを無視する必要があります。
Because the server is not required to respond to the client's ADD LINK LLC message in all cases, the client must not wait for a response or throw an error if one does not come.
サーバーはすべての場合にクライアントのADD LINK LLCメッセージに応答する必要がないため、応答がない場合、クライアントは応答を待ったり、エラーをスローしたりしてはなりません。
Reasons that a server may delete a link include the following:
サーバーがリンクを削除する理由には、次のものがあります。
o The link has not been used for TCP connections for an implementation-defined time interval, and deleting the link will not cause the link group to lack redundancy.
o リンクは実装定義の時間間隔でTCP接続に使用されておらず、リンクを削除してもリンクグループの冗長性が失われることはありません。
o Errors in resources supporting the link occur. These errors may include, but are not limited to, RNIC errors, QP errors, and software errors.
o リンクをサポートするリソースでエラーが発生します。これらのエラーには、RNICエラー、QPエラー、およびソフトウェアエラーが含まれますが、これらに限定されません。
o The RNIC supporting this SMC-R link is being taken down, either because of an error case or because of an operator or software command.
o このSMC-RリンクをサポートするRNICは、エラーが発生したか、オペレーターまたはソフトウェアコマンドが原因で、停止しています。
If a link being deleted is supporting TCP connections and there are one or more surviving links in the link group, the TCP connections are moved to the surviving links. For more information on this processing, see Section 2.3 ("SMC-R Resilience and Load Balancing").
削除されるリンクがTCP接続をサポートしていて、リンクグループに1つ以上の存続リンクがある場合、TCP接続は存続リンクに移動されます。この処理の詳細については、セクション2.3（「SMC-Rの復元力と負荷分散」）を参照してください。
The server deletes a link from the link group by sending a DELETE LINK request LLC message to the client over any of the usable links in the link group. Because the DELETE LINK LLC message specifies which link is to be deleted, it may flow over any link in the link group. The server must not clean up its RoCE resources for the link until the client responds.
サーバーは、リンクグループ内の使用可能なリンクのいずれかを介してクライアントにDELETE LINKリクエストLLCメッセージを送信することにより、リンクグループからリンクを削除します。 DELETE LINK LLCメッセージは削除するリンクを指定しているため、リンクグループ内のリンクを介してフローする可能性があります。サーバーは、クライアントが応答するまで、リンクのRoCEリソースをクリーンアップしてはなりません。
The client responds to the server's DELETE LINK request LLC message by sending the server a DELETE LINK response LLC message. The client must respond positively; it cannot decline to delete the link. Once the server has received the client's DELETE LINK response, both sides may clean up their resources for the link.
クライアントは、サーバーにDELETE LINK応答LLCメッセージを送信することにより、サーバーのDELETE LINK要求LLCメッセージに応答します。クライアントは積極的に応答する必要があります。リンクの削除を辞退することはできません。サーバーがクライアントのDELETE LINK応答を受信すると、リンクの両方のリソースをクリーンアップできます。
Either a positive write completion or some other indication from the RNIC on the client's side is sufficient to indicate to the client that the server has received the DELETE LINK response.
サーバーがDELETE LINK応答を受信したことをクライアントに示すには、クライアント側のRNICからの肯定的な書き込み完了または他の何らかの指示で十分です。
Host X Host Y
+-------------------+ +-------------------+
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 9 |
|RToken X| |Failed|<--X----X----X----X-->| | |
| | | | | | |
| \/ +------+ +------+ |
|+--------+ | | |
|| Deleted| | | |
|| RMB | | | |
|| | | | |
|+--------+ | | |
| /\ +------+ +------+ |
|RToken Z| | | SMC-R Link 2 | | |
| | |RNIC 3|<-------------------->|RNIC 4| |
| QP 64| | | | QP 65 |
| +------+ +------+ |
+-------------------+ +-------------------+
DELETE LINK(request, link number = 1,
................................................>
reason code = RNIC failure)
DELETE LINK(response, link number = 1)
<................................................
(Note: Architecturally, this exchange can flow over either SMC-R link but most likely flows over Link 2, since the RNIC for Link 1 has failed.)
（注：アーキテクチャー上、この交換はいずれかのSMC-Rリンクを介してフローできますが、リンク1のRNICが失敗したため、リンク2を介してフローする可能性が高いです。
Figure 10: Server-Initiated DELETE LINK Flow
図10：サーバー起動のDELETE LINKフロー
The client may request that the server delete a link for the same reasons that the server may delete a link, except for inactivity timeout.
クライアントは、非アクティブタイムアウトを除いて、サーバーがリンクを削除するのと同じ理由で、サーバーがリンクを削除することを要求する場合があります。
Because the client depends on the server to delete links, there are two types of delete requests from client to server:
クライアントはリンクを削除するためにサーバーに依存しているため、クライアントからサーバーへの削除要求には2つのタイプがあります。
o Orderly: The client is requesting that the server delete the link when able. This would result from an operator command to bring down the RNIC or some other nonfatal reason. In this case, the server is required to delete the link but may not do it right away.
o 整然とした：クライアントは、サーバーが可能な場合にリンクを削除するように要求しています。これは、RNICを停止するためのオペレーターコマンドまたはその他の致命的でない理由が原因です。この場合、サーバーはリンクを削除する必要がありますが、すぐに削除できない場合があります。
o Disorderly: The server must delete the link right away, because the client has experienced a fatal error with the link.
o 順不同：クライアントがリンクで致命的なエラーを経験したため、サーバーはリンクをすぐに削除する必要があります。
In either case, the server responds by initiating a DELETE LINK exchange with the client, as described in the previous section. The difference between the two is whether the server must do so immediately or can delay for an opportunity to gracefully delete the link.
いずれの場合も、前のセクションで説明したように、サーバーはクライアントとのDELETE LINK交換を開始することによって応答します。 2つの違いは、サーバーがすぐに実行する必要があるか、リンクを適切に削除する機会のために遅延する可能性があるかです。
Host X Host Y
+-------------------+ +-------------------+
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 9 |
|RToken X| | |<---X--X--X--X--X--X->|Failed| |
| | | | | | |
| \/ +------+ +------+ |
|+--------+ | | |
|| Deleted| | | |
|| RMB | | | |
|| | | | |
|+--------+ | | |
| /\ +------+ +------+ |
|RToken Z| | | SMC-R Link 2 | | |
| | |RNIC 3|<-------------------->|RNIC 4| |
| QP 64| | | | QP 65 |
| +------+ +------+ |
+-------------------+ +-------------------+
DELETE LINK(request, link number = 1, disorderly,
<...............................................
reason code = RNIC failure)
DELETE LINK(request, link number = 1,
................................................>
reason code = RNIC failure)
DELETE LINK(response, link number = 1)
<................................................
(Note: Architecturally, this exchange can flow over either SMC-R link but most likely flows over Link 2, since the RNIC for Link 1 has failed.)
（注：アーキテクチャー上、この交換はいずれかのSMC-Rリンクを介してフローできますが、リンク1のRNICが失敗したため、リンク2を介してフローする可能性が高いです。
Figure 11: Client-Initiated DELETE LINK Flow
図11：クライアントが開始するDELETE LINKフロー
3.5.5.2. Managing Multiple RKeys over Multiple SMC-R Links in a Link Group
3.5.5.2. リンクグループ内の複数のSMC-Rリンクを介した複数のRKeyの管理
After the initial contact sequence completes and the number of TCP connections increases, it is possible that the SMC peers could add more RMBs to the link group. Recall that each peer independently manages its RMBs. Also recall that an RMB's RToken is specific to a QP, which means that when there are multiple SMC-R links in a link group, each RMB accessed with the link group requires a separate RToken for each SMC-R link in the group.
最初のコンタクトシーケンスが完了し、TCP接続の数が増えると、SMCピアがリンクグループにさらにRMBを追加する可能性があります。各ピアがRMBを個別に管理することを思い出してください。また、RMBのRTokenはQPに固有であることを思い出してください。つまり、リンクグループに複数のSMC-Rリンクがある場合、リンクグループでアクセスされる各RMBには、グループ内の各SMC-Rリンクに個別のRTokenが必要です。
Each RMB that is added to a link must be added to all links within the link group. The set of RMBs created for the link is called the "RToken set". The RTokens must be exchanged with the peer. As RMBs are added and deleted, the RToken set must remain in sync.
リンクに追加された各RMBは、リンクグループ内のすべてのリンクに追加する必要があります。リンク用に作成されたRMBのセットは、「RTokenセット」と呼ばれます。 RTokenはピアと交換する必要があります。 RMBが追加および削除されると、RTokenセットは同期を維持する必要があります。
A new RMB can be added to an SMC-R link group on either the client side or the server side. When an additional RMB is added to an existing SMC-R link group, that RMB must be associated with the QPs for each link in the link group. Therefore, when an RMB is added to an SMC-R link group, its RMB RToken for each SMC-R link's QP must be communicated to the peer.
新しいRMBは、クライアント側またはサーバー側のSMC-Rリンクグループに追加できます。追加のRMBが既存のSMC-Rリンクグループに追加される場合、そのRMBはリンクグループ内の各リンクのQPに関連付ける必要があります。したがって、RMBがSMC-Rリンクグループに追加されると、各SMC-RリンクのQPのRMB RTokenがピアに通信される必要があります。
The tokens for a new RMB added to an existing SMC-R link group are communicated using CONFIRM RKEY LLC messages, as shown in Figure 12. The RToken set is specified as pairs: an SMC-R link number, paired with the new RMB's RToken over that SMC-R link. To preserve failover capability, any TCP connection that uses a newly added RMB cannot go active until all RTokens for the RMB have been communicated for all of the links in the link group.
既存のSMC-Rリンクグループに追加された新しいRMBのトークンは、図12に示すように、CONFIRM RKEY LLCメッセージを使用して通信されます。RTokenセットは、ペアとして指定されます：新しいRMBのRTokenとペアになったSMC-Rリンク番号そのSMC-Rリンクを介して。フェイルオーバー機能を維持するために、新しく追加されたRMBを使用するTCP接続は、RMBのすべてのRTokenがリンクグループ内のすべてのリンクで通信されるまでアクティブにできません。
Host X Host Y
+-------------------+ +-------------------+
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 9 |
|RToken X| | |<-------------------->| | |
| | | | | | |
| \/ +------+ +------+ |
|+--------+ | | |
|| New | | | |
|| RMB | | | |
|| | | | |
|+--------+ | | |
| /\ +------+ +------+ |
|RToken Z| | | SMC-R Link 2 | | |
| | |RNIC 3|<-------------------->|RNIC 4| |
| QP 64| | | | QP 65 |
| +------+ +------+ |
+-------------------+ +-------------------+
CONFIRM RKEY(request, Add,
................................................>
RToken set((Link 1,RToken X),(Link 2,RToken Z)))
CONFIRM RKEY(response, Add,
<................................................
RToken set((Link 1,RToken X),(Link 2,RToken Z)))
(Note: This exchange can flow over either SMC-R link.)
（注：この交換は、いずれかのSMC-Rリンクを介してフローできます。）
Figure 12: Add RMB to Existing Link Group
図12：既存のリンクグループへのRMBの追加
Implementations may choose to proactively add RMBs to link groups in anticipation of need. For example, an implementation may add a new RMB when a certain usage threshold (e.g., percentage used) for all of its existing RMBs has been exceeded.
実装では、必要に応じて、積極的にRMBをリンクグループに追加することを選択できます。たとえば、実装は、既存のすべてのRMBの特定の使用量しきい値（たとえば、使用率）を超えたときに、新しいRMBを追加する場合があります。
A new RMB may also be added to an existing link group on an as-needed basis -- for example, when a new TCP connection is added to the link group but there are no available RMB elements. In this case, the CLC exchange is paused while the peer that requires the new RMB adds it. An example of this is illustrated in Figure 13.
新しいRMBは、既存のリンクグループに必要に応じて追加することもできます。たとえば、新しいTCP接続がリンクグループに追加されたが、使用可能なRMB要素がない場合などです。この場合、新しいRMBを必要とするピアがCLC交換を追加する間、CLC交換は一時停止されます。この例を図13に示します。
Host X -- Server Host Y -- Client
+-------------------+ +--------------------+
| Peer ID = PS1 | | Peer ID = PC1 |
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 64 |
|RToken X| |MAC MA|<-------------------->|MAC MB| | |
| | |GID GA| |GID GB| |RToken Y2|
| \/ +------+ +------+ \/ |
|+--------+ | | +--------+ |
|| | | Subnet S1 | | New | |
|| RMB | | | | RMB | |
|+--------+ | | +--------+ |
| /\ +------+ +------+ /\ |
| | |RNIC 3| SMC-R Link 2 |RNIC 4| |RToken W2|
| | |MAC MC|<-------------------->|MAC MD| | |
| QP 9 |GID GC| |GID GD| QP 65 |
| +------+ +------+ |
+-------------------+ +--------------------+
SYN / SYN-ACK / ACK TCP three-way handshake with TCP option
<--------------------------------------------------------->
SMC Proposal(PC1,MB,GB,S1)
<--------------------------------------------------------
SMC Accept(PS1,not 1st contact,MA,GA,QP8,RToken=X,RMB elem index)
--------------------------------------------------------->
CONFIRM RKEY(request, Add,
<........................................................
RToken set((Link 1,RToken Y2),(Link 2,RToken W2)))
CONFIRM RKEY(response, Add,
........................................................>
RToken set((Link 1,RToken Y2),(Link 2,RToken W2)))
SMC Confirm(PC1,MB,GB,QP64,RToken=Y2, RMB element index)
<--------------------------------------------------------
Legend:
------------ TCP/IP and CLC flows
............ RoCE (LLC) flows
Figure 13: Client Adds RMB during TCP Connection Setup
図13：TCP接続のセットアップ中にクライアントがRMBを追加
Either peer can delete one or more of its RMBs as long as it is not being used for any TCP connections. Ideally, an SMC-R peer would use a timer to avoid freeing an RMB immediately after the last TCP connection stops using it, to keep the RMB available for later TCP connections and avoid thrashing with addition and deletion of RMBs. Once an SMC-R peer decides to delete an RMB, it sends a DELETE RKEY LLC message to its peer. It can then free the RMB once it receives a response from the peer. Multiple RMBs can be deleted in a DELETE RKEY exchange.
いずれのピアも、TCP接続に使用されていない限り、RMBの1つ以上を削除できます。理想的には、SMC-Rピアはタイマーを使用して、最後のTCP接続がRMBの使用を停止した直後にRMBが解放されないようにし、RMBを以降のTCP接続で使用できるようにし、RMBの追加と削除によるスラッシングを回避します。 SMC-Rピアは、RMBを削除することを決定すると、DELETE RKEY LLCメッセージをピアに送信します。その後、ピアからの応答を受信すると、RMBを解放できます。 DELETE RKEY交換で複数のRMBを削除できます。
Note that in a DELETE RKEY message, it is not necessary to specify the full RToken for a deleted RMB. The RMB's RKey over one link in the link group is sufficient to specify which RMB is being deleted.
DELETE RKEYメッセージでは、削除されたRMBの完全なRTokenを指定する必要がないことに注意してください。リンクグループ内の1つのリンクに対するRMBのRKeyは、削除されるRMBを指定するのに十分です。
Host X Host Y
+-------------------+ +-------------------+
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 9 |
|RToken X| | |<-------------------->| | |
| | | | | | |
| \/ +------+ +------+ |
|+--------+ | | |
|| Deleted| | | |
|| RMB | | | |
|| | | | |
|+--------+ | | |
| /\ +------+ +------+ |
|RToken Z| | | SMC-R Link 2 | | |
| | |RNIC 3|<-------------------->|RNIC 4| |
| QP 9 | | | | |
| +------+ +------+ |
+-------------------+ +-------------------+
DELETE RKEY(request, RKey list(RKey X))
................................................>
DELETE RKEY(response, RKey list(RKey X))
<................................................
(Note: This exchange can flow over either SMC-R link.)
（注：この交換は、いずれかのSMC-Rリンクを介してフローできます。）
Figure 14: Delete RMB from SMC-R Link Group
図14：SMC-RリンクグループからのRMBの削除
When a new SMC-R link is added to an existing link group, there could be multiple RMBs on each side already associated with the link group. There could also be a different number of RMBs on one side than on the other, because each peer manages its RMBs independently. Each of these RMBs will require a new RToken to be used on the new SMC-R link, and those new RTokens must then be communicated to the peer. This requires two-way communication, as the server will have to communicate its RTokens to the client and vice versa.
新しいSMC-Rリンクが既存のリンクグループに追加されると、リンクグループに既に関連付けられている両側に複数のRMBが存在する可能性があります。各ピアがRMBを個別に管理するため、一方の側と他方の側で異なる数のRMBが存在する可能性もあります。これらの各RMBは、新しいSMC-Rリンクで使用される新しいRTokenを必要とし、それらの新しいRTokenはピアに伝達される必要があります。サーバーはRTokenをクライアントに、またはその逆に通信する必要があるため、双方向通信が必要です。
RTokens are communicated between peers in pairs. Each RToken pair consists of:
RTokenはペアでピア間で通信されます。各RTokenペアは次のもので構成されます。
o The RToken for the RMB, as is already known on an existing SMC-R link in the link group.
o リンクグループの既存のSMC-Rリンクですでに知られている、RMBのRToken。
o The RToken for the same RMB, to be used on the new SMC-R link.
o 新しいSMC-Rリンクで使用される、同じRMBのRToken。
These pairs are required to ensure that each peer knows which RTokens across QPs are equivalent.
これらのペアは、各ピアがQP間でどのRTokenが同等であるかを確実に認識するために必要です。
The ADD LINK request and response LLC messages do not have enough space to contain any RToken pairs. ADD LINK CONTINUATION LLC messages are used to communicate these pairs, as shown in Figure 15. The ADD LINK CONTINUATION LLC messages are sent on the same SMC-R link that the ADD LINK LLC messages were sent over, and in both the ADD LINK and ADD LINK CONTINUATION LLC messages the first RToken in each RToken pair will be the RToken for the RMB as known on the SMC-R link over which the LLC message is being sent.
ADD LINK要求および応答LLCメッセージには、RTokenペアを含めるのに十分なスペースがありません。 ADD LINK CONTINUATION LLCメッセージは、図15に示すように、これらのペアの通信に使用されます。ADDLINK CONTINUATION LLCメッセージは、ADD LINK LLCメッセージが送信されたのと同じSMC-Rリンクで送信され、ADD LINKとADD LINK CONTINUATION LLCメッセージは、各RTokenペアの最初のRTokenが、LLCメッセージが送信されるSMC-Rリンクで既知のRMBのRTokenになります。
Host X -- Server Host Y -- Client
+-------------------+ +-------------------+
| Peer ID = PS1 | | Peer ID = PC1 |
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 64 |
|RKey set| |MAC MA|<-------------------->|MAC MB| |RKey set|
|X,Y,Z | |GID GA| |GID GB| |Q,R,S,T |
| \/ +------+ +------+ \/ |
|+--------+ | | +--------+ |
|| 3 RMBs | | | | 4 RMBs | |
|+--------+ | | +--------+ |
| /\ +------+ +------+ /\ |
|RKey set| |RNIC 3| SMC-R Link 2 |RNIC 4| | RKey set|
|U,V,W | |MAC MC|<-------------------->|MAC MD| | L,M,N,P |
| QP 9 |GID GC| (being added) |GID GD| QP 65 |
| +------+ +------+ |
+-------------------+ +-------------------+
ADD LINK request (QP9,MC,GC, link number = 2)
............................................>
ADD LINK response (QP65,MD,GD, link number = 2)
<............................................
ADD LINK CONTINUATION req(RToken pairs=((X,U),(Y,V),(Z,W)))
............................................>
ADD LINK CONTINUATION rsp(RToken pairs=((Q,L),(R,M),(S,N),(T,P)))
<.............................................
CONFIRM LINK req/rsp exchange on Link 2
<.............................................>
Legend:
------------ TCP/IP and CLC flows
............ RoCE (LLC) flows
Figure 15: Exchanging RKeys when a New Link Is Added to a Link Group
図15：新しいリンクがリンクグループに追加されたときのRKeyの交換
LLC flows can be divided into two main groups for serialization considerations.
LLCフローは、シリアライゼーションを考慮して2つの主要なグループに分けることができます。
The first group is LLC messages that are independent and can flow at any time. These are one-time, unsolicited messages that either do not have a required response or have a simple response that does not interfere with the operations of another group of messages. These messages are as follows:
最初のグループは、独立していていつでも流れることができるLLCメッセージです。これらは、必要な応答がないか、別のメッセージグループの操作を妨げない単純な応答のいずれかである、1回限りの非請求メッセージです。これらのメッセージは次のとおりです。
o TEST LINK from either the client or the server: This message requires a TEST LINK response to be returned but does not affect the configuration of the link group or the RKeys.
o クライアントまたはサーバーからのTEST LINK：このメッセージはTEST LINK応答を返す必要がありますが、リンクグループまたはRKeyの構成には影響しません。
o ADD LINK from the client to the server: This message is provided as an "FYI" to the server to let it know that the client has an additional RNIC available. The server is not required to act upon or respond to this message.
o クライアントからサーバーへのリンクの追加：このメッセージは、「FYI」としてサーバーに提供され、クライアントに追加のRNICが使用可能であることを通知します。サーバーは、このメッセージを処理したり、このメッセージに応答したりする必要はありません。
o DELETE LINK from the client to the server: This message informs the server that either (1) the client has experienced an error or problem that requires a link or link group to be terminated or (2) an operator has commanded that a link or link group be terminated. The server does not respond directly to the message; rather, it initiates a DELETE LINK exchange as a result of receiving it.
o クライアントからサーバーへのリンクの削除：このメッセージは、（1）クライアントでリンクまたはリンクグループの終了が必要なエラーまたは問題が発生したか、（2）オペレーターがリンクまたはリンクにコマンドを発行したことをサーバーに通知しますグループを終了します。サーバーはメッセージに直接応答しません。むしろ、それを受信した結果としてDELETE LINK交換を開始します。
o DELETE LINK from the server to the client, with the "delete entire link group" flag set: This message informs the client that the entire link group is being deleted.
o 「リンクグループ全体を削除」フラグが設定されたサーバーからクライアントへのリンクの削除：このメッセージは、リンクグループ全体が削除されていることをクライアントに通知します。
The second group is LLC messages that are part of an exchange of LLC messages that affects link group configuration; this exchange must complete before another exchange of LLC messages that affects link group configuration can be processed. When a peer knows that one of these exchanges is in progress, it must not start another exchange. These exchanges are as follows:
2番目のグループは、リンクグループの設定に影響するLLCメッセージの交換の一部であるLLCメッセージです。この交換は、リンクグループの構成に影響するLLCメッセージの別の交換が処理される前に完了する必要があります。ピアは、これらの交換の1つが進行中であることを知っている場合、別の交換を開始してはなりません。これらの交換は次のとおりです。
o ADD LINK / ADD LINK response / ADD LINK CONTINUATION / ADD LINK CONTINUATION response / CONFIRM LINK / CONFIRM LINK response: This exchange, by adding a new link, changes the configuration of the link group.
o リンクの追加/リンクの追加応答/リンクの継続の追加/リンクの継続の追加応答/リンクの確認/リンクの確認応答：この交換では、新しいリンクを追加することにより、リンクグループの構成が変更されます。
o DELETE LINK / DELETE LINK response initiated by the server, without the "delete entire link group" flag set: This exchange, by deleting a link, changes the configuration of the link group.
o 「リンクグループ全体を削除」フラグが設定されていない、サーバーによって開始されたDELETE LINK / DELETE LINK応答：この交換は、リンクを削除することにより、リンクグループの構成を変更します。
o CONFIRM RKEY / CONFIRM RKEY response or DELETE RKEY / DELETE RKEY response: This exchange changes the RMB configuration of the link group. RKeys cannot change while links are being added or deleted (while an ADD LINK or DELETE LINK is in progress). However, CONFIRM RKEY and DELETE RKEY are unique in that both the client and server can independently manage (add or remove) their own RMBs. This allows each peer to concurrently change their RKeys and therefore concurrently send CONFIRM RKEY or DELETE RKEY requests. The concurrent CONFIRM RKEY or DELETE RKEY requests can be independently processed and do not represent a collision.
o CONFIRM RKEY / CONFIRM RKEY応答またはDELETE RKEY / DELETE RKEY応答：この交換により、リンクグループのRMB構成が変更されます。リンクの追加中または削除中（ADD LINKまたはDELETE LINKの実行中）は、RKeyを変更できません。ただし、CONFIRM RKEYとDELETE RKEYは、クライアントとサーバーの両方が独自のRMBを個別に管理（追加または削除）できるという点でユニークです。これにより、各ピアはRKeyを同時に変更できるため、CONFIRM RKEYまたはDELETE RKEY要求を同時に送信できます。同時CONFIRM RKEYまたはDELETE RKEY要求は個別に処理でき、衝突を表すものではありません。
Because the server is in control of the configuration of the link group, many timing windows and collisions are avoided, but there are still some that must be handled.
サーバーはリンクグループの構成を制御しているため、多くのタイミングウィンドウと衝突が回避されますが、処理する必要のあるウィンドウがまだいくつかあります。
Colliding LLC message: TEST LINK
LLCメッセージの衝突：TEST LINK
Action to resolve: Send immediate TEST LINK reply.
解決策：TEST LINKの返信をすぐに送信します。
Colliding LLC message: ADD LINK from client to server
衝突するLLCメッセージ：クライアントからサーバーへのリンクの追加
Action to resolve: Server ignores the ADD LINK message. When client receives server's ADD LINK, client will consider that message to be in response to its ADD LINK message and the flow works. Since both client and server know not to start this exchange if an ADD LINK operation is already underway, this can only occur if the client sends this message before receiving the server's ADD LINK and this message crosses with the server's ADD LINK message; therefore, the server's ADD LINK arrives at the client immediately after the client sent this message.
解決策：サーバーはADD LINKメッセージを無視します。クライアントがサーバーのADD LINKを受信すると、クライアントはそのメッセージがそのADD LINKメッセージへの応答であると見なし、フローが機能します。 ADD LINK操作がすでに実行されている場合、クライアントとサーバーの両方がこの交換を開始しないことを知っているため、これは、クライアントがサーバーのADD LINKを受信する前にこのメッセージを送信し、このメッセージがサーバーのADD LINKメッセージと交差する場合にのみ発生します。したがって、サーバーのADD LINKは、クライアントがこのメッセージを送信した直後にクライアントに到着します。
Colliding LLC message: DELETE LINK from client to server, specific link specified
競合するLLCメッセージ：クライアントからサーバーへのDELETE LINK、特定のリンクが指定されています
Action to resolve: Server queues the DELETE LINK message and processes it after the ADD LINK exchange completes. If it is an orderly link termination, it can wait until after this exchange continues. If it is disorderly and the link affected is the one that the current exchange is using, the server will discover the outage when a message in this exchange fails.
解決するアクション：サーバーはDELETE LINKメッセージをキューに入れ、ADD LINK交換の完了後にそれを処理します。正常なリンク終了の場合は、この交換が続くまで待機できます。それが無秩序であり、影響を受けるリンクが現在の交換が使用しているリンクである場合、サーバーは、この交換のメッセージが失敗したときに停止を検出します。
Colliding LLC message: DELETE LINK from client to server, entire link group to be deleted
競合するLLCメッセージ：クライアントからサーバーへのDELETE LINK、リンクグループ全体が削除されます
Action to resolve: Immediately clean up the link group.
解決策：リンクグループをすぐにクリーンアップします。
Colliding LLC message: CONFIRM RKEY from client
衝突するLLCメッセージ：クライアントからのRKEYの確認
Action to resolve: Send a negative CONFIRM RKEY response to the client. Once the current exchange finishes, client will have to recompute its RKey set to include the new link and then start a new CONFIRM RKEY exchange.
解決策：否定的なCONFIRM RKEY応答をクライアントに送信します。現在の交換が完了すると、クライアントはRKeyセットを再計算して新しいリンクを含め、新しいCONFIRM RKEY交換を開始する必要があります。
Colliding LLC message: TEST LINK from either peer
競合するLLCメッセージ：いずれかのピアからのTEST LINK
Action to resolve: Send immediate TEST LINK response.
解決策：TEST LINK応答をすぐに送信します。
Colliding LLC message: ADD LINK from client to server
衝突するLLCメッセージ：クライアントからサーバーへのリンクの追加
Action to resolve: Server queues the ADD LINK and processes it after the current exchange completes.
解決するアクション：サーバーはADD LINKをキューに入れ、現在の交換が完了した後にそれを処理します。
Colliding LLC message: DELETE LINK from client to server (specific link)
競合するLLCメッセージ：クライアントからサーバーへのDELETE LINK（特定のリンク）
Action to resolve: Server queues the DELETE LINK message and processes it after the current exchange completes. If it is an orderly link termination, it can wait until after this exchange continues. If it is disorderly and the link affected is the one that the current exchange is using, the server will discover the outage when a message in this exchange fails.
解決するアクション：サーバーはDELETE LINKメッセージをキューに入れ、現在の交換が完了した後にそれを処理します。正常なリンク終了の場合は、この交換が続くまで待機できます。それが無秩序であり、影響を受けるリンクが現在の交換が使用しているリンクである場合、サーバーは、この交換のメッセージが失敗したときに停止を検出します。
Colliding LLC message: DELETE LINK from either client or server, deleting the entire link group
競合するLLCメッセージ：クライアントまたはサーバーからのDELETE LINK、リンクグループ全体の削除
Action to resolve: Immediately clean up the link group.
解決策：リンクグループをすぐにクリーンアップします。
Colliding LLC message: CONFIRM RKEY from client to server
競合するLLCメッセージ：クライアントからサーバーへのRKEYの確認
Action to resolve: Send a negative CONFIRM RKEY response to the client. Once the current exchange finishes, client will have to recompute its RKey set to include the new link and then start a new CONFIRM RKEY exchange.
解決策：否定的なCONFIRM RKEY応答をクライアントに送信します。現在の交換が完了すると、クライアントはRKeyセットを再計算して新しいリンクを含め、新しいCONFIRM RKEY交換を開始する必要があります。
Colliding LLC message: TEST LINK
LLCメッセージの衝突：TEST LINK
Action to resolve: Send immediate TEST LINK reply.
解決策：TEST LINKの返信をすぐに送信します。
Colliding LLC message: ADD LINK from client to server
衝突するLLCメッセージ：クライアントからサーバーへのリンクの追加
Action to resolve: Queue the ADD LINK, and process it after the current exchange completes.
解決するアクション：ADD LINKをキューに入れ、現在の交換が完了した後に処理します。
Colliding LLC message: ADD LINK from server to client (CONFIRM RKEY exchange was initiated by the client, and it crossed with the server initiating an ADD LINK exchange)
衝突するLLCメッセージ：サーバーからクライアントへのADD LINK（CONFIRM RKEY交換はクライアントによって開始され、サーバーと交差してADD LINK交換を開始しました）
Action to resolve: Process the ADD LINK. Client will receive a negative CONFIRM RKEY from the server and will have to redo this CONFIRM RKEY exchange after the ADD LINK exchange completes.
解決策：リンクの追加を処理します。クライアントはサーバーから負のCONFIRM RKEYを受け取り、ADD LINK交換が完了した後でこのCONFIRM RKEY交換をやり直す必要があります。
Colliding LLC message: DELETE LINK from client to server, specific link to be deleted (CONFIRM RKEY exchange was initiated by the server, and it crossed with the client's DELETE LINK request)
衝突するLLCメッセージ：クライアントからサーバーへのDELETE LINK、削除される特定のリンク（CONFIRM RKEY交換がサーバーによって開始され、クライアントのDELETE LINK要求と交差しました）
Action to resolve: Server queues the DELETE LINK message and processes it after the CONFIRM RKEY exchange completes. If it is an orderly link termination, it can wait until after this exchange continues. If it is disorderly and the link affected is the one that the current exchange is using, the server will discover the outage when a message in this exchange fails.
解決するアクション：サーバーはDELETE LINKメッセージをキューに入れ、CONFIRM RKEY交換が完了した後にそれを処理します。正常なリンク終了の場合は、この交換が続くまで待機できます。それが無秩序であり、影響を受けるリンクが現在の交換が使用しているリンクである場合、サーバーは、この交換のメッセージが失敗したときに停止を検出します。
Colliding LLC message: DELETE LINK from server to client, specific link deleted (CONFIRM RKEY exchange was initiated by the client, and it crossed with the server's DELETE LINK)
競合するLLCメッセージ：サーバーからクライアントへのDELETE LINK、特定のリンクが削除されました（CONFIRM RKEY交換がクライアントによって開始され、サーバーのDELETE LINKと交差しました）
Action to resolve: Process the DELETE LINK. Client will receive a negative CONFIRM RKEY from the server and will have to redo this CONFIRM RKEY exchange after the ADD LINK exchange completes.
解決策：DELETE LINKを処理します。クライアントはサーバーから負のCONFIRM RKEYを受け取り、ADD LINK交換が完了した後でこのCONFIRM RKEY交換をやり直す必要があります。
Colliding LLC message: DELETE LINK from either client or server, entire link group deleted
衝突するLLCメッセージ：クライアントまたはサーバーからDELETE LINK、リンクグループ全体が削除されました
Action to resolve: Immediately clean up the link group.
解決策：リンクグループをすぐにクリーンアップします。
Colliding LLC message: CONFIRM LINK from the peer that did not start the current CONFIRM LINK exchange
競合するLLCメッセージ：現在のCONFIRM LINK交換を開始しなかったピアからのCONFIRM LINK
Action to resolve: Queue the request, and process it after the current exchange completes.
解決するアクション：要求をキューに入れ、現在の交換が完了した後で処理します。
Each TCP connection using SMC-R must be allocated an RMBE by each SMC-R peer. This allocation is performed by each endpoint independently to allow each endpoint to select an RMBE that best matches the characteristics on its TCP socket endpoint. The RMBE associated with a TCP socket endpoint must have a receive buffer that is at least as large as the TCP receive buffer size in effect for that connection. The receive buffer size can be determined by what is specified explicitly by the application using setsockopt() or implicitly via the system-configured default value. This will allow sufficient data to be RDMA-written by the SMC-R peer to fill an entire receive buffer size's worth of data on a given data flow. Given that each RMB must have fixed-length RMBEs, this implies that an SMC-R endpoint may need to maintain multiple RMBs of various sizes for SMC-R connections on a given SMC-R link and can then select an RMBE that most closely fits a connection.
SMC-Rを使用する各TCP接続には、各SMC-RピアによってRMBEを割り当てる必要があります。この割り当ては各エンドポイントによって個別に実行され、各エンドポイントがTCPソケットエンドポイントの特性に最も一致するRMBEを選択できるようにします。 TCPソケットエンドポイントに関連付けられたRMBEには、少なくともその接続で有効なTCP受信バッファーサイズと同じ大きさの受信バッファーが必要です。受信バッファーのサイズは、アプリケーションがsetsockopt()を使用して明示的に指定するか、システム構成のデフォルト値を介して暗黙的に指定することによって決定できます。これにより、SMC-Rピアが十分なデータをRDMAで書き込み、特定のデータフローで受信バッファサイズに相当するデータ全体を満たすことができます。各RMBに固定長のRMBEが必要であることを考えると、SMC-Rエンドポイントは、特定のSMC-Rリンク上のSMC-R接続に対してさまざまなサイズの複数のRMBを維持する必要があり、最も密接に適合するRMBEを選択できることを意味します接続。
An RMB is a virtual memory buffer whose backing real memory is pinned. The RMB is subdivided into a whole number of equal-sized RMB Elements (RMBEs). Each RMBE begins with a 4-byte eye catcher for diagnostic and service purposes, followed by the receive data buffer. The contents of this diagnostic eye catcher are implementation dependent and should be used by the local SMC-R peer to check for overlay errors by verifying an intact eye catcher with every RMBE access.
RMBは、バッキング実メモリが固定されている仮想メモリバッファです。 RMBは、等しいサイズのRMB要素（RMBE）の整数に細分されます。各RMBEは、診断とサービスの目的で4バイトのアイキャッチャーで始まり、その後に受信データバッファーが続きます。この診断アイキャッチャーの内容は実装に依存し、すべてのRMBEアクセスで完全なアイキャッチャーを検証することにより、オーバーレイエラーをチェックするためにローカルSMC-Rピアが使用する必要があります。
The RMBE is a wrapping receive buffer for receiving RDMA writes from the peer. Cursors, as described below, are exchanged between peers to manage and track RDMA writes and local data reads from the RMBE for a TCP connection.
RMBEは、ピアからのRDMA書き込みを受信するためのラッピング受信バッファーです。以下で説明するように、カーソルはピア間で交換され、TCP接続のRBEからのRDMA書き込みとローカルデータ読み取りを管理および追跡します。
RMBE control information consists of consumer cursors, producer cursors, wrap counts, CDC message sequence numbers, control flags such as urgent data and "writer blocked" indicators, and TCP connection information such as termination flags. This information is exchanged between SMC-R peers using CDC messages, which are passed using RoCE SendMsg. A TCP/IP stack implementing SMC-R must receive and store this information in its internal data structures, as it is used to manage the RMBE and its data buffer.
RMBE制御情報は、コンシューマーカーソル、プロデューサーカーソル、ラップカウント、CDCメッセージシーケンス番号、緊急データや「ライターブロック」インジケーターなどの制御フラグ、および終了フラグなどのTCP接続情報で構成されます。この情報は、RoC SendMsgを使用して渡されるCDCメッセージを使用してSMC-Rピア間で交換されます。 SMC-Rを実装するTCP / IPスタックは、RMBEとそのデータバッファーの管理に使用されるため、この情報を受信して内部データ構造に格納する必要があります。
The format and contents of the CDC message are described in detail in Appendix A.4 ("Connection Data Control (CDC) Message Format"). The following is a high-level description of what this control information contains.
CDCメッセージの形式と内容については、付録A.4（「接続データ制御（CDC）メッセージの形式」）で詳しく説明しています。以下は、この制御情報に含まれる内容の概要です。
o Connection state flags such as sending done, connection closed, failover data validation, and abnormal close.
o 送信完了、接続終了、フェイルオーバーデータ検証、異常終了などの接続状態フラグ。
o A sequence number that is managed by the sender. This sequence number starts at 1, is increased each send, and wraps to 0. This sequence number tracks the CDC message sent and is not related to the number of bytes sent. It is used for failover data validation.
o 送信者が管理するシーケンス番号。このシーケンス番号は1から始まり、送信ごとに増加し、0に折り返されます。このシーケンス番号は送信されたCDCメッセージを追跡し、送信されたバイト数とは関係ありません。フェイルオーバーデータの検証に使用されます。
o Producer cursor: a wrapping offset into the receiver's RMBE data area. Set by the peer that is writing into the RMBE, it points to where the writing peer will write the next byte of data into an RMBE. This cursor is accompanied by a wrap sequence number to help the RMBE owner (the receiver) identify full window size wrapping writes. Note that this cursor must account for (i.e., skip over) the RMBE eye catcher that is in the beginning of the data area.
o プロデューサーカーソル：レシーバーのRMBEデータ領域への折り返しオフセット。 RMBEに書き込むピアによって設定され、ピアがRMBEにデータの次のバイトを書き込む場所を指します。このカーソルには、RMBE所有者（受信者）が全ウィンドウサイズの折り返し書き込みを識別できるようにする折り返しシーケンス番号が付いています。このカーソルは、データ領域の先頭にあるRMBEアイキャッチャーを考慮する（つまり、スキップする）必要があることに注意してください。
o Consumer cursor: a wrapping offset into the receiver's RMBE data area. Set by the owner of the RMBE (the peer that is reading from it), this cursor points to the offset of the next byte of data to be consumed by the peer in its own RMBE. The sender cannot write beyond this cursor into the receiver's RMBE without causing data loss. Like the producer cursor, this is accompanied by a wrap count to help the writer identify full window size wrapping reads. Note that this cursor must account for (i.e., skip over) the RMBE eye catcher that is in the beginning of the data area.
o コンシューマーカーソル：レシーバーのRMBEデータ領域への折り返しオフセット。 RMBEの所有者（RMBEから読み取るピア）によって設定され、このカーソルは、自身のRMBE内のピアによって消費されるデータの次のバイトのオフセットを指します。送信側は、データの損失を引き起こすことなく、このカーソルを超えて受信側のRMBEに書き込むことはできません。プロデューサーカーソルと同様に、これには、ライターが全ウィンドウサイズのラッピング読み取りを識別するのに役立つ折り返しカウントが伴います。このカーソルは、データ領域の先頭にあるRMBEアイキャッチャーを考慮する（つまり、スキップする）必要があることに注意してください。
o Data flags such as urgent data, writer blocked indicator, and cursor update requests.
o 緊急データ、書き込み禁止標識、カーソル更新要求などのデータフラグ。
The RMBE eye catcher is initialized by the RMB owner prior to assigning it to a specific TCP connection and communicating its RMB index to the SMC-R partner. After an RMBE index is communicated to the SMC-R partner, the RMBE can only be referenced in "read-only mode" by the owner, and all updates to it are performed by the remote SMC-R partner via RDMA write operations.
RMBEアイキャッチャーは、特定のTCP接続に割り当て、そのRMBインデックスをSMC-Rパートナーに伝達する前に、RMB所有者によって初期化されます。 RMBEインデックスがSMC-Rパートナーに通信された後、RMBEは所有者によって「読み取り専用モード」でのみ参照でき、それに対するすべての更新はRDMA書き込み操作を介してリモートSMC-Rパートナーによって実行されます。
Initialization of an RMBE must include the following:
RMBEの初期化には、以下を含める必要があります。
o Zeroing out the entire RMBE receive buffer, which helps minimize data integrity issues (e.g., data from a previous connection somehow being presented to the current connection).
o RMBE受信バッファー全体をゼロにすることで、データの整合性の問題（たとえば、以前の接続からのデータが何らかの形で現在の接続に提示されているなど）を最小限に抑えることができます。
o Setting the beginning RMBE eye catcher. This eye catcher plays an important role in helping detect accidental overlays of the RMBE. The RMB owner should always validate these eye catchers before each new reference to the RMBE. If the eye catchers are found to be corrupted, the local host must reset the TCP connection associated with this RMBE and log the appropriate diagnostic information.
o 最初のRMBEアイキャッチャーを設定します。この目印は、RMBEの偶発的なオーバーレイの検出を支援する上で重要な役割を果たします。 RMBの所有者は、RMBEへの新しい参照の前に常にこれらの目印を検証する必要があります。目印が破損していることが判明した場合、ローカルホストはこのRMBEに関連付けられているTCP接続をリセットし、適切な診断情報をログに記録する必要があります。
RMB elements can be reused once their associated TCP and SMC-R connections are terminated. Under normal and abnormal SMC-R connection termination processing, both SMC-R peers must explicitly acknowledge that they are done using an RMBE before that element can be freed and reassigned to another SMC-R connection instance. For more details on SMC-R connection termination, refer to Section 4.8.
RMBエレメントは、関連するTCPおよびSMC-R接続が終了すると再利用できます。通常および異常なSMC-R接続終了処理では、両方のSMC-Rピアは、その要素が解放されて別のSMC-R接続インスタンスに再割り当てされる前に、RMBEを使用して行われたことを明示的に確認する必要があります。 SMC-R接続終了の詳細については、セクション4.8を参照してください。
However, there are some error scenarios where this two-way explicit acknowledgment may not be completed. In these scenarios, an RMBE owner may choose to reassign this RMBE to a new SMC-R connection instance on this SMC-R link group. When this occurs, the partner SMC-R peer must detect this condition during SMC-R Rendezvous processing when presented with an RMBE that it believes is already in use for a different SMC-R connection. In this case, the SMC-R peer must abort the existing SMC-R connection associated with this RMBE. The abort processing resets the TCP connection (if it is still active), but it must not attempt to perform any RDMA writes to this RMBE and must also ignore any data sitting in the local RMBE associated with the existing connection. It then proceeds to free up the local RMBE and notify the local application that the connection is being abnormally reset.
ただし、この双方向の明示的な確認応答が完了しない可能性があるいくつかのエラーシナリオがあります。これらのシナリオでは、RMBE所有者は、このRMBEをこのSMC-Rリンクグループの新しいSMC-R接続インスタンスに再割り当てすることを選択できます。これが発生した場合、パートナーのSMC-Rピアは、別のSMC-R接続ですでに使用されていると信じるRMBEが提示されると、SMC-Rランデブー処理中にこの状態を検出する必要があります。この場合、SMC-Rピアは、このRMBEに関連付けられている既存のSMC-R接続を中止する必要があります。中止処理はTCP接続をリセットします（まだアクティブな場合）が、このRMBEへのRDMA書き込みを実行してはならず、既存の接続に関連付けられたローカルRMBEにあるデータを無視する必要もあります。次に、ローカルRMBEを解放し、接続が異常にリセットされていることをローカルアプリケーションに通知します。
The remote SMC-R peer then proceeds to normal processing for this new SMC-R connection.
次に、リモートSMC-Rピアは、この新しいSMC-R接続の通常の処理に進みます。
The following sections describe considerations for the SMC-R protocol as compared to TCP.
以下のセクションでは、TCPと比較した場合のSMC-Rプロトコルの考慮事項について説明します。
An SMC-R receiver host sends its consumer cursor information to the sender to convey the progress that the receiving application has made in consuming the sent data. The difference between the writer's producer cursor and the associated receiver's consumer cursor indicates the window size available for the sender to write into. This is somewhat similar to TCP window update processing and therefore has some similar considerations, such as silly window syndrome avoidance, whereby TCP has an optimization that minimizes the overhead of very small, unproductive window size updates associated with suboptimal socket applications consuming very small amounts of data on every receive() invocation. For SMC-R, the receiver only updates its consumer cursor via a unique CDC message under the following conditions:
SMC-Rレシーバーホストは、コンシューマーカーソル情報をセンダーに送信して、受信したアプリケーションが送信したデータを消費する際の進捗状況を伝えます。ライターのプロデューサーカーソルと関連するレシーバーのコンシューマーカーソルの違いは、センダーが書き込みに使用できるウィンドウサイズを示します。これは、TCPウィンドウ更新処理にいくらか似ているため、愚かなウィンドウシンドロームの回避など、いくつかの同様の考慮事項があります。これにより、TCPは、非常に少量を消費する次善のソケットアプリケーションに関連する非常に小さい非生産的なウィンドウサイズ更新のオーバーヘッドを最小限に抑える最適化を行います。すべてのreceive()呼び出しに関するデータ。 SMC-Rの場合、受信者は次の条件下で一意のCDCメッセージを介してコンシューマーカーソルのみを更新します。
o The current window size (from a sender's perspective) is less than half of the receive buffer space, and the consumer cursor update will result in a minimum increase in the window size of 10% of the receive buffer space. Some examples:
o 現在のウィンドウサイズ（送信者の観点から）は、受信バッファースペースの半分未満であり、コンシューマーカーソルの更新により、受信バッファースペースの10％のウィンドウサイズが最小限増加します。いくつかの例：
a. Receive buffer size: 64K, current window size (from a sender's perspective): 50K. No need to update the consumer cursor. Plenty of space is available for the sender.
a. 受信バッファーサイズ：64K、現在のウィンドウサイズ（送信者の観点から）：50K。コンシューマーカーソルを更新する必要はありません。送信者は十分なスペースを利用できます。
b. Receive buffer size: 64K, current window size (from a sender's perspective): 30K, current window size from a receiver's perspective: 31K. No need to update the consumer cursor; even though the sender's window size is < 1/2 of the 64K, the window update would only increase that by 1K, which is < 1/10th of the 64K buffer size.
b. 受信バッファサイズ：64K、現在のウィンドウサイズ（送信者の観点から）：30K、受信者の観点からの現在のウィンドウサイズ：31K。コンシューマーカーソルを更新する必要はありません。送信者のウィンドウサイズが64Kの1/2未満である場合でも、ウィンドウの更新では64Kバッファサイズの1/10未満である1Kしか増加しません。
c. Receive buffer size: 64K, current window size (from a sender's perspective): 30K, current window size from a receiver's perspective: 64K. The receiver updates the consumer cursor (sender's window size is < 1/2 of the 64K; the window update would increase that by > 6.4K).
c. 受信バッファサイズ：64K、現在のウィンドウサイズ（送信者の観点から）：30K、受信者の観点からの現在のウィンドウサイズ：64K。受信者はコンシューマカーソルを更新します（送信者のウィンドウサイズは64Kの1/2未満です。ウィンドウの更新によりそれは> 6.4K増加します）。
o The receiver must always include a consumer cursor update whenever it sends a CDC message to the partner for another flow (i.e., send flow in the opposite direction). This allows the window size update to be delivered with no additional overhead. This is somewhat similar to TCP DelayAck processing and quite effective for request/response data patterns.
o レシーバーは、CDCメッセージを別のフローのパートナーに送信するとき（つまり、フローを反対方向に送信するとき）は常にコンシューマーカーソルの更新を含める必要があります。これにより、追加のオーバーヘッドなしでウィンドウサイズの更新を配信できます。これは、TCP DelayAck処理にいくらか似ており、要求/応答データパターンに対して非常に効果的です。
o If a peer has set the B-bit in a CDC message, then any consumption of data by the receiver causes a CDC message to be sent, updating the consumer cursor until a CDC message with that bit cleared is received from the peer.
o ピアがCDCメッセージでBビットを設定した場合、レシーバーによるデータの消費によりCDCメッセージが送信され、そのビットがクリアされたCDCメッセージがピアから受信されるまでコンシューマーカーソルが更新されます。
o The optimized window size updates are overridden when the sender sets the Consumer Cursor Update Requested flag in a CDC message to the receiver. When this indicator is on, the consumer must send a consumer cursor update immediately when data is consumed by the local application or if the cursor has not been updated for a while (i.e., local copy of the consumer cursor does not match the last consumer cursor value sent to the partner). This allows the sender to perform optional diagnostics for detecting a stalled receiver application (data has been sent but not consumed). It is recommended that the Consumer Cursor Update Requested flag only be sent for diagnostic procedures, as it may result in non-optimal data path performance.
o 最適化されたウィンドウサイズの更新は、送信者が受信者へのCDCメッセージでコンシューマーカーソルの更新要求フラグを設定すると上書きされます。このインジケーターがオンの場合、コンシューマーは、ローカルアプリケーションによってデータが消費されたとき、またはカーソルがしばらく更新されていない場合（つまり、コンシューマーカーソルのローカルコピーが最後のコンシューマーカーソルと一致しない場合）、コンシューマーカーソルの更新をすぐに送信する必要があります。パートナーに送信される値）。これにより、送信側はオプションの診断を実行して、停止した受信側アプリケーションを検出できます（データは送信されましたが消費されていません）。データパスのパフォーマンスが最適ではなくなる可能性があるため、コンシューマーカーソルの更新要求フラグは診断手順でのみ送信することをお勧めします。
The SMC-R protocol makes no special provisions for handling small data segments sent across a stream socket. Data is always sent if sufficient window space is available. In contrast to the TCP Nagle algorithm, there are no special provisions in SMC-R for coalescing small data segments.
SMC-Rプロトコルは、ストリームソケットを介して送信される小さなデータセグメントを処理するための特別なプロビジョニングを行いません。十分なウィンドウスペースが利用可能な場合、データは常に送信されます。 TCP Nagleアルゴリズムとは対照的に、SMC-Rには小さなデータセグメントを結合するための特別な規定はありません。
An implementation of SMC-R can be configured to optimize its sending processing by coalescing outbound data for a given SMC-R connection so that it can reduce the number of RDMA write operations it performs, in a fashion similar to Nagle's algorithm. However, any such coalescing would require a timer on the sending host that would ensure that data was eventually sent. Also, the sending host would have to opt out of this processing if Nagle's algorithm had been disabled (programmatically or via system configuration).
SMC-Rの実装は、Nagleのアルゴリズムと同様の方法で、それが実行するRDMA書き込み操作の数を減らすことができるように、特定のSMC-R接続の送信データを合体させることによって送信処理を最適化するように構成できます。ただし、そのような合体には、データが最終的に送信されることを保証するタイマーが送信ホストに必要です。また、Nagleのアルゴリズムが（プログラムで、またはシステム構成を介して）無効になっている場合、送信ホストはこの処理をオプトアウトする必要があります。
TCP keepalive processing allows applications to direct the local TCP/IP host to periodically "test" the viability of an idle TCP connection. Since SMC-R connections have a TCP representation along with an SMC-R representation, there are unique keepalive processing considerations:
TCPキープアライブ処理により、アプリケーションはローカルTCP / IPホストに、アイドル状態のTCP接続の実行可能性を定期的に「テスト」するよう指示できます。 SMC-R接続にはSMC-R表現とともにTCP表現があるため、キープアライブ処理に関する独自の考慮事項があります。
o SMC-R-layer keepalive processing: If keepalive is enabled for an SMC-R connection, the local host maintains a keepalive timer that reflects how long an SMC-R connection has been idle. The local host also maintains a timestamp of last activity for each SMC-R link (for any SMC-R connection on that link). When it is determined that an SMC-R connection has been idle longer than the keepalive interval, the host checks to see whether or not the SMC-R link has been idle for a duration longer than the keepalive timeout. If both conditions are met, the local host then performs a TEST LINK LLC command to test the viability of the SMC-R link over the RoCE fabric (RC-QPs). If a TEST LINK LLC command response is received within a reasonable amount of time, then the link is considered viable, and all connections using this link are considered viable as well. If, however, a response is not received in a reasonable amount of time or there's a failure in sending the TEST LINK LLC command, then this is considered a failure in the SMC-R link, and failover processing to an alternate SMC-R link must be triggered. If no alternate SMC-R link exists in the SMC-R link group, then all of the SMC-R connections on this link are abnormally terminated by resetting the TCP connections represented by these SMC-R connections. Given that multiple SMC-R connections can share the same SMC-R link, implementing an SMC-R link-level probe using the TEST LINK LLC command will help reduce the amount of unproductive keepalive traffic for SMC-R connections; as long as some SMC-R connections on a given SMC-R link are active (i.e., have had I/O activity within the keepalive interval), then there is no need to perform additional link viability testing.
o SMC-R層のキープアライブ処理：SMC-R接続でキープアライブが有効になっている場合、ローカルホストは、SMC-R接続がアイドル状態であった時間を反映するキープアライブタイマーを維持します。ローカルホストは、各SMC-Rリンク（そのリンク上のSMC-R接続の場合）の最後のアクティビティのタイムスタンプも保持します。 SMC-R接続がキープアライブインターバルよりも長い間アイドル状態であると判断された場合、ホストは、SMC-Rリンクがキープアライブタイムアウトよりも長い時間アイドル状態であったかどうかを確認します。両方の条件が満たされると、ローカルホストはTEST LINK LLCコマンドを実行して、RoCEファブリック（RC-QP）を介したSMC-Rリンクの実行可能性をテストします。 TEST LINK LLCコマンド応答が妥当な時間内に受信された場合、リンクは実行可能と見なされ、このリンクを使用するすべての接続も実行可能と見なされます。ただし、妥当な時間内に応答が受信されない場合、またはTEST LINK LLCコマンドの送信に失敗した場合、これはSMC-Rリンクの障害と見なされ、代替のSMC-Rリンクへのフェイルオーバー処理が行われます。トリガーする必要があります。 SMC-Rリンクグループに代替SMC-Rリンクが存在しない場合、これらのSMC-R接続で表されるTCP接続をリセットすることにより、このリンク上のすべてのSMC-R接続が異常終了します。複数のSMC-R接続が同じSMC-Rリンクを共有できる場合、TEST LINK LLCコマンドを使用してSMC-Rリンクレベルのプローブを実装すると、SMC-R接続の非生産的なキープアライブトラフィックの量を減らすのに役立ちます。特定のSMC-Rリンク上の一部のSMC-R接続がアクティブである（つまり、キープアライブインターバル内にI / Oアクティビティがあった）限り、追加のリンク実行可能性テストを実行する必要はありません。
o TCP-layer keepalive processing: Traditional TCP "keepalive" packets are not as relevant for SMC-R connections, given that the TCP path is not used for these connections once the SMC-R Rendezvous processing is completed. All SMC-R connections by default have associated TCP connections that are idle. Are TCP keepalive probes still needed for these connections? There are two main scenarios to consider:
o TCP層のキープアライブ処理：SMC-Rランデブー処理が完了すると、TCPパスがこれらの接続に使用されないため、従来のTCP「キープアライブ」パケットはSMC-R接続にそれほど関係ありません。デフォルトでは、すべてのSMC-R接続に、アイドル状態のTCP接続が関連付けられています。これらの接続には、TCPキープアライブプローブが必要ですか？考慮すべき主なシナリオが2つあります。
1. TCP keepalives that are used to determine whether or not the peer TCP endpoint is still active. This is not needed for SMC-R connections, as the SMC-R-level keepalives mentioned above will determine whether or not the remote endpoint connections are still active.
1. ピアTCPエンドポイントがまだアクティブかどうかを判断するために使用されるTCPキープアライブ。上記のSMC-Rレベルのキープアライブがリモートエンドポイント接続がまだアクティブであるかどうかを決定するため、これはSMC-R接続には必要ありません。
2. TCP keepalives that are used to ensure that TCP connections traversing an intermediate proxy maintain an active state. For example, stateful firewalls typically maintain state representing every valid TCP connection that traverses the firewall. These types of firewalls are known to expire idle connections by removing their state in the firewall to conserve memory. TCP keepalives are often used in this scenario to prevent firewalls from timing out otherwise idle connections. When using SMC-R, both endpoints must reside in the same Layer 2 network (i.e., the same subnet). As a result, firewalls cannot be injected in the path between two SMC-R endpoints. However, other intermediate proxies, such as TCP/IP-layer load balancers, may be injected in the path of two SMC-R endpoints. These types of load balancers also maintain connection state so that they can forward TCP connection traffic to the appropriate cluster endpoint. When using SMC-R, these TCP connections will appear to be completely idle, making them susceptible to potential timeouts at the load-balancing proxy. As a result, for this scenario, TCP keepalives may still be relevant.
2. 中間プロキシを通過するTCP接続がアクティブな状態を維持することを保証するために使用されるTCPキープアライブ。たとえば、ステートフルファイアウォールは通常、ファイアウォールを通過するすべての有効なTCP接続を表す状態を維持します。これらのタイプのファイアウォールは、メモリを節約するためにファイアウォールの状態を削除することにより、アイドル接続を期限切れにすることが知られています。このシナリオでは、ファイアウォールが他の方法でアイドル接続をタイムアウトするのを防ぐために、TCPキープアライブがよく使用されます。 SMC-Rを使用する場合、両方のエンドポイントが同じレイヤー2ネットワーク（つまり、同じサブネット）に存在する必要があります。その結果、2つのSMC-Rエンドポイント間のパスにファイアウォールを挿入できません。ただし、TCP / IPレイヤーロードバランサーなどの他の中間プロキシは、2つのSMC-Rエンドポイントのパスに挿入される場合があります。これらのタイプのロードバランサーは、TCP接続トラフィックを適切なクラスターエンドポイントに転送できるように、接続状態も維持します。 SMC-Rを使用する場合、これらのTCP接続は完全にアイドル状態のように見え、負荷分散プロキシでの潜在的なタイムアウトの影響を受けやすくなります。その結果、このシナリオでは、TCPキープアライブが依然として関連している可能性があります。
The following are the TCP-level keepalive processing requirements for SMC-R-enabled hosts:
以下は、SMC-R対応ホストのTCPレベルのキープアライブ処理要件です。
o SMC-R peers should allow TCP keepalives to flow on the TCP path of SMC-R connections based on existing TCP keepalive configuration and programming options. However, it is strongly recommended that platforms provide the ability to specify very granular keepalive timers (for example, single-digit-second timers) and should consider providing a configuration option that limits the minimum keepalive timer that will be used for TCP-layer keepalives on SMC-R connections. This is important to minimize the amount of TCP keepalive packets transmitted in the network for SMC-R connections.
o SMC-Rピアは、既存のTCPキープアライブ構成とプログラミングオプションに基づいて、SMC-R接続のTCPパス上でTCPキープアライブが流れることを許可する必要があります。ただし、非常に細かいキープアライブタイマー（たとえば、1桁の秒のタイマー）を指定する機能をプラットフォームに提供し、TCPレイヤーキープアライブに使用される最小キープアライブタイマーを制限する構成オプションの提供を検討することを強くお勧めしますSMC-R接続で。これは、SMC-R接続のネットワークで送信されるTCPキープアライブパケットの量を最小限に抑えるために重要です。
o SMC-R peers must always respond to inbound TCP-layer keepalives (by sending ACKs for these packets) even if the connection is using SMC-R. Typically, once a TCP connection has completed the SMC-R Rendezvous processing and is using SMC-R for data flows, no new inbound TCP segments are expected on that TCP connection, other than TCP termination segments (FIN, RST, etc.). TCP keepalives are the one exception that must be supported. Also, since TCP keepalive probes do not carry any application-layer data, this has no adverse impact on the application's inbound data stream.
o SMC-Rピアは、接続がSMC-Rを使用している場合でも、常に（これらのパケットのACKを送信することにより）着信TCP層のキープアライブに応答する必要があります。通常、TCP接続がSMC-Rランデブー処理を完了し、データフローにSMC-Rを使用している場合、そのTCP接続では、TCP終了セグメント（FIN、RSTなど）以外の新しいインバウンドTCPセグメントは予期されません。 TCPキープアライブは、サポートする必要がある1つの例外です。また、TCPキープアライブプローブはアプリケーション層のデータを伝送しないため、アプリケーションの受信データストリームに悪影響を与えることはありません。
A peer may change which SMC-R link within a link group it sends its writes over in the event of a link failure. Since each peer independently chooses which link to send writes over for a specific TCP connection, this process is done independently by each peer.
ピアは、リンク障害が発生した場合に書き込みを送信するリンクグループ内のSMC-Rリンクを変更する場合があります。各ピアは特定のTCP接続に対して書き込みを送信するリンクを独立して選択するため、このプロセスは各ピアによって独立して行われます。
Even though RoCE is a reliable transport, there is a small subset of failure modes that could cause unrecoverable loss of data. When an RNIC acknowledges receipt of an RDMA write to its peer, that creates a write completion event to the sending peer, which allows the sender to release any buffers it is holding for that write. In normal operation and in most failures, this operation is reliable.
RoCEは信頼性の高いトランスポートですが、データの回復不能な損失を引き起こす可能性がある障害モードの小さなサブセットがあります。 RNICは、ピアへのRDMA書き込みの受信を確認すると、送信ピアに書き込み完了イベントを作成します。これにより、送信側は、その書き込みのために保持しているバッファを解放できます。通常の操作およびほとんどの障害では、この操作は信頼できます。
However, there are failure modes possible in which a receiving RNIC has acknowledged an RDMA write but then was not able to place the received data into its host memory -- for example, a sudden, disorderly failure of the interface between the RNIC and the host. While rare, these types of events must be guarded against to ensure data integrity. The process for switching SMC-R links during failover, as described in this section, guards against this possibility and is mandatory.
ただし、受信側のRNICがRDMA書き込みを確認したが、受信したデータをホストメモリに配置できなかった障害モードがあります。たとえば、RNICとホスト間のインターフェースの突然の無秩序な障害。まれですが、これらのタイプのイベントは、データの整合性を確保するために保護する必要があります。このセクションで説明するように、フェイルオーバー中にSMC-Rリンクを切り替えるプロセスは、この可能性を防ぐために必須です。
Each peer must track the current state of the CDC sequence numbers for a TCP connection. The sender must keep track of the sequence number of the CDC message that described the last write acknowledged by the peer RNIC, or Sequence Sent (SS). In other words, SS describes the last write that the sender believes its peer has successfully received. The receiver must keep track of the sequence number of the CDC message that described the last write that it has successfully received (i.e., the data has been successfully placed into an RMBE), or Sequence Received (SR).
各ピアは、TCP接続のCDCシーケンス番号の現在の状態を追跡する必要があります。送信者は、ピアRNICまたはシーケンス送信（SS）によって確認応答された最後の書き込みを記述したCDCメッセージのシーケンス番号を追跡する必要があります。つまり、SSは、ピアが正常に受信したと送信者が信じている最後の書き込みを示します。受信者は、正常に受信した最後の書き込みを記述したCDCメッセージのシーケンス番号（つまり、データがRMBEに正常に配置された）またはシーケンス受信（SR）を追跡する必要があります。
When an RNIC fails and the sender changes SMC-R links, the sender must first send a CDC message with the F-bit (failover validation indicator; see Appendix A.4) set over the new SMC-R link. This is the failover data validation message. The sequence number in this CDC message is equal to SS. The CDC message key, the length, and the SMC-R alert token are the only other fields in this CDC message that are significant. No reply is expected from this validation message, and once the sender has sent it, the sender may resume sending on the new SMC-R link as described in Section 4.6.2.
RNICに障害が発生し、送信者がSMC-Rリンクを変更した場合、送信者はまず、新しいSMC-Rリンクに設定されたFビット（フェイルオーバー検証インジケーター、付録A.4を参照）が設定されたCDCメッセージを送信する必要があります。これは、フェイルオーバーデータ検証メッセージです。このCDCメッセージのシーケンス番号はSSと同じです。 CDCメッセージキー、長さ、およびSMC-Rアラートトークンは、このCDCメッセージの他の重要な唯一のフィールドです。この検証メッセージからの応答は予期されていません。送信者が送信すると、4.6.2で説明されているように、送信者は新しいSMC-Rリンクで送信を再開できます。
Upon receipt of the failover validation message, the receiver must verify that its SR value for the TCP connection is equal to or greater than the sequence number in the failover validation message. If so, no further action is required, and the TCP connection resumes on the new SMC-R link. If SR is less than the sequence number value in the validation message, data has been lost, and the receiver must immediately reset the TCP connection.
フェイルオーバー検証メッセージを受信すると、受信者は、TCP接続のSR値がフェイルオーバー検証メッセージのシーケンス番号以上であることを確認する必要があります。その場合、それ以上のアクションは不要であり、TCP接続は新しいSMC-Rリンクで再開されます。 SRが検証メッセージのシーケンス番号値よりも小さい場合、データは失われているため、受信者はTCP接続をただちにリセットする必要があります。
When a connection is moved to a new SMC-R link and the failover validation message has been sent, the sender can immediately resume normal transmission. In order to preserve the application message stream, the sender must replay any RDMA writes (and their associated CDC messages) that were in progress or failed when the previous SMC-R link failed, before sending new data on the new SMC-R link. The sender has two options for accomplishing this:
接続が新しいSMC-Rリンクに移動され、フェイルオーバー検証メッセージが送信されると、送信者は通常の送信をすぐに再開できます。アプリケーションメッセージストリームを保持するには、送信者は、新しいSMC-Rリンクで新しいデータを送信する前に、前のSMC-Rリンクが失敗したときに進行中または失敗したRDMA書き込み（および関連するCDCメッセージ）を再生する必要があります。送信者には、これを実行するための2つのオプションがあります。
o Preserve the sequence numbers "as is": Retry all failed and pending operations as they were originally done, including reposting all associated RDMA write operations and their associated CDC messages without making any changes. Then resume sending new data using new sequence numbers.
o シーケンス番号を「そのまま」保持：変更を行わずに、関連するすべてのRDMA書き込み操作と関連するCDCメッセージを再送信することを含め、失敗した操作と保留中の操作をすべて元どおりに再試行します。次に、新しいシーケンス番号を使用して新しいデータの送信を再開します。
o Combine pending messages and possibly add new data: Combine failed and pending messages into a single new write with a new sequence number. This allows the sender to combine pending messages into fewer operations. As a further optimization, this write can also include new data, as long as all failed and pending data are also included. If this approach is taken, the sequence number must be increased beyond the last failed or pending sequence number.
o 保留中のメッセージを結合し、場合によっては新しいデータを追加します。失敗したメッセージと保留中のメッセージを結合して、新しいシーケンス番号を持つ1つの新しい書き込みを作成します。これにより、送信者は保留中のメッセージをより少ない操作に結合できます。さらなる最適化として、この書き込みには、すべての失敗したデータと保留中のデータも含まれている限り、新しいデータを含めることもできます。このアプローチを採用する場合、シーケンス番号は、最後に失敗したか保留中のシーケンス番号を超えて増やす必要があります。
The following sections describe the RDMA wire flows for the SMC-R protocol after a TCP connection has switched into SMC-R mode (i.e., SMC-R Rendezvous processing is complete and a pair of RMB elements has been assigned and communicated by the SMC-R peers). The ladder diagrams below include the following:
次のセクションでは、TCP接続がSMC-Rモードに切り替わった後のSMC-RプロトコルのRDMAワイヤーフローについて説明します（つまり、SMC-Rランデブー処理が完了し、RMB要素のペアがSMC- Rピア）。以下のラダー図には、次のものが含まれています。
o RMBE control information kept by each peer. Only a subset of the information is depicted, specifically only the fields that reflect the stream of data written by Host A and read by Host B.
o 各ピアが保持するRMBE制御情報。情報のサブセット、特にホストAによって書き込まれ、ホストBによって読み取られたデータのストリームを反映するフィールドのみが示されています。
o Time line 0-x, which shows the wire flows in a time-relative fashion.
o タイムライン0-x。これは、ワイヤーが時間に相対して流れることを示します。
o Note that RMBE control information is only shown in a time interval if its value changed (otherwise, assume that the value is unchanged from the previously depicted value).
o RMBE制御情報は、その値が変更された場合にのみ時間間隔で表示されることに注意してください（そうでない場合、値は前に示した値から変更されていないと想定します）。
o The local copy of the producer cursors and consumer cursors that is maintained by each host is not depicted in these figures. Note that the cursor values in the diagram reflect the necessity of skipping over the eye catcher in the RMBE data area. They start and wrap at 4, not 0.
o これらの図には、各ホストによって維持されるプロデューサーカーソルとコンシューマーカーソルのローカルコピーは示されていません。図のカーソル値は、RMBEデータ領域でアイキャッチャーをスキップする必要性を反映していることに注意してください。それらは0ではなく4で開始してラップします。
SMC Host A SMC Host B
RMBE A Info RMBE B Info
(Consumer Cursors) (Producer Cursors)
Cursor Wrap Seq# Time Time Cursor Wrap Seq# Flags
4 0 0 0 4 0 0
0 0 1 ---------------> 1 0 0 0
RDMA-WR Data
(4:1003)
4 0 2 ...............> 2 1004 0 0
CDC Message
Figure 16: Scenario 1: Send Flow, Window Size Unconstrained
図16：シナリオ1：送信フロー、ウィンドウサイズの制約なし
Scenario assumptions:
シナリオの前提：
o Kernel implementation.
o カーネルの実装。
o New SMC-R connection; no data has been sent on the connection.
o 新しいSMC-R接続。接続でデータが送信されていません。
o Host A: Application issues send for 1000 bytes to Host B.
o ホストA：アプリケーションの問題は、ホストBに1000バイトを送信します。
o Host B: RMBE receive buffer size is 10,000; application has issued a recv for 10,000 bytes.
o ホストB：RMBE受信バッファーサイズは10,000です。アプリケーションが10,000バイトのrecvを発行しました。
Flow description:
フローの説明：
1. The application issues a send() for 1000 bytes; the SMC-R layer copies data into a kernel send buffer. It then schedules an RDMA write operation to move the data into the peer's RMBE receive buffer, at relative position 4-1003 (to skip the 4-byte eye catcher in the RMBE data area). Note that no immediate data or alert (i.e., interrupt) is provided to Host B for this RDMA operation.
1. アプリケーションは1000バイトのsend()を発行します。 SMC-Rレイヤーは、データをカーネル送信バッファーにコピーします。次に、RDMA書き込み操作をスケジュールして、データをピアのRMBE受信バッファーの相対位置4-1003に移動します（RMBEデータ領域の4バイトのアイキャッチャーをスキップするため）。このRDMA操作では、ホストBに即時のデータまたはアラート（つまり、割り込み）が提供されないことに注意してください。
2. Host A sends a CDC message to update the producer cursor to byte 1004. This CDC message will deliver an interrupt to Host B. At this point, the SMC-R layer can return control back to the application. Host B, once notified of the completion of the previous RDMA operation, locates the RMBE associated with the RMBE alert token that was included in the message and proceeds to perform normal receive-side processing, waking up the suspended application read thread, copying the data into the application's receive buffer, etc. It will use the producer cursor as an indicator of how much data is available to be delivered to the local application. After this processing is complete, the SMC-R layer will also update its local consumer cursor to match the producer cursor (i.e., indicating that all data has been consumed). Note that a message to the peer updating the consumer cursor is not needed at this time, as the window size is unconstrained (> 1/2 of the receive buffer size). The window size is calculated by taking the difference between the producer cursor and the consumer cursor in the RMBEs (10,000 - 1004 = 8996).
2. ホストAはCDCメッセージを送信して、プロデューサーカーソルをバイト1004に更新します。このCDCメッセージは、ホストBに割り込みを配信します。この時点で、SMC-Rレイヤーは制御をアプリケーションに戻すことができます。ホストBは、前のRDMA操作の完了を通知されると、メッセージに含まれていたRMBEアラートトークンに関連付けられたRMBEを特定し、通常の受信側の処理を実行し、中断されたアプリケーションの読み取りスレッドを起動し、データをコピーします。アプリケーションの受信バッファなどに送信します。ローカルアプリケーションに配信するために利用可能なデータの量を示すインジケータとして、プロデューサカーソルを使用します。この処理が完了すると、SMC-Rレイヤーは、プロデューサーカーソルと一致するようにローカルコンシューマーカーソルも更新します（つまり、すべてのデータが消費されたことを示します）。ウィンドウサイズが制限されていない（>受信バッファーサイズの1/2を超える）ため、コンシューマーカーソルを更新するピアへのメッセージは現時点では必要ありません。ウィンドウサイズは、RMBE内のプロデューサーカーソルとコンシューマーカーソルの差（10,000-1004 = 8996）を使用して計算されます。
SMC Host A SMC Host B
RMBE A Info RMBE B Info
(Consumer Cursors) (Producer Cursors)
Cursor Wrap Seq# Time Time Cursor Wrap Seq# Flags
4 0 0 0 4 0 0
0 0 1 ---------------> 1 0 0 0
RDMA-WR Data
(4:1003)
4 0 2 ...............> 2 1004 0 0
CDC Message
0 0 3 <-------------- 3 1004 0 0
RDMA-WR Data
(4:503)
1004 0 4 <.............. 4 1004 0 0
CDC Message
Figure 17: Scenario 2: Send/Receive Flow, Window Size Unconstrained
Scenario assumptions:
シナリオの前提：
o New SMC-R connection; no data has been sent on the connection.
o 新しいSMC-R接続。接続でデータが送信されていません。
o Host A: Application issues send for 1000 bytes to Host B.
o ホストA：アプリケーションの問題は、ホストBに1000バイトを送信します。
o Host B: RMBE receive buffer size is 10,000; application has already issued a recv for 10,000 bytes. Once the receive is completed, the application sends a 500-byte response to Host A.
o ホストB：RMBE受信バッファーサイズは10,000です。アプリケーションはすでに10,000バイトのrecvを発行しています。受信が完了すると、アプリケーションはホストAに500バイトの応答を送信します。
Flow description:
フローの説明：
1. The application issues a send() for 1000 bytes; the SMC-R layer copies data into a kernel send buffer. It then schedules an RDMA write operation to move the data into the peer's RMBE receive buffer, at relative position 4-1003. Note that no immediate data or alert (i.e., interrupt) is provided to Host B for this RDMA operation.
1. アプリケーションは1000バイトのsend()を発行します。 SMC-Rレイヤーは、データをカーネル送信バッファーにコピーします。次に、RDMA書き込み操作をスケジュールして、データをピアのRMBE受信バッファーの相対位置4-1003に移動します。このRDMA操作では、ホストBに即時のデータまたはアラート（つまり、割り込み）が提供されないことに注意してください。
2. Host A sends a CDC message to update the producer cursor to byte 1004. This CDC message will deliver an interrupt to Host B. At this point, the SMC-R layer can return control back to the application.
2. ホストAはCDCメッセージを送信して、プロデューサーカーソルをバイト1004に更新します。このCDCメッセージは、ホストBに割り込みを配信します。この時点で、SMC-Rレイヤーは制御をアプリケーションに戻すことができます。
3. Host B, once notified of the receipt of the previous CDC message, locates the RMBE associated with the RMBE alert token and proceeds to perform normal receive-side processing, waking up the suspended application read thread, copying the data into the application's receive buffer, etc. After this processing is complete, the SMC-R layer will also update its local consumer cursor to match the producer cursor (i.e., indicating that all data has been consumed). Note that an update of the consumer cursor to the peer is not needed at this time, as the window size is unconstrained (> 1/2 of the receive buffer size). The application then performs a send() for 500 bytes to Host A. The SMC-R layer will copy the data into a kernel buffer and then schedule an RDMA write into the partner's RMBE receive buffer. Note that this RDMA write operation includes no immediate data or notification to Host A.
3. ホストBは、前のCDCメッセージの受信を通知されると、RMBEアラートトークンに関連付けられたRMBEを特定し、通常の受信側処理を実行し、中断されたアプリケーションの読み取りスレッドをウェイクアップし、データをアプリケーションの受信バッファーにコピーします。この処理が完了すると、SMC-Rレイヤーは、プロデューサーカーソルと一致するようにローカルコンシューマーカーソルも更新します（つまり、すべてのデータが消費されたことを示します）。ウィンドウサイズが制約されていない（>受信バッファーサイズの1/2を超える）ため、現時点ではピアへのコンシューマーカーソルの更新は必要ありません。次に、アプリケーションはホストAに対して500バイトのsend()を実行します。SMC-Rレイヤーはデータをカーネルバッファーにコピーしてから、パートナーのRMBE受信バッファーへのRDMA書き込みをスケジュールします。このRDMA書き込み操作には、即時データやホストAへの通知は含まれないことに注意してください。
4. Host B sends a CDC message to update the partner's RMBE control information with the latest producer cursor (set to 503 and not shown in the diagram above) and to also inform the peer that the consumer cursor value is now 1004. It also updates the local current consumer cursor and the last sent consumer cursor to 1004. This CDC message includes notification, since we are updating our producer cursor; this requires attention by the peer host.
4. ホストBはCDCメッセージを送信して、パートナーのRMBE制御情報を最新のプロデューサーカーソル（503に設定され、上記の図には表示されていません）で更新し、コンシューマーカーソルの値が1004であることをピアに通知します。また、ローカル現在のコンシューマーカーソルと1004に最後に送信されたコンシューマーカーソル。プロデューサーカーソルを更新しているため、このCDCメッセージには通知が含まれます。これには、ピアホストによる注意が必要です。
SMC Host A SMC Host B
RMBE A Info RMBE B Info
(Consumer Cursors) (Producer Cursors)
Cursor Wrap Seq# Time Time Cursor Wrap Seq# Flags
4 0 0 0 4 0 0
4 0 1 ---------------> 1 4 0 0
RDMA-WR Data
(4:3003)
4 0 2 ...............> 2 3004 0 0
CDC Message
4 0 3 3 3004 0 0
4 0 4 ---------------> 4 3004 0 0
RDMA-WR Data
(3004:7003)
4 0 5 ................> 5 7004 0 0
CDC Message
7004 0 6 <................ 6 7004 0 0
CDC Message
Figure 18: Scenario 3: Send Flow, Window Size Constrained
図18：シナリオ3：送信フロー、ウィンドウサイズの制限
Scenario assumptions:
シナリオの前提：
o New SMC-R connection; no data has been sent on this connection.
o 新しいSMC-R接続。この接続でデータが送信されていません。
o Host A: Application issues send for 3000 bytes to Host B and then another send for 4000 bytes.
o ホストA：アプリケーションはホストBに3000バイトの送信を発行し、次に4000バイトの送信を発行します。
o Host B: RMBE receive buffer size is 10,000. Application has already issued a recv for 10,000 bytes.
o ホストB：RMBE受信バッファーサイズは10,000です。アプリケーションはすでに10,000バイトのrecvを発行しています。
Flow description:
フローの説明：
1. The application issues a send() for 3000 bytes; the SMC-R layer copies data into a kernel send buffer. It then schedules an RDMA write operation to move the data into the peer's RMBE receive buffer, at relative position 4-3003. Note that no immediate data or alert (i.e., interrupt) is provided to Host B for this RDMA operation.
1. アプリケーションは3000バイトのsend()を発行します。 SMC-Rレイヤーは、データをカーネル送信バッファーにコピーします。次に、RDMA書き込み操作をスケジュールして、相対位置4-3003にあるピアのRMBE受信バッファーにデータを移動します。このRDMA操作では、ホストBに即時のデータまたはアラート（つまり、割り込み）が提供されないことに注意してください。
2. Host A sends a CDC message to update its producer cursor to byte 3003. This CDC message will deliver an interrupt to Host B. At this point, the SMC-R layer can return control back to the application.
2. ホストAはCDCメッセージを送信して、プロデューサーカーソルをバイト3003に更新します。このCDCメッセージは、ホストBに割り込みを配信します。この時点で、SMC-Rレイヤーは制御をアプリケーションに戻すことができます。
3. Host B, once notified of the receipt of the previous CDC message, locates the RMBE associated with the RMBE alert token and proceeds to perform normal receive-side processing, waking up the suspended application read thread, copying the data into the application's receive buffer, etc. After this processing is complete, the SMC-R layer will also update its local consumer cursor to match the producer cursor (i.e., indicating that all data has been consumed). It will not, however, update the partner with this information, as the window size is not constrained (10,000 - 3000 = 7000 bytes of available space). The application on Host B also issues a new recv() for 10,000 bytes.
3. ホストBは、前のCDCメッセージの受信を通知されると、RMBEアラートトークンに関連付けられたRMBEを特定し、通常の受信側処理を実行し、中断されたアプリケーションの読み取りスレッドをウェイクアップし、データをアプリケーションの受信バッファーにコピーします。この処理が完了すると、SMC-Rレイヤーは、プロデューサーカーソルと一致するようにローカルコンシューマーカーソルも更新します（つまり、すべてのデータが消費されたことを示します）。ただし、ウィンドウサイズが制限されていないため（10,000-3000 = 7000バイトの使用可能なスペース）、パートナーはこの情報で更新されません。ホストBのアプリケーションも、10,000バイトの新しいrecv()を発行します。
4. On Host A, the application issues a send() for 4000 bytes. The SMC-R layer copies the data into a kernel buffer and schedules an async RDMA write into the peer's RMBE receive buffer at relative position 3003-7004. Note that no alert is provided to Host B for this flow.
4. ホストAで、アプリケーションは4000バイトのsend()を発行します。 SMC-Rレイヤーは、データをカーネルバッファーにコピーし、非同期RDMA書き込みをピアのRMBE受信バッファーの相対位置3003-7004にスケジュールします。このフローでは、ホストBにアラートが提供されないことに注意してください。
5. Host A sends a CDC message to update the producer cursor to byte 7004. This CDC message will deliver an interrupt to Host B. At this point, the SMC-R layer can return control back to the application.
5. ホストAはCDCメッセージを送信して、プロデューサーカーソルをバイト7004に更新します。このCDCメッセージは、ホストBに割り込みを配信します。この時点で、SMC-Rレイヤーは制御をアプリケーションに戻すことができます。
6. Host B, once notified of the receipt of the previous CDC message, locates the RMBE associated with the RMBE alert token and proceeds to perform normal receive-side processing, waking up the suspended application read thread, copying the data into the application's receive buffer, etc. After this processing is complete, the SMC-R layer will also update its local consumer cursor to match the producer cursor (i.e., indicating that all data has been consumed). It will then determine whether or not it needs to update the consumer cursor to the peer. The available window size is now 3000 (10,000 - (producer cursor - last sent consumer cursor)), which is < 1/2 of the receive buffer size (10,000/2 = 5000), and the advance of the window size is > 10% of the window size (1000). Therefore, a CDC message is issued to update the consumer cursor to Peer A.
6. ホストBは、前のCDCメッセージの受信を通知されると、RMBEアラートトークンに関連付けられたRMBEを特定し、通常の受信側処理を実行し、中断されたアプリケーションの読み取りスレッドをウェイクアップし、データをアプリケーションの受信バッファーにコピーします。この処理が完了すると、SMC-Rレイヤーは、プロデューサーカーソルと一致するようにローカルコンシューマーカーソルも更新します（つまり、すべてのデータが消費されたことを示します）。次に、ピアへのコンシューマカーソルを更新する必要があるかどうかを判断します。現在、使用可能なウィンドウサイズは3000（10,000-（プロデューサーカーソル-最後に送信されたコンシューマーカーソル））であり、これは受信バッファーサイズの1/2未満（10,000 / 2 = 5000）であり、ウィンドウサイズの拡張は> 10です。ウィンドウサイズの割合（1000）。したがって、CDCメッセージが発行され、コンシューマーカーソルがピアAに更新されます。
SMC Host A SMC Host B
RMBE A Info RMBE B Info
(Consumer Cursors) (Producer Cursors)
Cursor Wrap Seq# Time Time Cursor Wrap Seq# Flags
1004 1 0 0 1004 1 0
1004 1 1 ---------------> 1 1004 1 0
RDMA-WR Data
(1004:9999)
1004 1 2 ---------------> 2 1004 1 0
RDMA-WR Data
(4:1003)
1004 1 3 ...............> 3 1004 2 Wrt
CDC Message Blk
1004 2 4 <............... 4 1004 2 Wrt
CDC Message Blk
1004 2 5 ---------------> 5 1004 2 Wrt
RDMA-WR Data Blk
(1004:9999)
1004 2 6 ---------------> 6 1004 2 Wrt
RDMA-WR Data Blk
(4:1003)
1004 2 7 ...............> 7 1004 3 Wrt
CDC Message Blk
1004 3 8 <............... 8 1004 3 Wrt
CDC Message Blk
Figure 19: Scenario 4: Large Send, Flow Control, Full Window Size Writes
図19：シナリオ4：大規模な送信、フロー制御、フルウィンドウサイズの書き込み
Scenario assumptions:
シナリオの前提：
o Kernel implementation.
o カーネルの実装。
o Existing SMC-R connection, Host B's receive window size is fully open (peer consumer cursor = peer producer cursor).
o 既存のSMC-R接続、ホストBの受信ウィンドウサイズは完全に開いています（ピアコンシューマーカーソル=ピアプロデューサーカーソル）。
o Host A: Application issues send for 20,000 bytes to Host B.
o ホストA：アプリケーションの問題は、20,000バイトをホストBに送信します。
o Host B: RMBE receive buffer size is 10,000; application has issued a recv for 10,000 bytes.
o ホストB：RMBE受信バッファーサイズは10,000です。アプリケーションが10,000バイトのrecvを発行しました。
Flow description:
フローの説明：
1. The application issues a send() for 20,000 bytes; the SMC-R layer copies data into a kernel send buffer (assumes that send buffer space of 20,000 is available for this connection). It then schedules an RDMA write operation to move the data into the peer's RMBE receive buffer, at relative position 1004-9999. Note that no immediate data or alert (i.e., interrupt) is provided to Host B for this RDMA operation.
1. アプリケーションは20,000バイトのsend()を発行します。 SMC-Rレイヤーは、カーネル送信バッファーにデータをコピーします（20,000の送信バッファースペースがこの接続で利用可能であると想定しています）。次に、RDMA書き込み操作をスケジュールして、データを相対位置1004〜9999のピアのRMBE受信バッファーに移動します。このRDMA操作では、ホストBに即時のデータまたはアラート（つまり、割り込み）が提供されないことに注意してください。
2. Host A then schedules an RDMA write operation to fill the remaining 1000 bytes of available space in the peer's RMBE receive buffer, at relative position 4-1003. Note that no immediate data or alert (i.e., interrupt) is provided to Host B for this RDMA operation. Also note that an implementation of SMC-R may optimize this processing by combining steps 1 and 2 into a single RDMA write operation (with two different data sources).
2. 次に、ホストAはRDMA書き込み操作をスケジュールして、ピアのRMBE受信バッファー内の残りの1000バイトの使用可能なスペースを相対位置4-1003で埋めます。このRDMA操作では、ホストBに即時のデータまたはアラート（つまり、割り込み）が提供されないことに注意してください。また、SMC-Rの実装では、ステップ1と2を1つのRDMA書き込み操作（2つの異なるデータソースを使用）に組み合わせることにより、この処理を最適化する場合があります。
3. Host A sends a CDC message to update the producer cursor to byte 1004. Since the entire receive buffer space is filled, the producer writer blocked flag (the "Wrt Blk" indicator (flag) in Figure 19) is set and the producer cursor wrap sequence number (the producer "Wrap Seq#" in Figure 19) is incremented. This CDC message will deliver an interrupt to Host B. At this point, the SMC-R layer can return control back to the application.
3. ホストAがCDCメッセージを送信して、プロデューサーカーソルをバイト1004に更新します。受信バッファースペース全体がいっぱいになるため、プロデューサーライターのブロックフラグ（図19の「Wrt Blk」インジケーター（フラグ））が設定され、プロデューサーカーソルが折り返されます。シーケンス番号（図19のプロデューサー「Wrap Seq＃」）が増加します。このCDCメッセージは、ホストBに割り込みを配信します。この時点で、SMC-R層はアプリケーションに制御を戻すことができます。
4. Host B, once notified of the receipt of the previous CDC message, locates the RMBE associated with the RMBE alert token and proceeds to perform normal receive-side processing, waking up the suspended application read thread, copying the data into the application's receive buffer, etc. In this scenario, Host B notices that the producer cursor has not been advanced (same value as the consumer cursor); however, it notices that the producer cursor wrap sequence number is different from its local value (1), indicating that a full window of new data is available. All of the data in the receive buffer can be processed, with the first segment (1004-9999) followed by the second segment (4-1003). Because the producer writer blocked indicator was set, Host B schedules a CDC message to update its latest information to the peer: consumer cursor (1004), consumer cursor wrap sequence number (the current value of 2 is used).
4.ホストBは、前のCDCメッセージの受信を通知されると、RMBEアラートトークンに関連付けられたRMBEを特定し、通常の受信側処理の実行に進み、中断されたアプリケーションの読み取りスレッドを起動し、データをアプリケーションの受信にコピーします。このシナリオでは、ホストBはプロデューサーカーソルが進んでいない（コンシューマーカーソルと同じ値）ことに気づきます。ただし、プロデューサーカーソルのラップシーケンス番号がローカル値（1）と異なることに気づき、新しいデータのウィンドウ全体が利用可能であることを示します。最初のセグメント（1004〜9999）に続いて2番目のセグメント（4-1003）を使用して、受信バッファー内のすべてのデータを処理できます。プロデューサーライターのブロックインジケーターが設定されたため、ホストBはCDCメッセージをスケジュールして、最新の情報をピアに更新します。コンシューマーカーソル（1004）、コンシューマーカーソルラップシーケンス番号（現在の値2が使用されます）。
5. Host A, upon receipt of the CDC message, locates the TCP connection associated with the alert token and, upon examining the control information provided, notices that Host B has consumed all of the data (based on the consumer cursor and the consumer cursor wrap sequence number) and initiates the next RDMA write to fill the receive buffer at offset 1003-9999.
5. ホストAは、CDCメッセージを受信すると、アラートトークンに関連付けられたTCP接続を見つけ、提供された制御情報を調べると、ホストBがすべてのデータを消費したことを通知します（コンシューマカーソルとコンシューマカーソルのラップシーケンスに基づく）。番号）、次のRDMA書き込みを開始し、オフセット1003〜9999で受信バッファーを埋めます。
6. Host A then moves the next 1000 bytes into the beginning of the receive buffer (4-1003) by scheduling an RDMA write operation. Note that at this point there are still 8 bytes remaining to be written.
6. ホストAは、RDMA書き込み操作をスケジュールすることにより、次の1000バイトを受信バッファーの先頭（4-1003）に移動します。この時点で、まだ8バイトの書き込みが残っていることに注意してください。
7. Host A then sends a CDC message to set the producer writer blocked indicator and to increment the producer cursor wrap sequence number (3).
7. 次に、ホストAはCDCメッセージを送信して、プロデューサーライターのブロックインジケーターを設定し、プロデューサーカーソルのラップシーケンス番号をインクリメントします（3）。
8. Host B, upon notification, completes the same processing as step 4 above, including sending a CDC message to update the peer to indicate that all data has been consumed. At this point, Host A can write the final 8 bytes to Host B's RMBE into positions 1004-1011 (not shown).
8. ホストBは、通知を受けると、CDCメッセージを送信してピアを更新し、すべてのデータが消費されたことを示すなど、上記の手順4と同じ処理を完了します。この時点で、ホストAは最後の8バイトをホストBのRMBEの位置1004〜1011（図示せず）に書き込むことができます。
SMC Host A SMC Host B
RMBE A Info RMBE B Info
(Consumer Cursors) (Producer Cursors)
Cursor Wrap Seq# Time Time Cursor Wrap Seq# Flag
1000 1 0 0 1000 1 0
1000 1 1 ---------------> 1 1000 1 0
RDMA-WR Data
(1000:1499)
1000 1 2 ...............> 2 1500 1 UrgP
CDC Message UrgA
1500 1 3 <............... 3 1500 1 UrgP
CDC Message UrgA
1500 1 4 ---------------> 4 1500 1 UrgP
RDMA-WR Data UrgA
(1500:2499)
1500 1 5 ...............> 5 2500 1 0
CDC Message
Figure 20: Scenario 5: Send Flow, Urgent Data, Window Size Open
図20：シナリオ5：送信フロー、緊急データ、開いているウィンドウサイズ
Scenario assumptions:
シナリオの前提：
o Kernel implementation.
o カーネルの実装。
o Existing SMC-R connection; window size open (unconstrained); all data has been consumed by receiver.
o 既存のSMC-R接続。開いているウィンドウサイズ（制約なし）;すべてのデータは受信側で消費されています。
o Host A: Application issues send for 500 bytes with urgent data indicator (out of band) to Host B, then sends 1000 bytes of normal data.
o ホストA：アプリケーションは500バイトの緊急データインジケーター（帯域外）を送信してホストBに送信し、次に1000バイトの通常のデータを送信します。
o Host B: RMBE receive buffer size is 10,000; application has issued a recv for 10,000 bytes and is also monitoring the socket for urgent data.
o ホストB：RMBE受信バッファーサイズは10,000です。アプリケーションは10,000バイトのrecvを発行し、緊急データのソケットも監視しています。
Flow description:
フローの説明：
1. The application issues a send() for 500 bytes of urgent data; the SMC-R layer copies data into a kernel send buffer. It then schedules an RDMA write operation to move the data into the peer's RMBE receive buffer, at relative position 1000-1499. Note that no immediate data or alert (i.e., interrupt) is provided to Host B for this RDMA operation.
1. アプリケーションは、500バイトの緊急データに対してsend()を発行します。 SMC-Rレイヤーは、データをカーネル送信バッファーにコピーします。次に、RDMA書き込み操作をスケジュールして、データをピアのRMBE受信バッファーの相対位置1000〜1499に移動します。このRDMA操作では、ホストBに即時のデータまたはアラート（つまり、割り込み）が提供されないことに注意してください。
2. Host A sends a CDC message to update its producer cursor to byte 1500 and to turn on the producer Urgent Data Pending (UrgP) and Urgent Data Present (UrgA) flags. This CDC message will deliver an interrupt to Host B. At this point, the SMC-R layer can return control back to the application.
2. ホストAはCDCメッセージを送信して、プロデューサーカーソルをバイト1500に更新し、プロデューサーの緊急データ保留（UrgP）フラグと緊急データ存在（UrgA）フラグをオンにします。このCDCメッセージは、ホストBに割り込みを配信します。この時点で、SMC-R層はアプリケーションに制御を戻すことができます。
3. Host B, once notified of the receipt of the previous CDC message, locates the RMBE associated with the RMBE alert token, notices that the Urgent Data Pending flag is on, and proceeds with out-of-band socket API notification -- for example, satisfying any outstanding select() or poll() requests on the socket by indicating that urgent data is pending (i.e., by setting the exception bit on). The urgent data present indicator allows Host B to also determine the position of the urgent data (the producer cursor points 1 byte beyond the last byte of urgent data). Host B can then perform normal receive-side processing (including specific urgent data processing), copying the data into the application's receive buffer, etc. Host B then sends a CDC message to update the partner's RMBE control area with its latest consumer cursor (1500). Note that this CDC message must occur, regardless of the current local window size that is available. The partner host (Host A) cannot initiate any additional RDMA writes until it receives acknowledgment that the urgent data has been processed (or at least processed/remembered at the SMC-R layer).
3. ホストBは、前のCDCメッセージの受信を通知されると、RMBEアラートトークンに関連付けられたRMBEを見つけ、緊急データ保留フラグがオンになっていることに気づき、帯域外ソケットAPI通知を続行します。たとえば、緊急データが保留中であることを示すことにより（つまり、例外ビットをオンに設定することにより）、ソケット上の未処理のselect()またはpoll()要求を満たすこと。緊急データ存在インジケーターにより、ホストBは緊急データの位置を決定することもできます（プロデューサーカーソルは緊急データの最後のバイトより1バイト先を指します）。次に、ホストBは通常の受信側処理（特定の緊急データ処理を含む）を実行し、データをアプリケーションの受信バッファーにコピーするなどします。次に、ホストBはCDCメッセージを送信して、パートナーのRMBE制御領域を最新のコンシューマーカーソルで更新します（1500 ）。このCDCメッセージは、使用可能な現在のローカルウィンドウサイズに関係なく発生することに注意してください。パートナーホスト（ホストA）は、緊急データが処理された（または少なくともSMC-Rレイヤーで処理/記憶された）ことの確認を受け取るまで、追加のRDMA書き込みを開始できません。
4. Upon receipt of the message, Host A wakes up, sees that the peer consumed all data up to and including the last byte of urgent data, and now resumes sending any pending data. In this case, the application had previously issued a send for 1000 bytes of normal data, which would have been copied in the send buffer, and control would have been returned to the application. Host A now initiates an RDMA write to move that data to the peer's receive buffer at position 1500-2499.
4. メッセージを受信すると、ホストAはウェイクアップし、ピアが緊急データの最後のバイトまでのすべてのデータを消費したことを確認し、保留中のデータの送信を再開します。この場合、アプリケーションは以前に1000バイトの通常データの送信を発行していました。これは送信バッファーにコピーされ、制御がアプリケーションに返されます。ホストAはRDMA書き込みを開始して、そのデータを1500〜2499の位置にあるピアの受信バッファーに移動します。
5. Host A then sends a CDC message to update its producer cursor value (2500) and to turn off the Urgent Data Pending and Urgent Data Present flags. Host B wakes up, processes the new data (resumes application, copies data into the application receive buffer), and then proceeds to update the local current consumer cursor (2500). Given that the window size is unconstrained, there is no need for a consumer cursor update in the peer's RMBE.
5. 次に、ホストAはCDCメッセージを送信して、プロデューサーカーソルの値（2500）を更新し、緊急データ保留フラグと緊急データ存在フラグをオフにします。ホストBがウェイクアップし、新しいデータを処理して（アプリケーションを再開し、データをアプリケーションの受信バッファーにコピーし）、ローカルの現在のコンシューマーカーソルの更新に進みます（2500）。ウィンドウサイズに制約がない場合、ピアのRMBEでコンシューマカーソルを更新する必要はありません。
SMC Host A SMC Host B RMBE A Info RMBE B Info (Consumer Cursors) (Producer Cursors) Cursor Wrap Seq# Time Time Cursor Wrap Seq# Flag 1000 1 0 0 1000 2 Wrt Blk
SMCホストA SMCホストB RMBE A情報RMBE B情報（コンシューマーカーソル）（プロデューサーカーソル）カーソルラップSeq＃時間タイムカーソルラップSeq＃フラグ1000 1 0 0 1000 2 Wrt Blk
1000 1 1 ...............> 1 1000 2 Wrt
CDC Message Blk
UrgP
1000 2 2 <............... 2 1000 2 Wrt
CDC Message Blk
UrgP
1000 2 3 ---------------> 3 1000 2 Wrt
RDMA-WR Data Blk
(1000:1499) UrgP
1000 2 4 ...............> 4 1500 2 UrgP
CDC Message UrgA
1500 2 5 <............... 5 1500 2 UrgP
CDC Message UrgA
1500 2 6 ---------------> 6 1500 2 UrgP
RDMA-WR Data UrgA
(1500:2499)
1000 2 7 ...............> 7 2500 2 0
CDC Message
Figure 21: Scenario 6: Send Flow, Urgent Data, Window Size Closed
図21：シナリオ6：送信フロー、緊急データ、閉じたウィンドウサイズ
Scenario assumptions:
シナリオの前提：
o Kernel implementation.
o カーネルの実装。
o Existing SMC-R connection; window size closed; writer is blocked.
o 既存のSMC-R接続。閉じたウィンドウサイズ。ライターがブロックされています。
o Host A: Application issues send for 500 bytes with urgent data indicator (out of band) to Host B, then sends 1000 bytes of normal data.
o ホストA：アプリケーションは500バイトの緊急データインジケーター（帯域外）を送信してホストBに送信し、次に1000バイトの通常のデータを送信します。
o Host B: RMBE receive buffer size is 10,000; application has no outstanding recv() (for normal data) and is monitoring the socket for urgent data.
o ホストB：RMBE受信バッファーサイズは10,000です。アプリケーションには未処理のrecv()（通常のデータ用）がなく、ソケットに緊急データを監視しています。
Flow description:
フローの説明：
1. The application issues a send() for 500 bytes of urgent data; the SMC-R layer copies data into a kernel send buffer (if available). Since the writer is blocked (window size closed), it cannot send the data immediately. It then sends a CDC message to notify the peer of the Urgent Data Pending (UrgP) indicator (the writer blocked indicator remains on as well). This serves as a signal to Host B that urgent data is pending in the stream. Control is also returned to the application at this point.
1. アプリケーションは、500バイトの緊急データに対してsend()を発行します。 SMC-Rレイヤーは、カーネル送信バッファー（使用可能な場合）にデータをコピーします。ライターはブロックされている（ウィンドウサイズが閉じている）ため、データをすぐに送信できません。次に、CDCメッセージを送信して、緊急データ保留（UrgP）インジケーターをピアに通知します（ライターブロックインジケーターもオンのままです）。これは、緊急データがストリームで保留中であるというホストBへの信号として機能します。この時点で、制御もアプリケーションに戻ります。
2. Host B, once notified of the receipt of the previous CDC message, locates the RMBE associated with the RMBE alert token, notices that the Urgent Data Pending flag is on, and proceeds with out-of-band socket API notification -- for example, satisfying any outstanding select() or poll() requests on the socket by indicating that urgent data is pending (i.e., by setting the exception bit on). At this point, it is expected that the application will enter urgent data mode processing, expeditiously processing all normal data (by issuing recv API calls) so that it can get to the urgent data byte. Whether the application has this urgent mode processing or not, at some point, the application will consume some or all of the pending data in the receive buffer. When this occurs, Host B will also send a CDC message to update its consumer cursor and consumer cursor wrap sequence number to the peer. In the example above, a full window's worth of data was consumed.
2. ホストBは、前のCDCメッセージの受信を通知されると、RMBEアラートトークンに関連付けられたRMBEを見つけ、緊急データ保留フラグがオンになっていることに気づき、帯域外ソケットAPI通知を続行します。たとえば、緊急データが保留中であることを示すことにより（つまり、例外ビットをオンに設定することにより）、ソケット上の未処理のselect()またはpoll()要求を満たすこと。この時点で、アプリケーションは緊急データモードの処理に入り、緊急データバイトに到達できるように（recv API呼び出しを発行することにより）すべての通常のデータを迅速に処理することが予想されます。アプリケーションにこの緊急モード処理があるかどうかに関係なく、ある時点で、アプリケーションは受信バッファー内の保留中のデータの一部またはすべてを消費します。これが発生すると、ホストBはCDCメッセージも送信して、そのコンシューマーカーソルとコンシューマーカーソルラップシーケンス番号をピアに更新します。上記の例では、ウィンドウ全体のデータが消費されました。
3. Host A, once awakened by the message, will notice that the window size is now open on this connection (based on the consumer cursor and the consumer cursor wrap sequence number, which now matches the producer cursor wrap sequence number) and resume sending of the urgent data segment by scheduling an RDMA write into relative position 1000-1499.
3. ホストAは、メッセージによって起動されると、この接続でウィンドウサイズが開いていることに気づき（コンシューマーカーソルとコンシューマーカーソルのラップシーケンス番号に基づいており、プロデューサーカーソルのラップシーケンス番号と一致しています）、送信を再開します。相対位置1000〜1499へのRDMA書き込みをスケジュールすることによる緊急データセグメント。
4. Host A then sends a CDC message to advance its producer cursor (1500) and to also notify Host B of the Urgent Data Present (UrgA) indicator (and turn off the writer blocked indicator). This signals to Host B that the urgent data is now in the local receive buffer and that the producer cursor points to the last byte of urgent data.
4. 次に、ホストAはCDCメッセージを送信して、プロデューサーカーソル（1500）を進め、緊急データ存在（UrgA）インジケーターをホストBに通知します（そしてライターブロックインジケーターをオフにします）。これは、緊急データがローカル受信バッファーにあること、およびプロデューサーカーソルが緊急データの最後のバイトを指していることをホストBに通知します。
5. Host B wakes up, processes the urgent data, and, once the urgent data is consumed, sends a CDC message to update its consumer cursor (1500).
5. ホストBがウェイクアップして緊急データを処理し、緊急データが消費されると、CDCメッセージを送信してそのコンシューマーカーソルを更新します（1500）。
6. Host A wakes up, sees that Host B has consumed the sequence number associated with the urgent data, and then initiates the next RDMA write operation to move the 1000 bytes associated with the next send() of normal data into the peer's receive buffer at position 1500-2499. Note that the send API would have likely completed earlier in the process by copying the 1000 bytes into a send buffer and returning back to the application, even though we could not send any new data until the urgent data was processed and acknowledged by Host B.
6. ホストAがウェイクアップし、ホストBが緊急データに関連付けられたシーケンス番号を消費したことを確認し、次のRDMA書き込み操作を開始して、通常のデータの次のsend()に関連付けられた1000バイトをピアの受信バッファーの位置に移動します1500〜2499。ホストBが緊急のデータを処理して確認するまで新しいデータを送信できなかったとしても、送信APIはプロセスの早い段階で1000バイトを送信バッファーにコピーしてアプリケーションに戻ることで完了した可能性が高いことに注意してください。
7. Host A sends a CDC message to advance its producer cursor to 2500 and to reset the Urgent Data Pending and Urgent Data Present flags. Host B wakes up and processes the inbound data.
7. ホストAはCDCメッセージを送信して、プロデューサーカーソルを2500に進め、緊急データ保留フラグと緊急データ存在フラグをリセットします。ホストBがウェイクアップし、インバウンドデータを処理します。
Just as SMC-R connections are established using a combination of TCP connection establishment flows and SMC-R protocol flows, the termination of SMC-R connections also uses a similar combination of SMC-R protocol termination flows and normal TCP connection termination flows. The following sections describe the SMC-R protocol normal and abnormal connection termination flows.
TCP接続確立フローとSMC-Rプロトコルフローの組み合わせを使用してSMC-R接続が確立されるのと同様に、SMC-R接続の終了も、SMC-Rプロトコル終了フローと通常のTCP接続終了フローの同様の組み合わせを使用します。以下のセクションでは、SMC-Rプロトコルの通常および異常な接続終了フローについて説明します。
Normal SMC-R connection flows are triggered via the normal stream socket API semantics, namely by the application issuing a close() or shutdown() API. Most applications, after consuming all incoming data and after sending any outbound data, will then issue a close() API to indicate that they are done both sending and receiving data. Some applications, typically a small percentage, make use of the shutdown() API that allows them to indicate that the application is done sending data, receiving data, or both sending and receiving data. The main use of this API is scenarios where a TCP application wants to alert its partner endpoint that it is done sending data but is still receiving data on its socket (shutdown for write). Issuing shutdown() for both sending and receiving data is really no different than issuing a close() and can therefore be treated in a similar fashion. Shutdown for read is typically not a very useful operation and in normal circumstances does not trigger any network flows to notify the partner TCP endpoint of this operation.
通常のSMC-R接続フローは、通常のストリームソケットAPIセマンティクスによって、つまり、アプリケーションがclose()またはshutdown()APIを発行することによってトリガーされます。ほとんどのアプリケーションは、すべての受信データを消費し、送信データを送信した後、データの送信と受信の両方が完了したことを示すclose()APIを発行します。一部のアプリケーション（通常はわずかな割合）は、アプリケーションがデータの送信、データの受信、またはデータの送信と受信の両方を完了したことを示すことができるshutdown()APIを使用します。このAPIの主な用途は、TCPアプリケーションがパートナーエンドポイントにデータの送信が完了したが、ソケットでデータを受信していることを警告するシナリオです（書き込みのシャットダウン）。データの送信と受信の両方に対してshutdown()を発行することは、close()を発行することとまったく同じであり、したがって、同様の方法で処理できます。読み取りのためのシャットダウンは、通常、あまり有用な操作ではなく、通常の状況では、ネットワークフローをトリガーして、この操作をパートナーTCPエンドポイントに通知しません。
These same trigger points will be used by the SMC-R layer to initiate SMC-R connection termination flows. The main design point for SMC-R normal connection flows is to use the SMC-R protocol to first shut down the SMC-R connection and free up any SMC-R RDMA resources, and then allow the normal TCP connection termination protocol (i.e., FIN processing) to drive cleanup of the TCP connection. This design point is very important in ensuring that RDMA resources such as the RMBEs are only freed and reused when both SMC-R endpoints are completely done with their RDMA write operations to the partner's RMBE.
これらの同じトリガーポイントは、SMC-RレイヤーでSMC-R接続終了フローを開始するために使用されます。 SMC-Rの通常の接続フローの主な設計ポイントは、SMC-Rプロトコルを使用して最初にSMC-R接続をシャットダウンし、SMC-R RDMAリソースを解放してから、通常のTCP接続終了プロトコル（つまり、 FIN処理）を使用して、TCP接続のクリーンアップを実行します。この設計ポイントは、RMBEなどのRDMAリソースが解放され、再利用されるのは、両方のSMC-RエンドポイントがパートナーのRMBEへのRDMA書き込み操作で完全に完了した場合にのみ重要です。
1
+-----------------+
|-------------->| CLOSED |<-------------|
3D | | | | 4D
| +-----------------+ |
| | |
| 2 | |
| V |
+----------------+ +-----------------+ +----------------+
|AppFinCloseWait | | ACTIVE | |PeerFinCloseWait|
| | | | | |
+----------------+ +-----------------+ +----------------+
| | | |
| Active Close | 3A | 4A | Passive Close |
| V | V |
| +--------------+ | +-------------+ |
|--<----|PeerCloseWait1| | |AppCloseWait1|--->----|
3C | | | | | | | 4C
| +--------------+ | +-------------+ |
| | | | |
| | 3B | 4B | |
| V | V |
| +--------------+ | +-------------+ |
|--<----|PeerCloseWait2| | |AppCloseWait2|--->----|
| | | | |
+--------------+ | +-------------+
|
|
Figure 22: SMC-R Connection States
図22：SMC-R接続状態
Figure 22 describes the states that an SMC-R connection typically goes through. Note that there are variations to these states that can occur when an SMC-R connection is abnormally terminated, similar in a way to when a TCP connection is reset. The following are the high-level state transitions for an SMC-R connection:
図22は、SMC-R接続が通常通過する状態を示しています。 TCP接続がリセットされたときと同様に、SMC-R接続が異常終了したときに発生する可能性のあるこれらの状態のバリエーションがあることに注意してください。以下は、SMC-R接続の高レベルの状態遷移です。
1. An SMC-R connection begins in the Closed state. This state is meant to reflect an RMBE that is not currently in use (was previously in use but no longer is, or was never allocated).
1. SMC-R接続は、クローズ状態で始まります。この状態は、現在使用されていない（以前は使用されていたが使用されていない、または割り当てられていない）RMBEを反映することを目的としています。
2. An SMC-R connection progresses to the Active state once the SMC-R Rendezvous processing has successfully completed, RMB element indices have been exchanged, and SMC-R links have been activated. In this state, the TCP connection is fully established, rendezvous processing has been completed, and SMC-R peers can begin the exchange of data via RDMA.
2. SMC-R Rendezvous処理が正常に完了し、RMB要素のインデックスが交換され、SMC-Rリンクがアクティブ化されると、SMC-R接続はアクティブ状態に進みます。この状態では、TCP接続が完全に確立され、ランデブー処理が完了しており、SMC-RピアはRDMAを介したデータ交換を開始できます。
3. Active close processing (on the SMC-R peer that is initiating the connection termination).
3. アクティブなクローズ処理（接続終了を開始しているSMC-Rピア上）。
A. When an application on one of the SMC-R connection peers issues a close(), a shutdown() for write, or a shutdown() for both read and write, the SMC-R layer on that host will initiate SMC-R connection termination processing. First, if a close() or shutdown(both) is issued, it will check to see that there's no data in the local RMB element that has not been read by the application. If unread data is detected, the SMC-R connection must be abnormally reset; for more details on this, refer to Section 4.8.2 ("Abnormal SMC-R Connection Termination Flows"). If no unread data is pending, it then checks to see whether or not any outstanding data is waiting to be written to the peer, or if any outstanding RDMA writes for this SMC-R connection have not yet completed. If either of these two scenarios is true, an indicator that this connection is in a pending close state is saved in internal data structures representing this SMC-R connection, and control is returned to the application. If all data to be written to the partner has completed, this peer will send a CDC message to notify the peer of either the PeerConnectionClosed indicator (close or shutdown for both was issued) or the PeerDoneWriting indicator. This will provide an interrupt to inform that partner SMC-R peer that the connection is terminating. At this point, the local side of the SMC-R connection transitions in the PeerCloseWait1 state, and control can be returned to the application. If this process could not be completed synchronously (the pending close condition mentioned above), it is completed when all RDMA writes for data and control cursors have been completed.
A. SMC-R接続ピアの1つにあるアプリケーションがclose()、shutdown()を書き込み、またはshutdown()を読み取りと書き込みの両方に発行すると、そのホストのSMC-RレイヤーがSMC- R接続終了処理。まず、close()またはshutdown（both）が発行されると、ローカルRMB要素にアプリケーションによって読み取られていないデータがないことを確認します。未読データが検出された場合、SMC-R接続を異常にリセットする必要があります。詳細については、セクション4.8.2（「異常なSMC-R接続終了フロー」）を参照してください。保留中の未読データがない場合は、未処理のデータがピアへの書き込みを待機しているかどうか、またはこのSMC-R接続の未処理のRDMA書き込みがまだ完了していないかどうかを確認します。これら2つのシナリオのいずれかが当てはまる場合、この接続が保留中のクローズ状態であることを示すインジケーターが、このSMC-R接続を表す内部データ構造に保存され、制御がアプリケーションに返されます。パートナーに書き込まれるすべてのデータが完了すると、このピアはCDCメッセージを送信して、ピアにPeerConnectionClosedインジケーター（両方のクローズまたはシャットダウンが発行された）またはPeerDoneWritingインジケーターを通知します。これにより、接続が終了していることをパートナーSMC-Rピアに通知するための割り込みが提供されます。この時点で、SMC-R接続のローカル側はPeerCloseWait1状態に遷移し、制御をアプリケーションに戻すことができます。このプロセスを同期的に完了できなかった場合（上記の保留中のクローズ条件）、データとコントロールカーソルに対するすべてのRDMA書き込みが完了すると、プロセスは完了します。
B. At some point, the SMC-R peer application (passive close) will consume all incoming data, realize that that partner is done sending data on this connection, and proceed to initiate its own close of the connection once it has completed sending all data from its end. The partner application can initiate this connection termination processing via close() or shutdown() APIs. If the application does so by issuing a shutdown() for write, then the partner SMC-R layer will send a CDC message to notify the peer (the active close side) of the PeerDoneWriting indicator. When the "active close" SMC-R peer wakes up as a result of the previous CDC message, it will notice that the PeerDoneWriting indicator is now on and transition to the PeerCloseWait2 state. This state indicates that the peer is done sending data and may still be reading data. At this point, the "active close" peer will also need to ensure that any outstanding recv() calls for this socket are woken up and remember that no more data is forthcoming on this connection (in case the local connection was shutdown() for write only).
B.ある時点で、SMC-Rピアアプリケーション（パッシブクローズ）はすべての受信データを消費し、そのパートナーがこの接続でデータの送信を完了したことを認識し、すべての送信が完了すると接続の独自のクローズを開始します。その端からのデータ。パートナーアプリケーションは、close()またはshutdown()APIを介してこの接続終了処理を開始できます。アプリケーションが、shutdown()を発行して発行する場合、パートナーSMC-RレイヤーはCDCメッセージを送信して、ピア（アクティブな終了側）にPeerDoneWritingインジケーターを通知します。前のCDCメッセージの結果として「アクティブクローズ」SMC-Rピアが起動すると、PeerDoneWritingインジケーターがオンになり、PeerCloseWait2状態に移行することがわかります。この状態は、ピアがデータの送信を完了し、まだデータを読み取っている可能性があることを示しています。この時点で、「アクティブクローズ」ピアは、このソケットの未処理のrecv()呼び出しが起こされていることを確認し、この接続でこれ以上データが送信されないことを覚えておく必要があります（ローカル接続がshutdown()の場合）書き込みのみ）。
C. This flow is a common transition from 3A or 3B above. When the SMC-R peer (passive close) consumes all data and updates all necessary cursors to the peer, and the application closes its socket (close or shutdown for both), it will send a CDC message to the peer (the active close side) with the PeerConnectionClosed indicator set. At this point, the connection can transition back to the Closed state if the local application has already closed (or issued shutdown for both) the socket. Once in the Closed state, the RMBE can now be safely reused for a new SMC-R connection. When the PeerConnectionClosed indicator is turned on, the SMC-R peer is indicating that it is done updating the partner's RMBE.
C.このフローは、上記の3Aまたは3Bからの一般的な移行です。 SMC-Rピア（パッシブクローズ）がすべてのデータを消費し、ピアへのすべての必要なカーソルを更新し、アプリケーションがソケットをクローズする（クローズまたはシャットダウンの両方）と、CDCメッセージがピア（アクティブクローズサイド）に送信されます。 ）PeerConnectionClosedインジケーターセットを使用します。この時点で、ローカルアプリケーションがすでにソケットを閉じている（または両方に対してシャットダウンを発行している）場合、接続はClosed状態に戻る可能性があります。 Closed状態になると、RMBEは新しいSMC-R接続に安全に再利用できるようになります。 PeerConnectionClosedインジケーターがオンになっている場合、SMC-Rピアは、パートナーのRMBEの更新が完了したことを示しています。
D. Conditional state: If the local application has not yet issued a close() or shutdown(both), we need to wait until the application does so. Once it does, the local host will send a CDC message to notify the peer of the PeerConnectionClosed indicator and then transition to the Closed state.
D.条件付き状態：ローカルアプリケーションがまだclose()またはshutdown（両方）を発行していない場合、アプリケーションが発行するまで待機する必要があります。これが完了すると、ローカルホストはCDCメッセージを送信してピアにPeerConnectionClosedインジケーターを通知し、Closed状態に移行します。
4. Passive close processing (on the SMC-R peer that receives an indication that the partner is closing the connection).
4. パッシブクローズ処理（パートナーが接続をクローズしているという指示を受け取るSMC-Rピア上で）。
A. Upon receipt of a CDC message, the SMC-R layer will detect that the PeerConnectionClosed indicator or PeerDoneWriting indicator is on. If any outstanding recv() calls are pending, they are completed with an indicator that the partner has closed the connection (zero-length data presented to the application). If there is any pending data to be written and PeerConnectionClosed is on, then an SMC-R connection reset must be performed. The connection then enters the AppCloseWait1 state on the passive close side waiting for the local application to initiate its own close processing.
A. SMC-Rレイヤーは、CDCメッセージを受信すると、PeerConnectionClosedインジケーターまたはPeerDoneWritingインジケーターがオンであることを検出します。未解決のrecv()呼び出しが保留中の場合、パートナーが接続を閉じたことを示すインジケーター（アプリケーションに提示される長さがゼロのデータ）で完了します。書き込まれる保留データがあり、PeerConnectionClosedがオンの場合、SMC-R接続リセットを実行する必要があります。次に、接続はパッシブクローズ側でAppCloseWait1状態になり、ローカルアプリケーションが独自のクローズ処理を開始するのを待ちます。
B. If the local application issues a shutdown() for writing, then the SMC-R layer will send a CDC message to notify the partner of the PeerDoneWriting indicator and then transition the local side of the SMC-R connection to the AppCloseWait2 state.
B.ローカルアプリケーションが書き込みのためにshutdown()を発行すると、SMC-R層はCDCメッセージを送信してパートナーにPeerDoneWritingインジケーターを通知し、SMC-R接続のローカル側をAppCloseWait2状態に移行します。
C. When the application issues a close() or shutdown() for both, the local SMC-R peer will send a message informing the peer of the PeerConnectionClosed indicator and transition to the Closed state if the remote peer has also sent the local peer the PeerConnectionClosed indicator. If the peer has not sent the PeerConnectionClosed indicator, we transition into the PeerFinCloseWait state.
C.アプリケーションが両方に対してclose()またはshutdown()を発行すると、ローカルSMC-Rピアは、ピアにPeerConnectionClosedインジケーターを通知するメッセージを送信し、リモートピアもローカルピアを送信した場合はクローズ状態に移行しますPeerConnectionClosedインジケーター。ピアがPeerConnectionClosedインジケーターを送信していない場合、PeerFinCloseWait状態に遷移します。
D. The local SMC-R connection stays in this state until the peer sends the PeerConnectionClosed indicator in a CDC message. When the indicator is sent, we transition to the Closed state and are then free to reuse this RMBE.
D.ローカルSMC-R接続は、ピアがCDCメッセージでPeerConnectionClosedインジケーターを送信するまでこの状態のままです。インジケーターが送信されると、Closed状態に移行し、このRMBEを自由に再利用できます。
Note that each SMC-R peer needs to provide some logic that will prevent being stranded in a termination state indefinitely. For example, if an Active Close SMC-R peer is in a PeerCloseWait (1 or 2) state waiting for the remote SMC-R peer to update its connection termination status, it needs to provide a timer that will prevent it from waiting in that state indefinitely should the remote SMC-R peer not respond to this termination request. This could occur in error scenarios -- for example, if the remote SMC-R peer suffered a failure prior to being able to respond to the termination request or the remote application is not responding to this connection termination request by closing its own socket. This latter scenario is similar to the TCP FINWAIT2 state, which has been known to sometimes cause issues when remote TCP/IP hosts lose track of established connections and neglect to close them. Even though the TCP standards do not mandate a timeout from the TCP FINWAIT2 state, most TCP/IP implementations assign a timeout for this state. A similar timeout will be required for SMC-R connections. When this timeout occurs, the local SMC-R peer performs TCP reset processing for this connection. However, no additional RDMA writes to the partner RMBE can occur at this point (we have already indicated that we are done updating the peer's RMBE). After the TCP connection is reset, the RMBE can be returned to the free pool for reallocation. See Section 4.4.2 for more details.
各SMC-Rピアは、終了状態で無期限に取り残されるのを防ぐいくつかのロジックを提供する必要があることに注意してください。たとえば、Active Close SMC-RピアがPeerCloseWait（1または2）状態であり、リモートSMC-Rピアが接続終了ステータスを更新するのを待機している場合、その中で待機しないようにするタイマーを提供する必要があります。リモートSMC-Rピアがこの終了要求に応答しない場合、無期限に状態を示します。これは、エラーシナリオで発生する可能性があります。たとえば、リモートSMC-Rピアが終了要求に応答する前に障害が発生した場合や、リモートアプリケーションが自身のソケットを閉じることによってこの接続終了要求に応答していない場合などです。この後者のシナリオは、TCP FINWAIT2状態に似ています。これは、リモートTCP / IPホストが確立された接続を追跡できず、それらを閉じることを怠ると問題が発生することがわかっています。 TCP標準はTCP FINWAIT2状態からのタイムアウトを義務付けていませんが、ほとんどのTCP / IP実装はこの状態にタイムアウトを割り当てます。 SMC-R接続にも同様のタイムアウトが必要です。このタイムアウトが発生すると、ローカルSMC-Rピアがこの接続のTCPリセット処理を実行します。ただし、この時点ではパートナーRMBEへの追加のRDMA書き込みは発生しません（ピアのRMBEの更新が完了したことはすでに示しています）。 TCP接続がリセットされた後、RMBEは再割り当てのために空きプールに戻すことができます。詳細については、セクション4.4.2を参照してください。
Also note that it is possible to have two SMC-R endpoints initiate an Active close concurrently. In that scenario, the flows above still apply; however, both endpoints follow the active close path (path 3).
また、2つのSMC-Rエンドポイントでアクティブクローズを同時に開始することもできます。そのシナリオでは、上記のフローが引き続き適用されます。ただし、両方のエンドポイントはアクティブなクローズパス（パス3）に従います。
Abnormal SMC-R connection termination can occur for a variety of reasons, including the following:
SMC-R接続の異常終了は、次のようなさまざまな理由で発生します。
o The TCP connection associated with an SMC-R connection is reset. In TCP, either endpoint can send a RST segment to abort an existing TCP connection when error conditions are detected for the connection or the application overtly requests that the connection be reset.
o SMC-R接続に関連付けられたTCP接続がリセットされます。 TCPでは、どちらかのエンドポイントがRSTセグメントを送信して、接続のエラー状態が検出された場合、またはアプリケーションが接続のリセットを明示的に要求した場合に、既存のTCP接続を中止できます。
o Normal SMC-R connection termination processing has unexpectedly stalled for a given connection. When the stall is detected (connection termination timeout condition), an abnormal SMC-R connection termination flow is initiated.
o 特定の接続で、通常のSMC-R接続終了処理が予期せずに停止しました。ストールが検出されると（接続終了タイムアウト条件）、異常なSMC-R接続終了フローが開始されます。
In these scenarios, it is very important that resources associated with the affected SMC-R connections are properly cleaned up to ensure that there are no orphaned resources and that resources can reliably be reused for new SMC-R connections. Given that SMC-R relies heavily on the RDMA write processing, special care needs to be taken to ensure that an RMBE is no longer being used by an SMC-R peer before logically reassigning that RMBE to a new SMC-R connection.
これらのシナリオでは、影響を受けるSMC-R接続に関連付けられているリソースを適切にクリーンアップして、孤立したリソースがないこと、および新しいSMC-R接続でリソースを確実に再利用できることが非常に重要です。 SMC-RはRDMA書き込み処理に大きく依存しているため、RMBEが新しいSMC-R接続に論理的に再割り当てされる前に、RMBEがSMC-Rピアによって使用されていないことを確認するために特別な注意が必要です。
When an SMC-R peer initiates a TCP connection reset, it also initiates an SMC-R abnormal connection flow at the same time. The SMC-R peers explicitly signal their intent to abnormally terminate an SMC-R connection and await explicit acknowledgment that the peer has received this notification and has also completed abnormal connection termination on its end. Note that TCP connection reset processing can occur in parallel to these flows.
SMC-RピアがTCP接続リセットを開始すると、同時にSMC-R異常接続フローも開始されます。 SMC-Rピアは、SMC-R接続を異常終了する意図を明示的に通知し、ピアがこの通知を受信し、その端で接続異常終了も完了したことを示す明示的な確認応答を待ちます。 TCP接続リセット処理は、これらのフローと並行して発生する可能性があることに注意してください。
+-----------------+
|-------------->| CLOSED |<-------------|
| | | |
| +-----------------+ |
| |
| |
| |
| +-----------------------+ |
| | Any state | |
|1B | (before setting | 2B|
| | PeerConnectionClosed | |
| | indicator in | |
| | peer's RMBE) | |
| +-----------------------+ |
| 1A | | 2A |
| Active Abort | | Passive Abort |
| V V |
| +--------------+ +--------------+ |
|-------|PeerAbortWait | | Process Abort|------|
| | | |
+--------------+ +--------------+
Figure 23: SMC-R Abnormal Connection Termination State Diagram
図23：SMC-Rの異常な接続終了の状態図
Figure 23 above shows the SMC-R abnormal connection termination state diagram:
上の図23は、SMC-Rの異常な接続終了の状態図を示しています。
1. Active abort designates the SMC-R peer that is initiating the TCP RST processing. At the time that the TCP RST is sent, the active abort side must also do the following:
1. アクティブアボートは、TCP RST処理を開始しているSMC-Rピアを指定します。 TCP RSTが送信されるときに、アクティブな打ち切り側は次のことも行う必要があります。
A. Send the PeerConnAbort indicator to the partner in a CDC message, and then transition to the PeerAbortWait state. During this state, it will monitor this SMC-R connection waiting for the peer to send its corresponding PeerConnAbort indicator but will ignore any other activity in this connection (i.e., new incoming data). It will also generate an appropriate error to any socket API calls issued against this socket (e.g., ECONNABORTED, ECONNRESET).
A. PeerConnAbortインジケーターをCDCメッセージでパートナーに送信してから、PeerAbortWait状態に移行します。この状態の間、ピアは対応するPeerConnAbortインジケーターを送信するのを待っているこのSMC-R接続を監視しますが、この接続の他のアクティビティ（つまり、新しい着信データ）を無視します。また、このソケットに対して発行されたすべてのソケットAPI呼び出し（ECONNABORTED、ECONNRESETなど）に対して適切なエラーを生成します。
B. Once the peer sends the PeerConnAbort indicator to the local host, the local host can transition this SMC-R connection to the Closed state and reuse this RMBE. Note that the SMC-R peer that goes into the active abort state must provide some protection against staying in that state indefinitely should the remote SMC-R peer not respond by sending its own PeerConnAbort indicator to the local host. While this should be a rare scenario, it could occur if the remote SMC-R peer (passive abort) suffered a failure right after the local SMC-R peer (active abort) sent the PeerConnAbort indicator. To protect against these types of failures, a timer can be set after entering the PeerAbortWait state, and if that timer pops before the peer has sent its local PeerConnAbort indicator (to the active abort side), this RMBE can be returned to the free pool for possible reallocation. See Section 4.4.2 for more details.
B.ピアがPeerConnAbortインジケーターをローカルホストに送信すると、ローカルホストはこのSMC-R接続をClosed状態に移行し、このRMBEを再利用できます。アクティブな打ち切り状態になるSMC-Rピアは、リモートSMC-Rピアがローカルホストに独自のPeerConnAbortインジケーターを送信して応答しない場合に、その状態がいつまでも続くことを防ぐ必要があります。これはまれなシナリオですが、ローカルSMC-Rピア（アクティブアボート）がPeerConnAbortインジケーターを送信した直後にリモートSMC-Rピア（パッシブアボート）に障害が発生した場合に発生する可能性があります。これらのタイプの障害から保護するために、PeerAbortWait状態に入った後にタイマーを設定でき、ピアがローカルのPeerConnAbortインジケーターを（アクティブなアボート側に）送信する前にそのタイマーがポップした場合、このRMBEをフリープールに返すことができます。可能な再割り当てのため。詳細については、セクション4.4.2を参照してください。
2. Passive abort designates the SMC-R peer that is the recipient of an SMC-R abort from the peer designated by the PeerConnAbort indicator being sent by the peer in a CDC message. Upon receiving this request, the local peer must do the following:
2. パッシブアボートは、ピアからCDCメッセージで送信されるPeerConnAbortインジケーターで指定されたピアからのSMC-Rアボートの受信者であるSMC-Rピアを指定します。この要求を受信すると、ローカルピアは次のことを行う必要があります。
A. Using the appropriate error codes, indicate to the socket application that this connection has been aborted, and then purge all in-flight data for this connection that is waiting to be read or waiting to be sent.
A.適切なエラーコードを使用して、この接続が中止されたことをソケットアプリケーションに通知し、読み取りまたは送信を待機しているこの接続の処理中のデータをすべて削除します。
B. Send a CDC message to notify the peer of the PeerConnAbort indicator and, once that is completed, transition this RMBE to the Closed state.
B. CDCメッセージを送信してピアにPeerConnAbortインジケーターを通知し、それが完了すると、このRMBEをClosed状態に移行します。
If an SMC-R peer receives a TCP RST for a given SMC-R connection, it also initiates SMC-R abnormal connection termination processing if it has not already been notified (via the PeerConnAbort indicator) that the partner is severing the connection. It is possible to have two SMC-R endpoints concurrently be in an active abort role for a given connection. In that scenario, the flows above still apply but both endpoints take the active abort path (path 1).
SMC-Rピアが特定のSMC-R接続のTCP RSTを受信した場合、パートナーが接続を切断していることを（PeerConnAbortインジケーターを介して）通知されていない場合、SMC-R異常接続終了処理も開始します。特定の接続に対して、2つのSMC-Rエンドポイントを同時にアクティブな中止の役割にすることができます。そのシナリオでは、上記のフローは引き続き適用されますが、両方のエンドポイントはアクティブな中止パス（パス1）を使用します。
The following are additional conditions that have implications for SMC-R connection termination:
以下は、SMC-R接続の終了に影響する追加の条件です。
o An SMC-R peer being gracefully shut down. If an SMC-R peer supports a graceful shutdown operation, it should attempt to terminate all SMC-R connections as part of shutdown processing. This could be accomplished via LLC DELETE LINK requests on all active SMC-R links.
o 正常にシャットダウンされているSMC-Rピア。 SMC-Rピアが正常なシャットダウン操作をサポートしている場合、シャットダウン処理の一部として、すべてのSMC-R接続を終了しようとする必要があります。これは、すべてのアクティブなSMC-RリンクのLLC DELETE LINK要求を介して実行できます。
o Abnormal termination of an SMC-R peer. In this example, there may be no opportunity for the host to perform any SMC-R cleanup processing. In this scenario, it is up to the remote peer to detect a RoCE communications failure with the failing host. This could trigger SMC-R link switchover, but that would also generate RoCE errors, causing the remote host to eventually terminate all existing SMC-R connections to this peer.
o SMC-Rピアの異常終了。この例では、ホストがSMC-Rクリーンアップ処理を実行する機会がない場合があります。このシナリオでは、障害のあるホストとのRoCE通信障害を検出するのはリモートピアの責任です。これにより、SMC-Rリンクスイッチオーバーがトリガーされる可能性がありますが、RoCEエラーが生成され、リモートホストがこのピアへの既存のすべてのSMC-R接続を最終的に終了させます。
o Loss of RoCE connectivity between two SMC-R peers. If two peers are no longer reachable across any links in their SMC-R link group, then both peers perform a TCP reset for the connections, generate an error to the local applications, and free up all QP resources associated with the link group.
o 2つのSMC-Rピア間のRoCE接続の喪失。 SMC-Rリンクグループ内のリンクを介して2つのピアに到達できなくなった場合、両方のピアが接続に対してTCPリセットを実行し、ローカルアプリケーションにエラーを生成し、リンクグループに関連付けられているすべてのQPリソースを解放します。
The concepts and access control of virtual LANs (VLANs) must be extended to also cover the RoCE network traffic flowing across the Ethernet.
仮想LAN（VLAN）の概念とアクセス制御を拡張して、イーサネットを流れるRoCEネットワークトラフィックもカバーする必要があります。
The RoCE VLAN configuration and access permissions must mirror the IP VLAN configuration and access permissions over the Converged Enhanced Ethernet fabric. This means that hosts, routers, and switches that have access to specific VLANs on the IP fabric must also have the same VLAN access across the RoCE fabric. In other words, the SMC-R connectivity will follow the same virtual network access permissions as normal TCP/IP traffic.
RoCE VLANの構成とアクセス許可は、IP VLANの構成とアクセス許可をコンバージド拡張イーサネットファブリックにミラーリングする必要があります。つまり、IPファブリック上の特定のVLANにアクセスできるホスト、ルーター、およびスイッチは、RoCEファブリック全体で同じVLANアクセスも持っている必要があります。つまり、SMC-R接続は、通常のTCP / IPトラフィックと同じ仮想ネットワークアクセス許可に従います。
As mentioned above, the RoCE fabric inherits the same VLAN topology/access as the IP fabric. RoCE is a Layer 2 protocol that requires both endpoints to reside in the same Layer 2 network (i.e., VLAN). RoCE traffic cannot traverse multiple VLANs, as there is no support for routing RoCE traffic beyond a single VLAN. As a result, SMC-R communications will also be confined to peers that are members of the same VLAN. IP-based firewalls are typically inserted between VLANs (or physical LANs) and rely on normal IP routing to insert themselves in the data path. Since RoCE (and by extension SMC-R) is not routable beyond the local VLAN, there is no ability to insert a firewall in the network path of two SMC-R peers.
上記のように、RoCEファブリックはIPファブリックと同じVLANトポロジ/アクセスを継承します。 RoCEは、両方のエンドポイントが同じレイヤー2ネットワーク（つまり、VLAN）に存在する必要があるレイヤー2プロトコルです。単一のVLANを越えてRoCEトラフィックをルーティングすることはサポートされていないため、RoCEトラフィックは複数のVLANを通過できません。その結果、SMC-R通信も同じVLANのメンバーであるピアに限定されます。 IPベースのファイアウォールは通常、VLAN（または物理LAN）の間に挿入され、通常のIPルーティングに依存してデータパスに挿入されます。 RoCE（および拡張SMC-R）はローカルVLANを超えてルーティングできないため、2つのSMC-Rピアのネットワークパスにファイアウォールを挿入することはできません。
Because SMC-R maintains the TCP three-way handshake for connection setup before switching to RoCE out of band, existing IP filters that control connection setup flows remain effective in an SMC-R environment. IP filters that operate on traffic flowing in an active TCP connection are not supported, because the connection data does not flow over IP.
SMC-Rは、帯域外のRoCEに切り替える前に、接続セットアップのTCP 3ウェイハンドシェイクを維持するため、接続セットアップフローを制御する既存のIPフィルターは、SMC-R環境でも引き続き有効です。接続データはIPを経由しないため、アクティブなTCP接続を流れるトラフィックを操作するIPフィルターはサポートされません。
Similar to IP filters, intrusion detection services that operate on TCP connection setups are compatible with SMC-R with no changes required. However, once the TCP connection has switched to RoCE out of band, packets are not available for examination.
IPフィルターと同様に、TCP接続セットアップで動作する侵入検知サービスはSMC-Rと互換性があり、変更は必要ありません。ただし、TCP接続が帯域外のRoCEに切り替わると、パケットを検査できなくなります。
IP security is not compatible with SMC-R, because there are no IP packets on which to operate. TCP connections that require IP security must opt out of SMC-R.
動作するIPパケットがないため、IPセキュリティはSMC-Rと互換性がありません。 IPセキュリティーを必要とするTCP接続は、SMC-Rをオプトアウトする必要があります。
Transport Layer Security/Secure Socket Layer (TLS/SSL) is preserved in an SMC-R environment. The TLS/SSL layer resides above the SMC-R layer, and outgoing connection data is encrypted before being passed down to the SMC-R layer for RDMA write. Similarly, incoming connection data goes through the SMC-R layer encrypted and is decrypted by the TLS/SSL layer as it is today.
トランスポート層セキュリティ/ Secure Socket Layer（TLS / SSL）は、SMC-R環境で保持されます。 TLS / SSLレイヤーはSMC-Rレイヤーの上にあり、発信接続データはRDMA書き込みのためにSMC-Rレイヤーに渡される前に暗号化されます。同様に、着信接続データは暗号化されたSMC-Rレイヤーを通過し、現在のようにTLS / SSLレイヤーによって復号化されます。
The TLS/SSL handshake messages flow over the TCP connection after the connection has switched to SMC-R, and so they are exchanged using RDMA writes by the SMC-R layer, transparently to the TLS/SSL layer.
TLS / SSLハンドシェイクメッセージは、接続がSMC-Rに切り替わった後、TCP接続を介して流れます。したがって、SMC-RレイヤーによるRDMA書き込みを使用して、TLS / SSLレイヤーに対して透過的にメッセージが交換されます。
The scarcity of TCP option codes available for assignment is understood, and this architecture uses experimental TCP options following the conventions of [RFC6994] ("Shared Use of Experimental TCP Options").
割り当てに使用できるTCPオプションコードの不足が理解されており、このアーキテクチャは、[RFC6994]の規則（「実験的TCPオプションの共有使用」）に従って実験的TCPオプションを使用します。
TCP ExID 0xE2D4C3D9 has been registered with IANA as a TCP Experiment Identifier. See Section 3.1.
TCP ExID 0xE2D4C3D9は、TCP実験識別子としてIANAに登録されています。セクション3.1を参照してください。
If this protocol achieves wide acceptance, a discrete option code may be requested by subsequent versions of this protocol.
このプロトコルが広く受け入れられた場合、このプロトコルの後続のバージョンで個別のオプションコードが要求されることがあります。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013, <http://www.rfc-editor.org/info/rfc6994>.
[RFC6994] Touch、J。、「実験的TCPオプションの共有使用」、RFC 6994、DOI 10.17487 / RFC6994、2013年8月、<http://www.rfc-editor.org/info/rfc6994>。
[RoCE] InfiniBand, "RDMA over Converged Ethernet specification", <https://cw.infinibandta.org/wg/Members/documentRevision/ download/7149>.
[RoCE] InfiniBand、「RDMA over Converged Ethernet仕様」、<https://cw.infinibandta.org/wg/Members/documentRevision/download/7149>。
The SMC-R TCP option is formatted in accordance with [RFC6994] ("Shared Use of Experimental TCP Options"). The ExID value is IBM-1047 (EBCDIC) encoding for "SMCR".
SMC-R TCPオプションは、[RFC6994]（「実験的TCPオプションの共有使用」）に従ってフォーマットされています。 ExID値は、「SMCR」のIBM-1047（EBCDIC）エンコードです。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Kind = 254 | Length = 6 | x'E2' | x'D4' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 24: SMC-R TCP Option Format
図24：SMC-R TCPオプションの形式
The following rules apply to all CLC messages:
次の規則がすべてのCLCメッセージに適用されます。
General rules on formats:
フォーマットに関する一般的な規則：
o Reserved fields must be set to zero and not validated.
o 予約フィールドはゼロに設定し、検証しないでください。
o Each message has an eye catcher at the start and another eye catcher at the end. These must both be validated by the receiver.
o 各メッセージには、最初にアイキャッチャーがあり、最後に別のアイキャッチャーがあります。これらは両方とも受信側によって検証される必要があります。
o SMC version indicator: The only SMC-R version defined in this architecture is version 1. In the future, if peers have a mismatch of versions, the lowest common version number is used.
o SMCバージョンインジケータ：このアーキテクチャで定義されているSMC-Rバージョンは、バージョン1のみです。将来、ピアにバージョンの不一致がある場合、最も小さい共通バージョン番号が使用されます。
All CLC messages contain a peer ID that uniquely identifies an instance of a TCP/IP stack. This peer ID is required to be universally unique across TCP/IP stacks and instances (including restarts) of TCP/IP stacks.
すべてのCLCメッセージには、TCP / IPスタックのインスタンスを一意に識別するピアIDが含まれています。このピアIDは、TCP / IPスタックおよびTCP / IPスタックのインスタンス（再起動を含む）全体で普遍的に一意である必要があります。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Instance ID | RoCE MAC (first 2 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RoCE MAC (last 4 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 25: Peer ID Format
図25：ピアIDの形式
Instance ID
インスタンスID
A 2-byte instance count that ensures that if the same RNIC MAC is later used in the peer ID for a different TCP/IP stack -- for example, if an RNIC is redeployed to another stack -- the values are unique. It also ensures that if a TCP/IP stack is restarted, the instance ID changes. The value is implementation defined, with one suggestion being 2 bytes of the system clock.
同じRNIC MACが後で別のTCP / IPスタックのピアIDで使用される場合（たとえば、RNICが別のスタックに再デプロイされる場合）を保証する2バイトのインスタンス数。値は一意です。また、TCP / IPスタックが再起動された場合、インスタンスIDが確実に変更されます。値は実装定義であり、1つの提案はシステムクロックの2バイトです。
RoCE MAC
RoCE MAC
The RoCE MAC address for one of the peer's RNICs. Note that in a virtualized environment this will be the virtual MAC of one of the peer's RNICs.
ピアのRNICの1つのRoCE MACアドレス。仮想化環境では、これはピアのRNICの1つの仮想MACになることに注意してください。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length |Version| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Client's Peer ID -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Client's preferred GID -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client's preferred RoCE |
+- MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Offset to mask/prefix area (0) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. Area for future growth .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Subnet Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv4 Mask Lgth| Reserved |Num IPv6 prfx |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
: Array of IPv6 prefixes (variable length) :
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 26: SMC Proposal CLC Message Format
図26：SMCプロポーザルCLCメッセージ形式
The fields present in the SMC Proposal CLC message are:
SMCプロポーザルCLCメッセージに含まれるフィールドは次のとおりです。
Eye catchers
目印
Like all CLC messages, the SMC Proposal has beginning and ending eye catchers to aid with verification and parsing. The hex digits spell "SMCR" in IBM-1047 (EBCDIC).
すべてのCLCメッセージと同様に、SMCプロポーザルには、検証と解析を支援する開始と終了の目印があります。 16進数字は、IBM-1047（EBCDIC）では「SMCR」と表記します。
Type
タイプ
CLC message Type 1 indicates SMC Proposal.
CLCメッセージタイプ1は、SMCプロポーザルを示します。
Length
長さ
The length of this CLC message. If this is an IPv4 flow, this value is 52. Otherwise, it is variable, depending upon how many prefixes are listed.
このCLCメッセージの長さ。これがIPv4フローの場合、この値は52です。それ以外の場合は、リストされているプレフィックスの数に応じて可変です。
Version
バージョン
Version of the SMC-R protocol. Version 1 is the only currently defined value.
SMC-Rプロトコルのバージョン。現在定義されている値はバージョン1のみです。
Client's Peer ID
クライアントのピアID
As described in Appendix A.2.1 above.
上記の付録A.2.1に記載されています。
Client's preferred RoCE GID
クライアントが推奨するRiCE GIF
The IPv6 address of the client's preferred RNIC on the RoCE fabric.
RoCEファブリック上のクライアントの優先RNICのIPv6アドレス。
Client's preferred RoCE MAC address
クライアントの優先RoCE MACアドレス
The MAC address of the client's preferred RNIC on the RoCE fabric. It is required, as some operating systems do not have neighbor discovery or ARP support for RoCE RNICs.
RoCEファブリック上のクライアントの優先RNICのMACアドレス。一部のオペレーティングシステムにはRoCE RNICのネイバー探索またはARPサポートがないため、これは必須です。
Offset to mask/prefix area
マスク/プレフィックス領域へのオフセット
Provides the number of bytes that must be skipped after this field, to access the IPv4 Subnet Mask field and the fields that follow it. Allows for future growth of this signal. In this version of the architecture, this value is always zero.
IPv4サブネットマスクフィールドとそれに続くフィールドにアクセスするために、このフィールドの後にスキップする必要があるバイト数を提供します。このシグナルの将来の成長を可能にします。このバージョンのアーキテクチャでは、この値は常にゼロです。
Area for future growth
今後の成長領域
In this version of the architecture, this field does not exist. This indicates where additional information may be inserted into the signal in the future. The "Offset to mask/prefix area" field must be used to skip over this area.
このバージョンのアーキテクチャでは、このフィールドは存在しません。これは、将来信号に追加情報が挿入される可能性がある場所を示します。この領域をスキップするには、[マスク/プレフィックス領域へのオフセット]フィールドを使用する必要があります。
IPv4 Subnet Mask
IPv4サブネットマスク
If this message is flowing over an IPv4 TCP connection, the value of the subnet mask associated with the interface over which the client sent this message. If this is an IPv6 flow, this field is all zeros.
このメッセージがIPv4 TCP接続を介して流れている場合、クライアントがこのメッセージを送信したインターフェイスに関連付けられているサブネットマスクの値。これがIPv6フローの場合、このフィールドはすべてゼロです。
This field, along with all fields that follow it in this signal, must be accessed by skipping the number of bytes listed in the "Offset to mask/prefix area" field after the end of that field.
このフィールドは、この信号の後に続くすべてのフィールドと一緒に、そのフィールドの終わりの「オフセット/マスク/プレフィックス領域」フィールドにリストされているバイト数をスキップしてアクセスする必要があります。
IPv4 Mask Lgth
IPv4マスク長
If this message is flowing over an IPv4 TCP connection, the number of significant bits in the IPv4 Subnet Mask field. If this is an IPv6 flow, this field is zero.
このメッセージがIPv4 TCP接続を介して流れている場合、IPv4サブネットマスクフィールドの有効ビット数。これがIPv6フローの場合、このフィールドはゼロです。
Num IPv6 prfx
IPv6 prfx
If this message is flowing over an IPv6 TCP connection, the number of IPv6 prefixes that follow, with a maximum value of 8. If this is an IPv4 flow, this field is zero and is immediately followed by the ending eye catcher.
このメッセージがIPv6 TCP接続を介して流れている場合、それに続くIPv6プレフィックスの数。最大値は8です。これがIPv4フローの場合、このフィールドはゼロで、直後に終了アイキャッチャーが続きます。
Array of IPv6 prefixes
IPv6プレフィックスの配列
For IPv6 TCP connections, a list of the IPv6 prefixes associated with the network over which the client sent this message, up to a maximum of eight prefixes.
IPv6 TCP接続の場合、クライアントがこのメッセージを送信したネットワークに関連付けられたIPv6プレフィックスのリスト（最大8個のプレフィックス）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| |
+ IPv6 prefix value +
| |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix Length |
+-+-+-+-+-+-+-+-+
Figure 27: Format for IPv6 Prefix Array Element
図27：IPv6プレフィックス配列要素の形式
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 68 |Version|F|Rsrvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Server's Peer ID -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Server's RoCE GID -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Server's RoCE |
+- MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Server QP (bytes 1-2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+
|Srvr QP byte 3 | Server RMB RKey (bytes 1-3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Srvr RMB byte 4|Server RMB indx| Srvr RMB alert tkn (bytes 1-2)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Srvr RMB alert tkn (bytes 3-4)|Bsize | MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Server's RMB virtual address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Server's initial packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 28: SMC Accept CLC Message Format
図28：SMC Accept CLCメッセージフォーマット
The fields present in the SMC Accept CLC message are:
SMC Accept CLCメッセージにあるフィールドは次のとおりです。
Eye catchers
目印
Like all CLC messages, the SMC Accept has beginning and ending eye catchers to aid with verification and parsing. The hex digits spell "SMCR" in IBM-1047 (EBCDIC).
すべてのCLCメッセージと同様に、SMC Acceptには、検証と解析を支援する開始と終了の目印があります。 16進数字は、IBM-1047（EBCDIC）では「SMCR」と表記します。
Type
タイプ
CLC message Type 2 indicates SMC Accept.
CLCメッセージタイプ2は、SMC Acceptを示します。
Length
長さ
The SMC Accept CLC message is 68 bytes long.
SMC Accept CLCメッセージは68バイトの長さです。
Version
バージョン
Version of the SMC-R protocol. Version 1 is the only currently defined value.
SMC-Rプロトコルのバージョン。現在定義されている値はバージョン1のみです。
F-bit
Fビット
First contact flag: A 1-bit flag that indicates that the server believes this TCP connection is the first SMC-R contact for this link group.
最初の連絡先フラグ：このTCP接続がこのリンクグループの最初のSMC-R連絡先であるとサーバーが信じていることを示す1ビットのフラグ。
Server's Peer ID
サーバーのピアID
As described in Appendix A.2.1 above.
上記の付録A.2.1に記載されています。
Server's RoCE GID
ServerS Roseガイド
The IPv6 address of the RNIC that the server chose for this SMC-R link.
サーバーがこのSMC-Rリンク用に選択したRNICのIPv6アドレス。
Server's RoCE MAC address
サーバーのRoCE MACアドレス
The MAC address of the server's RNIC for the SMC-R link. It is required, as some operating systems do not have neighbor discovery or ARP support for RoCE RNICs.
SMC-Rリンク用のサーバーのRNICのMACアドレス。一部のオペレーティングシステムにはRoCE RNICのネイバー探索またはARPサポートがないため、これは必須です。
Server's QP number
サーバーのQP番号
The number for the reliably connected queue pair that the server created for this SMC-R link.
サーバーがこのSMC-Rリンク用に作成した、確実に接続されたキューペアの数。
Server's RMB RKey
サーバーのRMB RKey
The RDMA RKey for the RMB that the server created or chose for this TCP connection.
サーバーがこのTCP接続用に作成または選択したRMBのRDMA RKey。
Server's RMB element index
サーバーのRMB要素のインデックス
Indexes which element within the server's RMB will represent this TCP connection.
サーバーのRMB内のどの要素がこのTCP接続を表すかをインデックスします。
Server's RMB element alert token
サーバーのRMB要素アラートトークン
A platform-defined, architecturally opaque token that identifies this TCP connection. Added by the client as immediate data on RDMA writes from the client to the server to inform the server that there is data for this connection to retrieve from the RMB element.
このTCP接続を識別する、プラットフォームで定義された、構造的に不透明なトークン。 RMB要素から取得するこの接続のデータがあることをサーバーに通知するために、クライアントからサーバーへのRDMA書き込みの即時データとしてクライアントによって追加されます。
Bsize:
Bsize：
Server's RMB element buffer size in 4-bit compressed notation: x = 4 bits. Actual buffer size value is (2^(x + 4)) * 1K. Smallest possible value is 16K. Largest size supported by this architecture is 512K.
サーバーのRMB要素のバッファーサイズ（4ビット圧縮表記）：x = 4ビット。実際のバッファサイズの値は（2 ^（x + 4））* 1Kです。可能な最小値は16Kです。このアーキテクチャでサポートされる最大サイズは512Kです。
MTU
MTU
An enumerated value indicating this peer's QP MTU size. The two peers exchange their MTU values, and whichever value is smaller will be used for the QP. This field should only be validated in the first contact exchange.
このピアのQP MTUサイズを示す列挙値。 2つのピアはMTU値を交換し、どちらか小さい方の値がQPに使用されます。このフィールドは、最初の連絡先交換でのみ検証する必要があります。
The enumerated MTU values are:
列挙されたMTU値は次のとおりです。
0: reserved
0：予約済み
1: 256
１： ２５６
2: 512
２： ５１２
3: 1024
３： １０２４
4: 2048
４： ２０４８
5: 4096
５： ４０９６
6-15: reserved
6-15：予約済み
Server's RMB virtual address
サーバーのRMB仮想アドレス
The virtual address of the server's RMB as assigned by the server's RNIC.
サーバーのRNICによって割り当てられたサーバーのRMBの仮想アドレス。
Server's initial packet sequence number
サーバーの初期パケットシーケンス番号
The starting packet sequence number that this peer will use when sending to the other peer, so that the other peer can prepare its QP for the sequence number to expect.
このピアが他のピアに送信するときに使用する開始パケットシーケンス番号。これにより、他のピアは、シーケンス番号が予期するQPを準備できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 68 |Version| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Client's Peer ID -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Client's RoCE GID -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Client's RoCE |
+- MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | Client QP (bytes 1-2) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+---+
|Clnt QP byte 3 | Client RMB RKey (bytes 1-3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Clnt RMB byte 4|Client RMB indx| Clnt RMB alert tkn (bytes 1-2)|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Clnt RMB alert tkn (bytes 3-4)|Bsize | MTU | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Client's RMB Virtual Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Client's initial packet sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 29: SMC Confirm CLC Message Format
図29：SMC確認CLCメッセージ形式
The SMC Confirm CLC message is nearly identical to the SMC Accept, except that it contains client information and lacks a first contact flag.
SMC確認CLCメッセージは、クライアント情報が含まれ、最初の連絡フラグがないことを除いて、SMC承認とほぼ同じです。
The fields present in the SMC Confirm CLC message are:
SMC確認CLCメッセージにあるフィールドは次のとおりです。
Eye catchers
目印
Like all CLC messages, the SMC Confirm has beginning and ending eye catchers to aid with verification and parsing. The hex digits spell "SMCR" in IBM-1047 (EBCDIC).
すべてのCLCメッセージと同様に、SMC確認には、検証と解析を支援する開始と終了の目印があります。 16進数字は、IBM-1047（EBCDIC）では「SMCR」と表記します。
Type
タイプ
CLC message Type 3 indicates SMC Confirm.
CLCメッセージタイプ3は、SMC確認を示します。
Length
長さ
The SMC Confirm CLC message is 68 bytes long.
SMC確認CLCメッセージは68バイト長です。
Version
バージョン
Version of the SMC-R protocol. Version 1 is the only currently defined value.
SMC-Rプロトコルのバージョン。現在定義されている値はバージョン1のみです。
Client's Peer ID
クライアントのピアID
As described in Appendix A.2.1 above.
上記の付録A.2.1に記載されています。
Client's RoCE GID
クライアントのRoCE GID
The IPv6 address of the RNIC that the client chose for this SMC-R link.
クライアントがこのSMC-Rリンク用に選択したRNICのIPv6アドレス。
Client's RoCE MAC address
クライアントのRoCE MACアドレス
The MAC address of the client's RNIC for the SMC-R link. It is required, as some operating systems do not have neighbor discovery or ARP support for RoCE RNICs.
SMC-Rリンク用のクライアントのRNICのMACアドレス。一部のオペレーティングシステムにはRoCE RNICのネイバー探索またはARPサポートがないため、これは必須です。
Client's QP number
クライアントのQP番号
The number for the reliably connected queue pair that the client created for this SMC-R link.
クライアントがこのSMC-Rリンク用に作成した、確実に接続されたキューペアの数。
Client's RMB RKey
クライアントのRMB RKey
The RDMA RKey for the RMB that the client created or chose for this TCP connection.
クライアントがこのTCP接続用に作成または選択したRMBのRDMA RKey。
Client's RMB element index
クライアントのRMB要素のインデックス
Indexes which element within the client's RMB will represent this TCP connection.
クライアントのRMB内のどの要素がこのTCP接続を表すかを示すインデックス。
Client's RMB element alert token
クライアントのRMB要素アラートトークン
A platform-defined, architecturally opaque token that identifies this TCP connection. Added by the server as immediate data on RDMA writes from the server to the client to inform the client that there is data for this connection to retrieve from the RMB element.
このTCP接続を識別する、プラットフォームで定義された、構造的に不透明なトークン。 RMB要素から取得するこの接続のデータがあることをクライアントに通知するために、サーバーからクライアントへのRDMA書き込みの即時データとしてサーバーによって追加されます。
Bsize:
Bsize：
Client's RMB element buffer size in 4-bit compressed notation: x = 4 bits. Actual buffer size value is (2^(x + 4)) * 1K. Smallest possible value is 16K. Largest size supported by this architecture is 512K.
4ビット圧縮表記でのクライアントのRMB要素バッファーサイズ：x = 4ビット。実際のバッファサイズの値は（2 ^（x + 4））* 1Kです。可能な最小値は16Kです。このアーキテクチャでサポートされる最大サイズは512Kです。
MTU
MTU
An enumerated value indicating this peer's QP MTU size. The two peers exchange their MTU values, and whichever value is smaller will be used for the QP. The values are enumerated in Appendix A.2.3. This value should only be validated in the first contact exchange.
このピアのQP MTUサイズを示す列挙値。 2つのピアはMTU値を交換し、どちらか小さい方の値がQPに使用されます。値は付録A.2.3に列挙されています。この値は、最初の連絡先交換でのみ検証する必要があります。
Client's RMB Virtual Address
クライアントのRMB仮想アドレス
The virtual address of the client's RMB as assigned by the server's RNIC.
サーバーのRNICによって割り当てられたクライアントのRMBの仮想アドレス。
Client's initial packet sequence number
クライアントの初期パケットシーケンス番号
The starting packet sequence number that this peer will use when sending to the other peer, so that the other peer can prepare its QP for the sequence number to expect.
このピアが他のピアに送信するときに使用する開始パケットシーケンス番号。これにより、他のピアは、シーケンス番号が予期するQPを準備できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 28 |Version|S|Rsrvd|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Sender's Peer ID -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Peer Diagnosis Information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| x'E2' | x'D4' | x'C3' | x'D9' |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 30: SMC Decline CLC Message Format
図30：SMC拒否CLCメッセージ形式
The fields present in the SMC Decline CLC message are:
SMC Decline CLCメッセージに含まれるフィールドは次のとおりです。
Eye catchers
目印
Like all CLC messages, the SMC Decline has beginning and ending eye catchers to aid with verification and parsing. The hex digits spell "SMCR" in IBM-1047 (EBCDIC).
すべてのCLCメッセージと同様に、SMC拒否には、検証と解析を支援するための開始と終了の目印があります。 16進数字は、IBM-1047（EBCDIC）では「SMCR」と表記します。
Type
タイプ
CLC message Type 4 indicates SMC Decline.
CLCメッセージタイプ4は、SMC拒否を示します。
Length
長さ
The SMC Decline CLC message is 28 bytes long.
SMC Decline CLCメッセージは28バイトの長さです。
Version
バージョン
Version of the SMC-R protocol. Version 1 is the only currently defined value.
SMC-Rプロトコルのバージョン。現在定義されている値はバージョン1のみです。
S-bit
Sビット
Sync Bit. Indicates that the link group is out of sync and the receiving peer must clean up its representation of the link group.
同期ビット。リンクグループが同期しておらず、受信ピアがリンクグループの表現をクリーンアップする必要があることを示します。
Sender's Peer ID
送信者のピアID
As described in Appendix A.2.1 above.
上記の付録A.2.1に記載されています。
Peer Diagnosis Information
ピア診断情報
4 bytes of diagnosis information provided by the peer. These values are defined by the individual peers, and it is necessary to consult the peer's system documentation to interpret the results.
ピアから提供された4バイトの診断情報。これらの値は個々のピアによって定義され、結果を解釈するにはピアのシステムドキュメントを参照する必要があります。
LLC messages are sent over an existing SMC-R link using RoCE SendMsg and are always 44 bytes long so that they fit into the space available in a single WQE without requiring the receiver to post receive buffers. If all 44 bytes are not needed, they are padded out with zeros. LLC messages are in a request/response format. The message type is the same for request and response, and a flag indicates whether a message is flowing as a request or a response.
LLCメッセージは、RoCE SendMsgを使用して既存のSMC-Rリンクを介して送信され、常に44バイトの長さであるため、レシーバーが受信バッファーをポストすることなく、単一のWQEで使用可能なスペースに収まります。 44バイトすべてが必要でない場合は、ゼロが埋め込まれます。 LLCメッセージは要求/応答形式です。メッセージタイプは要求と応答で同じであり、フラグはメッセージが要求または応答として流れているかどうかを示します。
The two high-order bits of an LLC message opcode indicate how it is to be handled by a peer that does not support the opcode.
LLCメッセージのオペコードの上位2ビットは、オペコードをサポートしていないピアがそれをどのように処理するかを示します。
If the high-order bits of the opcode are b'00', then the peer must support the LLC message and indicate a protocol error if it does not.
オペコードの上位ビットがb'00 'の場合、ピアはLLCメッセージをサポートし、サポートしていない場合はプロトコルエラーを示す必要があります。
If the high-order bits of the opcode are b'10', then the peer must silently discard the LLC message if it does not support the opcode. This requirement is included to allow for toleration of advanced, but optional, functionality.
opcodeの上位ビットがb'10 'の場合、opcodeをサポートしていないピアはLLCメッセージを暗黙的に破棄する必要があります。この要件は、高度ではあるがオプションの機能を許容できるようにするために含まれています。
High-order bits of b'11' indicate a Connection Data Control (CDC) message as described in Appendix A.4.
付録A.4で説明されているように、b'11 'の上位ビットは接続データ制御（CDC）メッセージを示します。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 1 | Length = 44 | Reserved |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's RoCE |
+- MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+- -+
| Sender's RoCE GID |
+- -+
| |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Sender's QP number, bytes 1-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sender QP byte3| Link number |Sender's link userID, bytes 1-2|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sender's link userID, bytes 3-4| Max links | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- Reserved -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 31: CONFIRM LINK LLC Message Format
図31：CONFIRM LINK LLCメッセージの形式
The CONFIRM LINK LLC message is required to be exchanged between the server and client over a newly created SMC-R link to complete the setup of an SMC-R link. Its purpose is to confirm that the RoCE path is actually usable.
CONFIRM LINK LLCメッセージは、SMC-Rリンクのセットアップを完了するために、新しく作成されたSMC-Rリンクを介してサーバーとクライアント間で交換される必要があります。その目的は、RoCEパスが実際に使用可能であることを確認することです。
On first contact, this message flows after the server receives the SMC Confirm CLC message from the client over the IP connection. For additional links added to an SMC-R link group, it flows after the ADD LINK and ADD LINK CONTINUATION exchange. This flow provides confirmation that the queue pair is in fact usable. Each peer echoes its RoCE information back to the other.
最初の連絡では、サーバーがIP接続を介してクライアントからSMC確認CLCメッセージを受信した後に、このメッセージが流れます。 SMC-Rリンクグループに追加された追加リンクの場合は、ADD LINKおよびADD LINK CONTINUATION交換の後にフローが流れます。このフローは、キューペアが実際に使用可能であることを確認します。各ピアは、RoCE情報を他のピアにエコーします。
The contents of the CONFIRM LINK LLC message are:
CONFIRM LINK LLCメッセージの内容は次のとおりです。
Type
タイプ
Type 1 indicates CONFIRM LINK.
タイプ1は、リンクの確認を示します。
Length
長さ
The CONFIRM LINK LLC message is 44 bytes long.
CONFIRM LINK LLCメッセージは44バイトの長さです。
R
R
Reply flag. When set, indicates that this is a CONFIRM LINK reply.
返信フラグ。設定されている場合、これがCONFIRM LINK応答であることを示します。
Sender's RoCE MAC address
送信者のRoCE MACアドレス
The MAC address of the sender's RNIC for the SMC-R link. It is required, as some operating systems do not have neighbor discovery or ARP support for RoCE RNICs.
SMC-Rリンクの送信側のRNICのMACアドレス。一部のオペレーティングシステムにはRoCE RNICのネイバー探索またはARPサポートがないため、これは必須です。
Sender's RoCE GID
送信者のRoCE GID
The IPv6 address of the RNIC that the sender is using for this SMC-R link.
送信者がこのSMC-Rリンクに使用しているRNICのIPv6アドレス。
Sender's QP number
送信者のQP番号
The number for the reliably connected queue pair that the sender created for this SMC-R link.
送信者がこのSMC-Rリンク用に作成した、確実に接続されたキューペアの番号。
Link number
リンク番号
An identifier assigned by the server that uniquely identifies the link within the link group. This identifier is ONLY unique within a link group. Provided by the server and echoed back by the client.
リンクグループ内のリンクを一意に識別する、サーバーによって割り当てられた識別子。この識別子は、リンクグループ内でのみ一意です。サーバーによって提供され、クライアントによってエコーバックされます。
Link user ID
ユーザーIDをリンク
An opaque, implementation-defined identifier assigned by the sender and provided to the receiver solely for purposes of display, diagnosis, network management, etc. The link user ID should be unique across the sender's entire software space, including all other link groups.
送信者によって割り当てられ、表示、診断、ネットワーク管理などの目的でのみ受信者に提供される不透明な実装定義の識別子。リンクユーザーIDは、他のすべてのリンクグループを含む送信者のソフトウェアスペース全体で一意である必要があります。
Max links
最大リンク
The maximum number of links the sender can support in a link group. The maximum for this link group is the smaller of the values provided by the two peers.
送信者がリンクグループでサポートできるリンクの最大数。このリンクグループの最大値は、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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 2 | Length = 44 | Rsrvd |RsnCode|R|Z| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender's RoCE |
+- MAC address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
+- -+
| Sender's RoCE GID |
+- -+
| |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |Sender's QP number, bytes 1-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sender QP byte3| Link number |Rsrvd | MTU |Initial PSN |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Initial PSN (continued) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+
| Reserved |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 32: ADD LINK LLC Message Format
図32：ADD LINK LLCメッセージの形式
The ADD LINK LLC message is sent over an existing link in the link group when a peer wishes to add an SMC-R link to an existing SMC-R link group. It is sent by the server to add a new SMC-R link to the group, or by the client to request that the server add a new link -- for example, when a new RNIC becomes active. When sent from the client to the server, it represents a request that the server initiate an ADD LINK exchange.
ADD LINK LLCメッセージは、ピアがSMC-Rリンクを既存のSMC-Rリンクグループに追加する場合に、リンクグループの既存のリンクを介して送信されます。これは、サーバーが新しいSMC-Rリンクをグループに追加するために送信するか、クライアントがサーバーに新しいリンクを追加するように要求する（たとえば、新しいRNICがアクティブになったとき）に送信されます。クライアントからサーバーに送信される場合、サーバーがADD LINK交換を開始する要求を表します。
This message is sent immediately after the initial SMC-R link in the group completes, as described in Section 3.5.1 ("First Contact"). It can also be sent over an existing SMC-R link group at any time as new RNICs are added and become available. Therefore, there can be as few as one new RMB RToken to be communicated, or several. RTokens will be communicated using ADD LINK CONTINUATION messages.
このメッセージは、セクション3.5.1（「最初の連絡先」）で説明されているように、グループ内の最初のSMC-Rリンクが完了した直後に送信されます。また、新しいRNICが追加されて使用可能になると、いつでも既存のSMC-Rリンクグループを介して送信できます。したがって、通信する新しいRMB RTokenは1つだけでも、いくつかでもかまいません。 RTokenは、ADD LINK CONTINUATIONメッセージを使用して通信されます。
The contents of the ADD LINK LLC message are:
ADD LINK LLCメッセージの内容は次のとおりです。
Type
タイプ
Type 2 indicates ADD LINK.
タイプ2はリンクの追加を示します。
Length
長さ
The ADD LINK LLC message is 44 bytes long.
ADD LINK LLCメッセージは44バイトの長さです。
RsnCode
RsnCode
If the Z (rejection) flag is set, this field provides the reason code. Values can be:
Z（拒否）フラグが設定されている場合、このフィールドは理由コードを提供します。値は次のとおりです。
X'1' - no alternate path available: set when the server provides the same MAC/GID as an existing SMC-R link in the group, and the client does not have any additional RNICs available (i.e., the server is attempting to set up an asymmetric link but none is available).
X'1 '-使用可能な代替パスなし：サーバーがグループ内の既存のSMC-Rリンクと同じMAC / GIDを提供し、クライアントが追加のRNICを使用できない場合（つまり、サーバーが設定を試みている場合）非対称リンクをアップしますが、何も利用できません）。
X'2' - Invalid MTU value specified.
X'2 '-無効なMTU値が指定されました。
R
R
Reply flag. When set, indicates that this is an ADD LINK reply.
返信フラグ。設定されている場合、これがリンク追加応答であることを示します。
Z
と
Rejection flag. When set on reply, indicates that the server's ADD LINK was rejected by the client. When this flag is set, the reason code will also be set.
拒否フラグ。応答時に設定された場合、サーバーのADD LINKがクライアントによって拒否されたことを示します。このフラグが設定されると、理由コードも設定されます。
Sender's RoCE MAC address
送信者のRoCE MACアドレス
The MAC address of the sender's RNIC for the new SMC-R link. It is required, as some operating systems do not have neighbor discovery or ARP support for RoCE RNICs.
新しいSMC-Rリンクの送信者のRNICのMACアドレス。一部のオペレーティングシステムにはRoCE RNICのネイバー探索またはARPサポートがないため、これは必須です。
Sender's RoCE GID
送信者のRoCE GID
The IPv6 address of the RNIC that the sender is using for the new SMC-R link.
送信者が新しいSMC-Rリンクに使用しているRNICのIPv6アドレス。
Sender's QP number
送信者のQP番号
The number for the reliably connected queue pair that the sender created for the new SMC-R link.
送信者が新しいSMC-Rリンク用に作成した、確実に接続されたキューペアの番号。
Link number
リンク番号
An identifier for the new SMC-R link. This is assigned by the server and uniquely identifies the link within the link group. This identifier is ONLY unique within a link group. Provided by the server and echoed back by the client.
新しいSMC-Rリンクの識別子。これはサーバーによって割り当てられ、リンクグループ内のリンクを一意に識別します。この識別子は、リンクグループ内でのみ一意です。サーバーによって提供され、クライアントによってエコーバックされます。
MTU
MTU
An enumerated value indicating this peer's QP MTU size. The two peers exchange their MTU values, and whichever value is smaller will be used for the QP. The values are enumerated in Appendix A.2.3.
このピアのQP MTUサイズを示す列挙値。 2つのピアはMTU値を交換し、どちらか小さい方の値がQPに使用されます。値は付録A.2.3に列挙されています。
Initial PSN
最初のPSN
The starting packet sequence number (PSN) that this peer will use when sending to the other peer, so that the other peer can prepare its QP for the sequence number to expect.
このピアが他のピアに送信するときに使用する開始パケットシーケンス番号（PSN）。これにより、他のピアは、シーケンス番号が予期するQPを準備できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 3 | Length = 44 | Reserved |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Linknum | NumRTokens | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- RKey/RToken pair -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- RKey/RToken pair or zeros -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 33: ADD LINK CONTINUATION LLC Message Format
図33：ADD LINK CONTINUATION LLCメッセージフォーマット
When a new SMC-R link is added to an SMC-R link group, it is necessary to communicate the new link's RTokens for the RMBs that the SMC-R link group can access. This message follows the ADD LINK and provides the RTokens.
新しいSMC-RリンクがSMC-Rリンクグループに追加された場合、SMC-RリンクグループがアクセスできるRMBの新しいリンクのRTokenを通信する必要があります。このメッセージはADD LINKに続き、RTokenを提供します。
The server kicks off this exchange by sending the first ADD LINK CONTINUATION LLC message, and the server controls the exchange as described below.
サーバーは最初のADD LINK CONTINUATION LLCメッセージを送信してこの交換を開始し、サーバーは以下で説明するように交換を制御します。
o If the client and the server require the same number of ADD LINK CONTINUATION messages to communicate their RTokens, the server starts the exchange by sending the first ADD LINK CONTINUATION request to the client with its (the server's) RTokens. The client then responds with an ADD LINK CONTINUATION response with its RTokens, and so on until the exchange is completed.
o クライアントとサーバーがRTokenを通信するために同数のADD LINK CONTINUATIONメッセージを必要とする場合、サーバーは最初のADD LINK CONTINUATIONリクエストを（サーバーの）RTokenと共にクライアントに送信することで交換を開始します。次に、クライアントはRTokenを含むADD LINK CONTINUATION応答で応答し、交換が完了するまで続きます。
o If the server requires more ADD LINK CONTINUATION messages than the client, then after the client has communicated all of its RTokens, the server continues to send ADD LINK CONTINUATION request messages to the client. The client continues to respond, using empty (number of RTokens to be communicated = 0) ADD LINK CONTINUATION response messages.
o サーバーがクライアントよりも多くのADD LINK CONTINUATIONメッセージを必要とする場合、クライアントがすべてのRTokenを伝達した後、サーバーは引き続きADD LINK CONTINUATION要求メッセージをクライアントに送信します。クライアントは、空（通信されるRTokenの数= 0）ADD LINK CONTINUATION応答メッセージを使用して応答を続けます。
o If the client requires more ADD LINK CONTINUATION messages than the server, then after communicating all of its RTokens, the server will continue to send empty ADD LINK CONTINUATION messages to the client to solicit replies with the client's RTokens, until all have been communicated.
o クライアントがサーバーよりも多くのADD LINK CONTINUATIONメッセージを必要とする場合、そのすべてのRTokenを通信した後、サーバーは空のADD LINK CONTINUATIONメッセージをクライアントに送信し続け、すべてが通信されるまでクライアントのRTokenで応答を要求します。
The contents of the ADD LINK CONTINUATION LLC message are:
ADD LINK CONTINUATION LLCメッセージの内容は次のとおりです。
Type
タイプ
Type 3 indicates ADD LINK CONTINUATION.
タイプ3はADD LINK CONTINUATIONを示します。
Length
長さ
The ADD LINK CONTINUATION LLC message is 44 bytes long.
ADD LINK CONTINUATION LLCメッセージは44バイトの長さです。
R
R
Reply flag. When set, indicates that this is an ADD LINK CONTINUATION reply.
返信フラグ。設定されている場合、これがADD LINK CONTINUATION応答であることを示します。
LinkNum
LinkNum
The link number of the new link within the SMC-R link group for which RKeys are being communicated.
RKeyが通信されているSMC-Rリンクグループ内の新しいリンクのリンク番号。
NumRTokens
NumRTokens
Number of RTokens remaining to be communicated (including the ones in this message). If the value is less than or equal to 2, this is the last message. If it is greater than 2, another continuation message will be required, and its value will be the value in this message minus 2, and so on until all RKeys are communicated. The maximum value for this field is 255.
通信するために残っているRTokenの数（このメッセージ内のものを含む）。値が2以下の場合、これが最後のメッセージです。 2より大きい場合、別の継続メッセージが必要になり、その値はこのメッセージの値から2を引いたものになります。以降、すべてのRKeyが伝達されるまで続きます。このフィールドの最大値は255です。
RKey/RToken pairs (two or less)
キー/トークンのペア（2つ以下）
These consist of an RKey for an RMB that is known on the SMC-R link over which this message was sent (the reference RKey), paired with the same RMB's RToken over the new SMC-R link. A full RToken is not required for the reference, because it is only being used to distinguish which RMB it applies to, not address it.
これらは、このメッセージが送信されたSMC-Rリンク（参照RKey）で既知のRMBのRKeyで構成され、新しいSMC-Rリンクで同じRMBのRTokenとペアになります。完全なRTokenは、それがどのRMBに適用されるかを区別するためだけに使用されており、アドレス指定されていないため、参照には必要ありません。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference RKey |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| New RKey |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- New Virtual Address -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 34: RKey/RToken Pair Format
図34：キー/トークンペアの形式
The contents of the RKey/RToken pair are:
キーとトークンのペアの内容は次のとおりです。
Reference RKey
リファレンスRKey
The RKey of the RMB as it is already known on the SMC-R link over which this message is being sent. Required so that the peer knows with which RMB to associate the new RToken.
このメッセージが送信されているSMC-RリンクですでにわかっているRMBのRKey。ピアが新しいRTokenを関連付けるRMBを認識するために必要です。
New RKey
新しいRKey
The RKey of this RMB as it is known over the new SMC-R link.
新しいSMC-Rリンクで知られているこのRMBのRKey。
New Virtual Address
New Virtual Address
The virtual address of this RMB as it is known over the new SMC-R link.
The virtual address of this RMB as it is known over the new SMC-R link.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 4 | Length = 44 | Reserved |R|A|O| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Linknum | reason code (bytes 1-3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RsnCode byte 4 | |
+-+-+-+-+-+-+-+-+ -+
| |
+- -+
| |
+- -+
| |
+- Reserved -+
| |
+- -+
| |
+- -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 35: DELETE LINK LLC Message Format
図35：DELETE LINK LLCメッセージの形式
When the client or server detects that a QP or SMC-R link goes down or needs to come down, it sends this message over one of the other links in the link group.
クライアントまたはサーバーは、QPまたはSMC-Rリンクがダウンしたか、ダウンする必要があることを検出すると、リンクグループ内の他のリンクの1つを介してこのメッセージを送信します。
When the DELETE LINK is sent from the client, it only serves as a notification, and the client expects the server to respond by sending a DELETE LINK request. To avoid races, only the server will initiate the actual DELETE LINK request and response sequence that results from notification from the client.
DELETE LINKがクライアントから送信されると、それは通知としてのみ機能し、クライアントはサーバーがDELETE LINK要求を送信して応答することを期待します。競合を回避するために、サーバーからのみ実際のDELETE LINK要求と、クライアントからの通知に起因する応答シーケンスが開始されます。
The server can also initiate the DELETE LINK without notification from the client if it detects an error or if orderly link termination was initiated.
サーバーは、エラーを検出した場合、または通常のリンク終了が開始された場合、クライアントからの通知なしにDELETE LINKを開始することもできます。
The client may also request termination of the entire link group, and the server may terminate the entire link group using this message.
クライアントはリンクグループ全体の終了も要求でき、サーバーはこのメッセージを使用してリンクグループ全体を終了できます。
The contents of the DELETE LINK LLC message are:
DELETE LINK LLCメッセージの内容は次のとおりです。
Type
タイプ
Type 4 indicates DELETE LINK.
タイプ4は、リンクの削除を示します。
Length
長さ
The DELETE LINK LLC message is 44 bytes long.
DELETE LINK LLCメッセージは44バイトの長さです。
R
R
Reply flag. When set, indicates that this is a DELETE LINK reply.
返信フラグ。設定されている場合、これがDELETE LINK応答であることを示します。
A
あ
"All" flag. When set, indicates that all links in the link group are to be terminated. This terminates the link group.
「すべて」のフラグ。設定されている場合、リンクグループ内のすべてのリンクが終了することを示します。これにより、リンクグループが終了します。
O
尾
Orderly flag. Indicates orderly termination. Orderly termination is generally caused by an operator command rather than an error on the link. When the client requests orderly termination, the server may wait to complete other work before terminating.
Orderly flag. Indicates orderly termination. Orderly termination is generally caused by an operator command rather than an error on the link. When the client requests orderly termination, the server may wait to complete other work before terminating.
LinkNum
LinkNum
The link number of the link to be terminated. If the A flag is set, this field has no meaning and is set to 0.
終了するリンクのリンク番号。 Aフラグが設定されている場合、このフィールドには意味がなく、0に設定されます。
RsnCode
RsnCode
The termination reason code. Currently defined reason codes are:
The termination reason code. Currently defined reason codes are:
Request reason codes:
リクエスト理由コード：
X'00010000' = Lost path
X'00010000 '=失われたパス
X'00020000' = Operator initiated termination
X'00020000 '=オペレーターが終了を開始
X'00030000' = Program initiated termination (link inactivity)
X'00030000 '=プログラムによって開始された終了（リンクが非アクティブ）
X'00040000' = LLC protocol violation
X'00040000 '= LLCプロトコル違反
X'00050000' = Asymmetric link no longer needed
X'00050000 '=非対称リンクは不要
Response reason code:
応答理由コード：
X'00100000' = Unknown link ID (no link)
X'00100000 '=不明なリンクID（リンクなし）
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 6 | Length = 44 | Reserved |R|0|Z|C|Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumTkns | New RMB RKey for this link (bytes 1-3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|ThisLink byte 4| |
+-+-+-+-+-+-+-+-+ -+
| New RMB virtual address for this link |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ -+
| |
+- Other link RMB specification or zeros -+
| |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+
| |
+- -+
| Other link RMB specification or zeros |
+- +-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 36: CONFIRM RKEY LLC Message Format
図36：CONFIRM RKEY LLCメッセージフォーマット
The CONFIRM RKEY flow can be sent at any time from either the client or the server, to inform the peer that an RMB has been created or deleted. The creator of a new RMB must inform its peer of the new RMB's RToken for all SMC-R links in the SMC-R link group.
CONFIRM RKEYフローは、クライアントまたはサーバーからいつでも送信でき、RMBが作成または削除されたことをピアに通知します。新しいRMBの作成者は、SMC-Rリンクグループ内のすべてのSMC-Rリンクについて、新しいRMBのRTokenをピアに通知する必要があります。
For RMB creation, the creator sends this message over the SMC-R link that the first TCP connection that uses the new RMB is using. This message contains the new RMB RToken for the SMC-R link over which the message is sent. It then lists the sender's SMC-R links in the link group paired with the new RToken for the new RMB for that link. This message can communicate the new RTokens for three QPs: the QP for the link over which this message is sent, and two others. If there are more than three links in the SMC-R link group, a CONFIRM RKEY CONTINUATION will be required.
RMB作成の場合、作成者は、新しいRMBを使用する最初のTCP接続が使用しているSMC-Rリンクを介してこのメッセージを送信します。このメッセージには、メッセージが送信されるSMC-Rリンクの新しいRMB RTokenが含まれています。次に、そのリンクの新しいRMBの新しいRTokenとペアになっているリンクグループ内の送信者のSMC-Rリンクを一覧表示します。このメッセージは、3つのQP（このメッセージが送信されるリンクのQPと他の2つ）の新しいRTokenを伝達できます。 SMC-Rリンクグループに4つ以上のリンクがある場合、CONFIRM RKEY CONTINUATIONが必要になります。
The peer responds by simply echoing the message with the response flag set. If the response is a negative response, the sender must recalculate the RToken set and start a new CONFIRM RKEY exchange from the beginning. The timing of this retry is controlled by the C flag, as described below.
ピアは、応答フラグを設定してメッセージをエコーするだけで応答します。応答が否定応答の場合、送信者はRTokenセットを再計算し、新しいCONFIRM RKEY交換を最初から開始する必要があります。この再試行のタイミングは、以下で説明するように、Cフラグによって制御されます。
The contents of the CONFIRM RKEY LLC message are:
CONFIRM RKEY LLCメッセージの内容は次のとおりです。
Type
タイプ
Type 6 indicates CONFIRM RKEY.
タイプ6はCONFIRM RKEYを示します。
Length
長さ
The CONFIRM RKEY LLC message is 44 bytes long.
CONFIRM RKEY LLCメッセージは44バイトの長さです。
R
R
Reply flag. When set, indicates that this is a CONFIRM RKEY reply.
返信フラグ。設定されている場合、これがCONFIRM RKEY応答であることを示します。
0
０
Reserved bit.
予約ビット。
Z
と
Negative response flag.
否定応答フラグ。
C
C
Configuration Retry bit. If this is a negative response and this flag is set, the originator should recalculate the RKey set and retry this exchange as soon as the current configuration change is completed. If this flag is not set on a negative response, the originator must wait for the next natural stimulus (for example, a new TCP connection started that requires a new RMB) before retrying.
構成再試行ビット。これが否定応答であり、このフラグが設定されている場合、発信者はRKeyセットを再計算し、現在の構成変更が完了したらすぐにこの交換を再試行する必要があります。このフラグが否定応答で設定されていない場合、発信者は次の自然な刺激（たとえば、新しいRMBを必要とする新しいTCP接続が開始される）を待ってから再試行する必要があります。
NumTkns
NumTkns
The number of other link/RToken pairs, including those provided in this message, to be communicated. Note that this value does not include the RToken for the link on which this message was sent (i.e., the maximum value is 2). If this value is 3 or less, this is the only message in the exchange. If this value is greater than 3, a CONFIRM RKEY CONTINUATION message will be required.
通信する他のリンク/ RTokenペアの数（このメッセージで提供されるものを含む）。この値には、このメッセージが送信されたリンクのRTokenが含まれていないことに注意してください（つまり、最大値は2です）。この値が3以下の場合、これは交換での唯一のメッセージです。この値が3より大きい場合、CONFIRM RKEY CONTINUATIONメッセージが必要になります。
Note: In this version of the architecture, eight is the maximum number of links supported in a link group.
注：このバージョンのアーキテクチャーでは、リンクグループでサポートされるリンクの最大数は8です。
New RMB RKey for this link
このリンクの新しいRMB RKey
The new RMB's RKey as assigned on the link over which this message is being sent.
The new RMB's RKey as assigned on the link over which this message is being sent.
New RMB virtual address for this link
このリンクの新しいRMB仮想アドレス
The new RMB's virtual address as assigned on the link over which this message is being sent.
The new RMB's virtual address as assigned on the link over which this message is being sent.
Other link RMB specification
その他リンクRMB仕様
The new RMB's specification on the other links in the link group, as shown in Figure 37.
The new RMB's specification on the other links in the link group, as shown in Figure 37.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link number | RMB's RKey for the specified link (bytes 1-3) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|New RKey byte 4| |
+-+-+-+-+-+-+-+-+ -+
| RMB's virtual address for the specified link |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+-+-+-+-+-+-+-+-+
Figure 37: Format of Link Number/RKey Pairs
図37：リンク番号/ RKeyペアのフォーマット
Link number
リンク番号
The link number for a link in the link group.
リンクグループ内のリンクのリンク番号。
RMB's RKey for the specified link
指定されたリンクのRMBのRKey
The RKey used to reach the RMB over the link whose number was specified in the Link number field.
「リンク番号」フィールドで番号が指定されたリンクを介してRMBに到達するために使用されたRKey。
RMB's virtual address for the specified link
指定されたリンクのRMBの仮想アドレス
The virtual address used to reach the RMB over the link whose number was specified in the Link number field.
「リンク番号」フィールドで番号が指定されたリンクを介してRMBに到達するために使用される仮想アドレス。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 8 | Length = 44 | Reserved |R|0|Z| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NumTknsLeft | |
+-+-+-+-+-+-+-+-+ -+
| |
+- Other link RMB specification -+
| |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+ -+
| |
+- Other link RMB specification or zeros -+
| |
+- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+
| |
+- -+
| Other link RMB specification or zeros |
+- +-+-+-+-+-+-+-+-+
| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 38: CONFIRM RKEY CONTINUATION LLC Message Format
図38：CONFIRM RKEY CONTINUATION LLCメッセージフォーマット
The CONFIRM RKEY CONTINUATION LLC message is used to communicate any additional RMB RTokens that did not fit into the CONFIRM RKEY message. Each of these messages can hold up to three RMB RTokens. The NumTknsLeft field indicates how many RMB RTokens are to be communicated, including the ones in this message. If the value is 3 or less, this is the last message of the group. If the value is 4 or higher, additional CONFIRM RKEY CONTINUATION messages will follow, and the NumTknsLeft value will be a countdown until all are communicated.
CONFIRM RKEY CONTINUATION LLCメッセージは、CONFIRM RKEYメッセージに適合しなかった追加のRMB RTokenを通信するために使用されます。これらの各メッセージは、最大3つのRMB RTokenを保持できます。 NumTknsLeftフィールドは、このメッセージに含まれるものを含め、通信されるRMB RTokenの数を示します。値が3以下の場合、これはグループの最後のメッセージです。値が4以上の場合、追加のCONFIRM RKEY CONTINUATIONメッセージが続き、NumTknsLeft値はすべてが通知されるまでカウントダウンになります。
Like the CONFIRM RKEY message, the peer responds by echoing the message back with the reply flag set.
CONFIRM RKEYメッセージと同様に、ピアは応答フラグを設定してメッセージをエコーバックすることにより応答します。
The contents of the CONFIRM RKEY CONTINUATION LLC message are:
CONFIRM RKEY CONTINUATION LLCメッセージの内容は次のとおりです。
Type
タイプ
Type 8 indicates CONFIRM RKEY CONTINUATION.
タイプ8は、RKEY CONTINUATIONを確認することを示します。
Length
Length
The CONFIRM RKEY CONTINUATION LLC message is 44 bytes long.
CONFIRM RKEY CONTINUATION LLCメッセージは44バイトの長さです。
R
R
Reply flag. When set, indicates that this is a CONFIRM RKEY CONTINUATION reply.
返信フラグ。設定されている場合、これがCONFIRM RKEY CONTINUATION応答であることを示します。
0
０
Reserved bit.
予約ビット。
Z
と
Negative response flag.
Negative response flag.
NumTknsLeft
NumTknsLeft
The number of link/RToken pairs, including those provided in this message, that are remaining to be communicated. If this value is 3 or less, this is the last message in the exchange. If this value is greater than 3, another CONFIRM RKEY CONTINUATION message will be required. Note that in this version of the architecture, eight is the maximum number of links supported in a link group.
このメッセージで提供されたものを含め、通信するために残っているリンク/ RTokenペアの数。この値が3以下の場合、これは交換の最後のメッセージです。この値が3より大きい場合、別のCONFIRM RKEY CONTINUATIONメッセージが必要になります。このバージョンのアーキテクチャでは、リンクグループでサポートされるリンクの最大数は8です。
Other link RMB specification
その他リンクRMB仕様
The new RMB's specification on other links in the link group, as shown in Figure 37.
図37に示すように、リンクグループ内の他のリンクに関する新しいRMBの仕様。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 9 | Length = 44 | Reserved |R|0|Z| Rsrvd |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Count | Error Mask | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| First deleted RKey |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Second deleted RKey or zeros |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Third deleted RKey or zeros |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fourth deleted RKey or zeros |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Fifth deleted RKey or zeros |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sixth deleted RKey or zeros |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seventh deleted RKey or zeros |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Eighth deleted RKey or zeros |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 39: DELETE RKEY LLC Message Format
図39：DELETE RKEY LLCメッセージフォーマット
The DELETE RKEY flow can be sent at any time from either the client or the server, to inform the peer that one or more RMBs have been deleted. Because the peer already knows every RMB's RKey on each link in the link group, this message only specifies one RKey for each RMB being deleted. The RKey provided for each deleted RMB will be its RKey as known on the SMC-R link over which this message is sent.
DELETE RKEYフローは、クライアントまたはサーバーからいつでも送信でき、1つ以上のRMBが削除されたことをピアに通知します。ピアはリンクグループ内の各リンク上のすべてのRMBのRKeyをすでに知っているため、このメッセージは削除される各RMBに対して1つのRKeyのみを指定します。削除された各RMBに提供されるRKeyは、このメッセージが送信されるSMC-Rリンクで知られているRKeyになります。
It is not necessary to provide the entire RToken. The RKey alone is sufficient for identifying an existing RMB.
RToken全体を提供する必要はありません。 RKeyだけで既存のRMBを識別できます。
The peer responds by simply echoing the message with the response flag set. If the peer did not recognize an RKey, a negative response flag will be set; however, no aggressive recovery action beyond logging the error will be taken.
ピアは、応答フラグを設定してメッセージをエコーするだけで応答します。ピアがRKeyを認識しなかった場合、否定応答フラグが設定されます。ただし、エラーをログに記録する以外の積極的な回復アクションは実行されません。
The contents of the DELETE RKEY LLC message are:
DELETE RKEY LLCメッセージの内容は次のとおりです。
Type
Type
Type 9 indicates DELETE RKEY.
タイプ9はDELETE KEYを示します。
Length
長さ
The DELETE RKEY LLC message is 44 bytes long.
DELETE RKEY LLCメッセージは44バイトの長さです。
R
R
Reply flag. When set, indicates that this is a DELETE RKEY reply.
返信フラグ。設定されている場合、これがDELETE RKEY応答であることを示します。
0
０
Reserved bit.
予約ビット。
Z
Z
Negative response flag.
Negative response flag.
Count
カウント
Number of RMBs being deleted by this message. Maximum value is 8.
このメッセージによって削除されているRMBの数。最大値は8です。
Error Mask
エラーマスク
If this is a negative response, indicates which RMBs were not successfully deleted. Each bit corresponds to a listed RMB; for example, b'01010000' indicates that the second and fourth RKeys weren't successfully deleted.
これが否定的な応答である場合、どのRMBが正常に削除されなかったかを示します。各ビットはリストされたRMBに対応します。たとえば、b'01010000 'は、2番目と4番目のRKeyが正常に削除されなかったことを示します。
Deleted RKeys
削除されたRKey
A list of Count RKeys. Provided on the request flow and echoed back on the response flow. Each RKey is valid on the link over which this message is sent and represents a deleted RMB. Up to eight RMBs can be deleted in this message.
RKeyのカウントのリスト。要求フローで提供され、応答フローでエコーバックされます。各RKeyは、このメッセージが送信されるリンクで有効であり、削除されたRMBを表します。このメッセージでは、最大8つのRMBを削除できます。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 7 | Length = 44 | Reserved |R| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- User Data -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- -+
| Reserved |
+- -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 40: TEST LINK LLC Message Format
図40：TEST LINK LLCメッセージの形式
The TEST LINK request can be sent from either peer to the other on an existing SMC-R link at any time to test that the SMC-R link is active and healthy at the software level. A peer that receives a TEST LINK LLC message immediately sends back a TEST LINK reply, echoing back the user data. Refer also to Section 4.5.3 ("TCP Keepalive Processing").
TEST LINK要求は、SMC-Rリンクがアクティブでソフトウェアレベルで正常であることをテストするために、いつでも既存のSMC-Rリンクでいずれかのピアから他のピアに送信できます。 TEST LINK LLCメッセージを受信したピアは、TEST LINK応答をすぐに送り返し、ユーザーデータをエコーバックします。セクション4.5.3（「TCPキープアライブ処理」）も参照してください。
The contents of the TEST LINK LLC message are:
TEST LINK LLCメッセージの内容は次のとおりです。
Type
タイプ
Type 7 indicates TEST LINK.
タイプ7はTEST LINKを示します。
Length
長さ
The TEST LINK LLC message is 44 bytes long.
TEST LINK LLCメッセージの長さは44バイトです。
R
R
Reply flag. When set, indicates that this is a TEST LINK reply.
返信フラグ。設定されている場合、これがTEST LINK応答であることを示します。
User Data
ユーザーデータ
The receiver of this message echoes the sender's data back in a TEST LINK response LLC message.
このメッセージの受信者は、送信者のデータをTEST LINK応答LLCメッセージにエコーバックします。
The RMBE control data is communicated using Connection Data Control (CDC) messages, which use RoCE SendMsg, similar to LLC messages. Also, as with LLC messages, CDC messages are 44 bytes long to ensure that they can fit into private data areas of receive WQEs without requiring the receiver to post receive buffers.
RMBE制御データは、LLCメッセージと同様にRoCE SendMsgを使用する接続データ制御（CDC）メッセージを使用して通信されます。また、LLCメッセージと同様に、CDCメッセージは44バイトの長さで、受信側が受信バッファーをポストする必要なく、受信WQEのプライベートデータ領域に確実に収まるようにします。
Unlike LLC messages, this data is integral to the data path, so its processing must be prioritized and optimized similarly to other data path processing. While LLC messages may be processed on a slower path than data, these messages cannot be.
LLCメッセージとは異なり、このデータはデータパスに不可欠であるため、他のデータパス処理と同様に、その処理に優先順位を付けて最適化する必要があります。 LLCメッセージはデータよりも遅いパスで処理される可能性がありますが、これらのメッセージは処理できません。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = x'FE' | Length = 44 | Sequence number |
4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SMC-R alert token |
8 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Producer cursor wrap seqno |
12 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Producer Cursor |
16 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Consumer cursor wrap seqno |
20 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Consumer Cursor |
24 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|B|P|U|R|F|Rsrvd|D|C|A| Reserved |
28 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
32 +- -+
| |
36 +- Reserved -+
| |
40 +- -+
| |
44 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 41: Connection Data Control (CDC) Message Format
図41：接続データ制御（CDC）メッセージ形式
Type = x'FE'
タイプ= x'FE '
This type number has the two high-order bits turned on to enable processing to quickly distinguish it from an LLC message.
このタイプ番号は、2つの上位ビットがオンになっているため、処理でLLCメッセージとすばやく区別できます。
Length = 44
The length of inline data that does not require the posting of a receive buffer.
受信バッファーの通知を必要としないインラインデータの長さ。
Sequence number
シーケンス番号
A 2-byte unsigned integer that represents a wrapping sequence number. The initial value is 1, and this value can wrap to 0. Incremented with every control message sent, except for the failover data validation message, and used to guard against processing an old control message out of sequence. Also used in failover data validation. In normal usage, if this number is less than the last received value, discard this message. If greater, process this message. Old control messages can be lost with no ill effect but cannot be processed after newer ones.
ラッピングシーケンス番号を表す2バイトの符号なし整数。初期値は1で、この値は0にラップできます。フェイルオーバーデータ検証メッセージを除くすべての制御メッセージが送信されるたびに増加し、古い制御メッセージの順序どおりの処理を防ぐために使用されます。フェイルオーバーデータの検証にも使用されます。通常の使用では、この数が最後に受信した値より小さい場合、このメッセージを破棄します。大きい場合は、このメッセージを処理してください。古い制御メッセージは悪影響を与えずに失われる可能性がありますが、新しいメッセージの後で処理することはできません。
If this is a failover validation CDC message (F flag set), then the receiver must verify that it has received and fully processed the RDMA write that was described by the CDC message with the sequence number in this message. If not, the TCP connection must be reset to guard against data loss. Details of this processing are provided in Section 4.6.1.
これがフェイルオーバー検証CDCメッセージ（Fフラグセット）の場合、レシーバーは、このメッセージにシーケンス番号が付いたCDCメッセージで記述されたRDMA書き込みを受信して完全に処理したことを確認する必要があります。そうでない場合は、データ損失を防ぐためにTCP接続をリセットする必要があります。この処理の詳細は、4.6.1項を参照してください。
SMC-R alert token
SMC-Rアラートトークン
The endpoint-assigned alert token that identifies to which TCP connection on the link group this control message refers.
この制御メッセージが参照するリンクグループのTCP接続を識別するエンドポイント割り当てのアラートトークン。
Producer cursor wrap seqno
プロデューサーカーソルラップシーケンス番号
A 2-byte unsigned integer that represents a wrapping counter incremented by the producer whenever the data written into this RMBE receive buffer causes a wrap (i.e., the producer cursor wraps). This is used by the receiver to determine when new data is available even though the cursors appear unchanged, such as when a full window size write is completed (producer cursor of this RMBE sent by peer = local consumer cursor) or in scenarios where the producer cursor sent for this RMBE < local consumer cursor.
このRMBE受信バッファーに書き込まれたデータがラップする（つまり、プロデューサーカーソルがラップする）たびにプロデューサーによって増分されるラッピングカウンターを表す2バイトの符号なし整数。これは、フルウィンドウサイズの書き込みが完了したとき（ピアによって送信されたこのRMBEのプロデューサーカーソル=ローカルコンシューマーカーソルなど）、またはプロデューサーがこのRMBEに対して送信されたカーソル<ローカルコンシューマカーソル。
Producer Cursor
プロデューサーカーソル
A 4-byte unsigned integer that is a wrapping offset into the RMBE data area. Points to the next byte of data to be written by the sender. Can advance up to the receiver's consumer cursor as known by the sender. When the urgent data present indicator is on, points 1 byte beyond the last byte of urgent data. When computing this cursor, the presence of the eye catcher in the RMBE data area must be accounted for. The first writable data location in the RMBE is at offset 4, so this cursor begins at 4 and wraps to 4.
RMBEデータ域への折り返しオフセットである4バイトの符号なし整数。送信者が書き込むデータの次のバイトを指します。送信者が知っている受信者のコンシューマーカーソルまで進むことができます。緊急データ存在インジケーターがオンの場合、緊急データの最後のバイトから1バイト先を指します。このカーソルを計算するときは、RMBEデータ領域にあるアイキャッチャーの存在を考慮する必要があります。 RMBEの最初の書き込み可能なデータの場所はオフセット4にあるため、このカーソルは4から始まり、4に戻ります。
Consumer cursor wrap seqno
コンシューマーカーソルラップシーケンス番号
A 2-byte unsigned integer that mirrors the value of the producer cursor wrap sequence number when the last read from this RMBE occurred. Used as an indicator of how far along the consumer is in reading data (i.e., processed last wrap point or not). The producer side can use this indicator to detect whether or not more data can be written to the partner in full window write scenarios (where the producer cursor = consumer cursor as known on the remote RMBE). In this scenario, if the consumer sequence number equals the local producer sequence number, the producer knows that more data can be written.
このRMBEからの最後の読み取りが発生したときのプロデューサーカーソルラップシーケンス番号の値を反映する2バイトの符号なし整数。コンシューマーがデータを読み取る距離を示す指標として使用されます（つまり、処理された最後のラップポイントかどうか）。プロデューサー側は、このインジケーターを使用して、フルウィンドウ書き込みシナリオ（プロデューサーカーソル=リモートRMBEで既知のコンシューマーカーソル）でパートナーにさらにデータを書き込むことができるかどうかを検出できます。このシナリオでは、コンシューマーシーケンス番号がローカルプロデューサーシーケンス番号と等しい場合、プロデューサーはより多くのデータを書き込むことができることを認識しています。
Consumer Cursor
消費者カーソル
A 4-byte unsigned integer that is a wrapping offset into the sender's RMBE data area. Points to the offset of the next byte of data to be consumed by the peer in its own RMBE. When computing this cursor, the presence of the eye catcher in the RMBE data area must be accounted for. The first writable data location in the RMBE is at offset 4, so this cursor begins at 4 and wraps to 4. The sender cannot write beyond this cursor into the peer's RMBE without causing data loss.
送信側のRMBEデータ域への折り返しオフセットである4バイトの符号なし整数。ピアが独自のRMBEで使用するデータの次のバイトのオフセットを指します。このカーソルを計算するときは、RMBEデータ領域にあるアイキャッチャーの存在を考慮する必要があります。 RMBEの最初の書き込み可能なデータの場所はオフセット4にあるため、このカーソルは4から始まり、4に折り返します。送信者は、データの損失を引き起こさずに、このカーソルを超えてピアのRMBEに書き込むことはできません。
B-bit
Bビット
Writer blocked indicator: Sender is blocked for writing. If this bit is set, sender will require explicit notification when receive buffer space is available.
書き込みをブロックしたインジケーター：送信者が書き込みをブロックされています。このビットが設定されている場合、受信バッファースペースが利用可能な場合、送信者は明示的な通知を必要とします。
P-bit
Pビット
Urgent data pending: Sender has urgent data pending for this connection.
保留中の緊急データ：送信者には、この接続で保留中の緊急データがあります。
U-bit
Uビット
Urgent data present: Indicates that urgent data is present in the RMBE data area, and the producer cursor points to 1 byte beyond the last byte of urgent data.
緊急データの存在：緊急データがRMBEデータ領域に存在し、プロデューサーカーソルが緊急データの最後のバイトを超えて1バイトを指していることを示します。
R-bit
Rビット
Request for consumer cursor update: Indicates that an immediate consumer cursor update is requested, regardless of whether or not one is warranted according to the window size optimization algorithm described in Section 4.5.1.
コンシューマカーソルの更新の要求：セクション4.5.1で説明されているウィンドウサイズ最適化アルゴリズムに従って保証されているかどうかに関係なく、コンシューマカーソルの即時更新が要求されていることを示します。
F-bit
F-bit
Failover validation indicator: Sent by a peer to guard against data loss during failover when the TCP connection is being moved to another SMC-R link in the link group. When this bit is set, the only other fields in the CDC message that are significant are the Type, Length, SMC-R alert token, and Sequence number fields. The receiver must validate that it has fully processed the RDMA write described by the previous CDC message bearing the same sequence number as this validation message. If it has, no further action is required. If it has not, the TCP connection must be reset. This processing is described in detail in Section 4.6.1.
フェイルオーバー検証インジケーター：TCP接続がリンクグループ内の別のSMC-Rリンクに移動されているときに、フェイルオーバー中のデータ損失を防ぐためにピアから送信されます。このビットが設定されている場合、重要なCDCメッセージのその他のフィールドは、タイプ、長さ、SMC-Rアラートトークン、およびシーケンス番号フィールドのみです。受信者は、この検証メッセージと同じシーケンス番号を持つ前のCDCメッセージによって記述されたRDMA書き込みを完全に処理したことを検証する必要があります。ある場合、それ以上のアクションは必要ありません。そうでない場合は、TCP接続をリセットする必要があります。この処理の詳細は、4.6.1項を参照してください。
D-bit
Dビット
Sending done indicator: Sent by a peer when it is done writing new data into the receiver's RMBE data area.
送信済みインジケータの送信：受信者のRMBEデータ領域への新しいデータの書き込みが完了すると、ピアによって送信されます。
C-bit
Cビット
PeerConnectionClosed indicator: Sent by a peer when it is completely done with this connection and will no longer be making any updates to the receiver's RMBE or sending any more control messages.
PeerConnectionClosedインジケーター：この接続で完全に完了し、受信者のRMBEを更新したり、制御メッセージを送信したりしなくなったときに、ピアによって送信されます。
A-bit
Aビット
Abnormal close indicator: Sent by a peer when the connection is abnormally terminated (for example, the TCP connection was reset). When sent, it indicates that the peer is completely done with this connection and will no longer be making any updates to this RMBE or sending any more control messages. It also indicates that the RMBE owner must flush any remaining data on this connection and generate an error return code to any outstanding socket APIs on this connection (same processing as receiving a RST segment on a TCP connection).
異常終了インジケーター：接続が異常終了した（例えば、TCP接続がリセットされた）ときにピアによって送信されます。送信されると、ピアがこの接続で完全に完了しており、このRMBEを更新したり、制御メッセージを送信したりしていないことを示しています。また、RMBE所有者がこの接続の残りのデータをフラッシュし、この接続の未処理のソケットAPIにエラー戻りコードを生成する必要があることも示しています（TCP接続でRSTセグメントを受信するのと同じ処理）。
A key design goal for SMC-R is to require no application changes for exploitation. It is confined to socket applications using stream (i.e., TCP) sockets over IPv4 or IPv6. By virtue of the fact that the switch to the SMC-R protocol occurs after a TCP connection is established, no changes are required in a socket address family or in the IP addresses and ports that the socket applications are using. Existing socket APIs that allow applications to retrieve local and remote socket address structures for an established TCP connection (for example, getsockname() and getpeername()) will continue to function as they have before. Existing DNS setup and APIs for resolving hostnames to IP addresses and vice versa also continue to function without any changes. In general, all of the usual socket APIs that are used for TCP communications (send APIs, recv APIs, etc.) will continue to function as they do today, even if SMC-R is used as the underlying protocol.
SMC-Rの主要な設計目標は、悪用のためにアプリケーションを変更する必要がないことです。これは、IPv4またはIPv6を介してストリーム（つまり、TCP）ソケットを使用するソケットアプリケーションに限定されます。 TCP接続の確立後にSMC-Rプロトコルへの切り替えが行われるため、ソケットアドレスファミリ、またはソケットアプリケーションが使用しているIPアドレスとポートを変更する必要はありません。アプリケーションが確立されたTCP接続のローカルおよびリモートソケットアドレス構造を取得できるようにする既存のソケットAPI（たとえば、getsockname()およびgetpeername()）は、以前と同様に機能し続けます。ホスト名をIPアドレスに、またはその逆に解決するための既存のDNSセットアップとAPIも、変更せずに機能し続けます。一般に、TCP通信に使用されるすべての通常のソケットAPI（送信API、recv APIなど）は、SMC-Rが基本プロトコルとして使用されている場合でも、現在と同様に機能し続けます。
Each SMC-R-enabled implementation does, however, need to pay special attention to any socket APIs that have a reliance on the underlying TCP and IP protocols and also ensure that their behavior in an SMC-R environment is reasonable and minimizes impact on the application. While the basic socket API set is fairly similar across different operating systems, there is more variability when it comes to advanced socket API options. Each implementation needs to perform a detailed analysis of its API options, any possible impact that SMC-R may have, and any resultant implications. As part of that step, a discussion or review with other implementations supporting SMC-R would be useful to ensure consistent implementation.
ただし、SMC-R対応の各実装では、基盤となるTCPおよびIPプロトコルに依存するソケットAPIに特別な注意を払い、SMC-R環境での動作が合理的で、応用。基本的なソケットAPIセットはさまざまなオペレーティングシステム間でかなり似ていますが、高度なソケットAPIオプションに関しては、より多様性があります。各実装では、APIオプション、SMC-Rが及ぼす可能性のある影響、および結果として生じる影響の詳細な分析を実行する必要があります。そのステップの一部として、SMC-Rをサポートする他の実装とのディスカッションまたはレビューは、一貫した実装を保証するのに役立ちます。
These APIs allow socket applications to manipulate socket, transport (TCP/UDP), and IP-level options associated with a given socket. Typically, a platform restricts the number of IP options available to stream (TCP) socket applications, given their connection-oriented nature. The general guideline here is to continue processing these APIs in a manner that allows for application compatibility. Some options will be relevant to the SMC-R protocol and will require special processing "under the covers". For example, the ability to manipulate TCP send and receive buffer sizes is still valid for SMC-R. However, other options may have no meaning for SMC-R. For example, if an application enabled the TCP_NODELAY socket option to disable Nagle's algorithm, it should have no real effect on SMC-R communications, as there is no notion of Nagle's algorithm with this new protocol. But the implementation must accept the TCP_NODELAY option as it does today and save it so that it can be later extracted via getsockopt() processing. Note that any TCP or IP-level options will still have an effect on any TCP/IP packets flowing for an SMC-R connection (i.e., as part of TCP/IP connection establishment and TCP/IP connection termination packet flows).
これらのAPIにより、ソケットアプリケーションは、ソケット、トランスポート（TCP / UDP）、および特定のソケットに関連付けられたIPレベルのオプションを操作できます。通常、プラットフォームは、接続指向の性質を前提として、ストリーム（TCP）ソケットアプリケーションに使用できるIPオプションの数を制限します。ここでの一般的なガイドラインは、アプリケーションの互換性を可能にする方法でこれらのAPIの処理を継続することです。一部のオプションはSMC-Rプロトコルに関連し、「カバーの下」で特別な処理が必要になります。たとえば、TCPの送受信バッファーサイズを操作する機能は、SMC-Rでも引き続き有効です。ただし、他のオプションはSMC-Rには意味がない場合があります。たとえば、アプリケーションがTCP_NODELAYソケットオプションを有効にしてNagleのアルゴリズムを無効にした場合、この新しいプロトコルではNagleのアルゴリズムの概念がないため、SMC-R通信に実際の影響はありません。しかし、実装は、今日と同じようにTCP_NODELAYオプションを受け入れ、後でgetsockopt()処理によって抽出できるように保存する必要があります。 TCPまたはIPレベルのオプションは、SMC-R接続に流れるTCP / IPパケットに影響を与えることに注意してください（つまり、TCP / IP接続確立およびTCP / IP接続終了パケットフローの一部として）。
Under the covers, manipulation of the TCP options will also include the SMC-layer setting, as well as reading the SMC-R experimental option before and after completion of the three-way TCP handshake.
内部では、TCPオプションの操作には、SMCレイヤー設定、および3ウェイTCPハンドシェイクの完了前後のSMC-R実験オプションの読み取りも含まれます。
This section discusses error scenarios for setting up and managing SMC-R links.
このセクションでは、SMC-Rリンクを設定および管理するためのエラーシナリオについて説明します。
A peer to the SMC-R CLC negotiation can send an SMC Decline in lieu of any expected CLC message to decline SMC and force the TCP connection back to the IP fabric. There can be several reasons for an SMC Decline during the CLC negotiation, including the following:
SMC-R CLCネゴシエーションのピアは、SMCを拒否し、TCP接続をIPファブリックに強制的に戻すために、予想されるCLCメッセージの代わりにSMC拒否を送信できます。以下を含む、CLCネゴシエーション中にSMCが拒否されるいくつかの理由が考えられます。
o RNIC went down
o RNICがダウンした
o SMC-R forbidden by local policy
o ローカルポリシーによりSMC-Rが禁止されています
o subnet (IPv4) or prefix (IPv6) doesn't match
o サブネット（IPv4）またはプレフィックス（IPv6）が一致しません
o lack of resources to perform SMC-R
o SMC-Rを実行するためのリソースの不足
In all cases, when an SMC Decline is sent in lieu of an expected CLC message, no confirmation is required, and the TCP connection immediately falls back to using the IP fabric.
すべての場合において、予想されるCLCメッセージの代わりにSMC拒否が送信されると、確認は不要であり、TCP接続はすぐにIPファブリックの使用にフォールバックします。
To prevent ambiguity between CLC messages and application data, an SMC Decline cannot "chase" another CLC message. An SMC Decline can only be sent in lieu of an expected CLC message. For example, if the client sends an SMC Proposal and then its RNIC goes down, it must wait for the SMC Accept from the server and then reply to the SMC Accept with an SMC Decline.
CLCメッセージとアプリケーションデータのあいまいさを防ぐために、SMC拒否は別のCLCメッセージを「追跡」することはできません。 SMC拒否は、予期されるCLCメッセージの代わりにのみ送信できます。たとえば、クライアントがSMCプロポーザルを送信し、そのRNICがダウンした場合、クライアントはサーバーからのSMC受け入れを待機し、SMC拒否でSMC受け入れに応答する必要があります。
This "no chase" rule means that if this TCP connection is not a first contact between RoCE peers, a server cannot send an SMC Decline after sending an SMC Accept -- it can only either break the TCP connection or fail over if a problem arises in the RoCE fabric after it has sent the SMC Accept. Similarly, once the client sends an SMC Confirm on a TCP connection that isn't a first contact, it is committed to SMC-R for this TCP connection and cannot fall back to IP.
この「追跡なし」ルールは、このTCP接続がRoCEピア間の最初の連絡でない場合、サーバーはSMC Acceptを送信した後にSMC Declineを送信できないことを意味します。問題が発生した場合にのみ、TCP接続を切断するか、フェイルオーバーできます。 SMC Acceptを送信した後のRoCEファブリック内。同様に、クライアントが最初の連絡先ではないTCP接続でSMC確認を送信すると、このTCP接続のSMC-Rにコミットされ、IPにフォールバックできなくなります。
For a TCP connection that represents a first contact between RoCE pairs, it is possible for SMC to fall back to IP during the LLC negotiation. This is possible until the first contact SMC-R link is confirmed. For example, see Figure 42. After a first contact SMC-R link is confirmed, fallback to IP is no longer possible. This translates to the following rule: a first contact peer can send an SMC Decline at any time during LLC negotiation until it has successfully sent its CONFIRM LINK (request or response) flow. After that point, it cannot fall back to IP.
RoCEペア間の最初の接続を表すTCP接続の場合、LLCネゴシエーション中にSMCがIPにフォールバックする可能性があります。これは、最初の接触SMC-Rリンクが確認されるまで可能です。たとえば、図42を参照してください。最初の接続SMC-Rリンクが確認されると、IPへのフォールバックはできなくなります。これは次のルールに変換されます。最初の連絡先ピアは、LLCネゴシエーション中にCONFIRM LINK（要求または応答）フローが正常に送信されるまで、SMC拒否をいつでも送信できます。それ以降は、IPにフォールバックできません。
Host X -- Server Host Y -- Client
+-------------------+ +-------------------+
| Peer ID = PS1 | | Peer ID = PC1 |
| +------+ +------+ |
| QP 8 |RNIC 1| SMC-R Link 1 |RNIC 2| QP 64 |
| RKey X | |MAC MA|<-------------------->|MAC MB| | |
| | |GID GA| attempted setup |GID GB| | RKey Y2|
| \/ +------+ +------+ \/ |
|+--------+ | | +--------+ |
|| RMB | | | | RMB | |
|+--------+ | | +--------+ |
| /\ +------+ +------+ /\ |
| | |RNIC 3| |RNIC 4| | RKey W2|
| | |MAC MC| |MAC MD| | |
| QP 9 |GID GC| |GID GD| QP 65 |
| +------+ +------+ |
+-------------------+ +-------------------+
SYN / SYN-ACK / ACK TCP three-way handshake with TCP option
<--------------------------------------------------------->
SMC Proposal / SMC Accept / SMC Confirm exchange
<-------------------------------------------------------->
CONFIRM LINK(request, Link 1)
.........................................................>
CONFIRM LINK(response, Link 1)
X...................................
:
: RoCE write failure
:.................................>
SMC Decline(PC1, reason code)
<--------------------------------------------------------
Connection data flows over IP fabric
<------------------------------------------------------->
Legend:
------------ TCP/IP and CLC flows
............ RoCE (LLC) flows
Figure 42: SMC Decline during LLC Negotiation
図42：LLC交渉中のSMCの減少
Because SMC-R does not support fallback to IP for a TCP connection that is already using RDMA, there are specific rules on when the SMC Decline CLC message, which signals a fallback to IP because of an error or problem with the RoCE fabric, can be sent during TCP connection setup. There is a "point of no return" after which a connection cannot fall back to IP, and RoCE errors that occur after this point require the connection to be broken with a RST flow in the IP fabric.
SMC-Rは、すでにRDMAを使用しているTCP接続のIPへのフォールバックをサポートしていないため、RoCEファブリックのエラーまたは問題が原因でIPへのフォールバックを通知するSMC拒否CLCメッセージがいつ送信できるかについて、特定のルールがあります。 TCP接続のセットアップ中に送信されます。接続がIPにフォールバックできない「ポイントオブノーリターン」があり、このポイントの後に発生するRoCEエラーでは、IPファブリックのRSTフローで接続を切断する必要があります。
For a first contact, that point of no return is after the ADD LINK LLC message has been successfully sent for the second SMC-R link. Specifically, the server cannot fall back to IP after receiving either (1) a positive write completion indication for the ADD LINK request or (2) the ADD LINK response from the client, whichever comes first. The client cannot fall back to IP after sending a negative ADD LINK response, receiving a positive write complete on a positive ADD LINK response, or receiving a CONFIRM LINK for the second SMC-R link from the server, whichever comes first.
最初の連絡先の場合、2番目のSMC-Rリンクに対してADD LINK LLCメッセージが正常に送信された後が戻りません。具体的には、サーバーは、（1）ADD LINK要求の肯定的な書き込み完了の指示または（2）クライアントからのADD LINK応答のいずれか先に受信した後、IPにフォールバックできません。クライアントは、負のADD LINK応答を送信した後、正のADD LINK応答で正の書き込み完了を受信した後、またはサーバーから2番目のSMC-RリンクのCONFIRM LINKを受信した後に、IPにフォールバックできません。
For a subsequent contact, that point of no return is after the last send of the CLC negotiation completes. This, in combination with the rule that error "chasers" are not allowed during CLC negotiation, means that the server cannot send an SMC Decline after sending an SMC Accept, and the client cannot send an SMC Decline after sending an SMC Confirm.
後続の連絡先については、CLCネゴシエーションの最後の送信が完了した後で戻りません。これは、CLCネゴシエーション中にエラー「チェイサー」が許可されないというルールと組み合わせて、SMC Acceptを送信した後にサーバーがSMC Declineを送信できず、SMC Confirmを送信した後にクライアントがSMC Declineを送信できないことを意味します。
The SMC Accept CLC message contains a first contact flag that indicates to the client whether the server believes it is setting up a new link group or using an existing link group. This flag is used to detect an out-of-sync condition between the client and the server. The scenario for such a condition is as follows: there is a single existing SMC-R link between the peers. After the client sends the SMC Proposal CLC message, the existing SMC-R link between the client and the server fails. The client cannot chase the SMC Proposal CLC message with an SMC Decline CLC message in this case, because the client does not yet know that the server would have wanted to choose the SMC-R link that just crashed. The QP that failed recovers before the server returns its SMC Accept CLC message. This means that there is a QP but no SMC-R link. Since the server had not yet learned of the SMC-R link failure when it sent the SMC Accept CLC message, it attempts to reuse the SMC-R link that just failed. This means that the server would not set the first contact flag, indicating to the client that the server thinks it is reusing an SMC-R link. However, the client does not have an SMC-R link that matches the server's specification. Because the first contact flag is off, the client realizes it is out of sync with the server and sends an SMC Decline to cause the connection to fall back to IP.
SMC Accept CLCメッセージには、サーバーが新しいリンクグループをセットアップしているのか、それとも既存のリンクグループを使用しているのかをクライアントに示す最初の連絡フラグが含まれています。このフラグは、クライアントとサーバー間の非同期状態を検出するために使用されます。このような状況のシナリオは次のとおりです。ピア間に1つの既存のSMC-Rリンクがあります。クライアントがSMCプロポーザルCLCメッセージを送信した後、クライアントとサーバー間の既存のSMC-Rリンクは失敗します。この場合、クライアントはSMCプロポーザルCLCメッセージをSMC拒否CLCメッセージで追跡することはできません。これは、クライアントがサーバーがクラッシュしたSMC-Rリンクを選択したかったことをまだ認識していないためです。失敗したQPは、サーバーがSMC Accept CLCメッセージを返す前に回復します。これは、QPはあるがSMC-Rリンクがないことを意味します。サーバーは、SMC Accept CLCメッセージを送信したときにSMC-Rリンク障害をまだ認識していないため、障害が発生したばかりのSMC-Rリンクを再利用しようとします。これは、サーバーが最初の連絡フラグを設定しないことを意味し、サーバーがSMC-Rリンクを再利用しているとサーバーが判断したことをクライアントに示します。ただし、クライアントには、サーバーの仕様に一致するSMC-Rリンクがありません。最初の連絡フラグがオフであるため、クライアントはそれがサーバーと同期していないことを認識し、SMC拒否を送信して接続をIPにフォールバックさせます。
Because the SMC-R negotiation flows as TCP data, there are built-in timeouts and retransmits at the TCP layer for individual messages. Implementations also must protect the overall TCP/CLC handshake with a timer or timers to prevent connections from hanging indefinitely due to SMC-R processing. This can be done with individual timers for individual CLC messages or an overall timer for the entire exchange, which may include the TCP handshake and the CLC handshake under one timer or separate timers. This decision is implementation dependent.
SMC-RネゴシエーションはTCPデータとして流れるため、組み込みのタイムアウトがあり、個々のメッセージに対してTCP層で再送信されます。また、実装では、SMC-R処理が原因で接続が無期限にハングアップしないように、1つまたは複数のタイマーでTCP / CLCハンドシェイク全体を保護する必要があります。これは、個々のCLCメッセージの個々のタイマー、または交換全体の全体的なタイマーで行うことができます。これには、1つのタイマーまたは個別のタイマーでのTCPハンドシェイクとCLCハンドシェイクが含まれる場合があります。この決定は実装に依存します。
If the TCP and/or CLC handshakes time out, the TCP connection must be terminated as it would be in a legacy IP environment when connection setup doesn't complete in a timely manner. Because the CLC flows are TCP messages, if they cannot be sent and received in a timely fashion, the TCP connection is not healthy and would not work if fallback to IP were attempted.
TCPまたはCLCハンドシェイクがタイムアウトした場合、レガシーIP環境の場合と同様に、接続セットアップがタイムリーに完了しない場合、TCP接続を終了する必要があります。 CLCフローはTCPメッセージであるため、タイムリーに送受信できない場合、TCP接続は正常ではなく、IPへのフォールバックが試みられても機能しません。
Protocol errors occur during CLC negotiation when a message is received that is not expected. For example, a peer that is expecting a CLC message but instead receives application data has experienced a protocol error; this also indicates a likely software error, as the two sides are out of sync. When application data is expected, this data is not parsed to ensure that it's not a CLC message.
CLCネゴシエーション中に予期しないメッセージを受信すると、プロトコルエラーが発生します。たとえば、CLCメッセージを予期しているが、代わりにアプリケーションデータを受信するピアでプロトコルエラーが発生しました。これは、双方が同期していないため、ソフトウェアエラーの可能性も示しています。アプリケーションデータが必要な場合、このデータは解析されず、CLCメッセージではないことが確認されます。
When a peer is expecting a CLC negotiation message, any parsing error except a bad enumerated value in that message must be treated as application data. The CLC negotiation messages are designed with beginning and ending eye catchers to help verify that a CLC negotiation message is actually the expected message. If other parsing errors in an expected CLC message occur, such as incorrect length fields or incorrectly formatted fields, the message must be treated as application data.
ピアがCLCネゴシエーションメッセージを予期している場合、そのメッセージの不正な列挙値を除く解析エラーは、アプリケーションデータとして処理する必要があります。 CLCネゴシエーションメッセージは、CLCネゴシエーションメッセージが実際に期待されるメッセージであることを確認できるように、最初と最後のアイキャッチャーで設計されています。予期しないCLCメッセージで他の構文解析エラー（長さフィールドが正しくない、フィールドの形式が正しくないなど）が発生した場合、メッセージをアプリケーションデータとして扱う必要があります。
All protocol errors, with the exception of bad enumerated values, must result in termination of the TCP connection. No fallback to IP is allowed in the case of a protocol error, because if the protocols are out of sync, mismatched, or corrupted, then data and security integrity cannot be ensured.
不正な列挙値を除くすべてのプロトコルエラーは、TCP接続の終了を引き起こす必要があります。プロトコルエラーが発生した場合、IPへのフォールバックは許可されません。プロトコルが同期していない、不一致、または破損している場合、データとセキュリティの整合性を保証できないためです。
The exception to this rule is enumerated values -- for example, the QP MTU values on SMC Accept and SMC Confirm. If a reserved value is received, the proper error response is to send an SMC Decline and fall back to IP; this is because the use of a reserved enumerated value indicates that the other partner likely has additional support that the receiving partner does not have. This indicated mismatch of SMC-R capabilities is not an integrity problem but indicates that SMC-R cannot be used for this connection.
このルールの例外は列挙値です。たとえば、SMC AcceptおよびSMC ConfirmのQP MTU値です。予約値を受け取った場合、適切なエラー応答は、SMC拒否を送信してIPにフォールバックすることです。これは、予約済みの列挙値を使用すると、他のパートナーが受信側パートナーにはない追加のサポートを持っている可能性が高いことを示しているためです。このSMC-R機能の不一致は整合性の問題ではありませんが、この接続にSMC-Rを使用できないことを示しています。
Whenever a peer sends an LLC message to which a reply is expected, it sets a timer after the send posts to wait for the reply. An expected response may be a reply flavor of the LLC message (for example, a CONFIRM LINK reply) or a new LLC message (for example, an ADD LINK CONTINUATION expected from the server by the client if there are more RKeys to be communicated).
ピアが応答が予想されるLLCメッセージを送信するときはいつでも、送信ポストが応答を待つようにタイマーを設定します。予期される応答は、LLCメッセージの応答フレーバー（たとえば、CONFIRM LINK応答）または新しいLLCメッセージ（たとえば、通信するRKeyがまだある場合にサーバーがクライアントから予期するADD LINK CONTINUATION）である可能性があります。 。
On LLC flows that are part of a first contact setup of a link group, the value of the timer is implementation dependent but should be long enough to allow the other peer to have a write complete timeout and 2-3 retransmits of an SMC Decline on the TCP fabric. For LLC flows that are maintaining the link group and are not part of a first contact setup of a link group, the timers may be shorter. Upon receipt of an expected reply, the timer is cancelled. If a timer pops without a reply having been received, the sender must initiate a recovery action.
リンクグループの最初のコンタクトセットアップの一部であるLLCフローでは、タイマーの値は実装に依存しますが、他のピアが書き込み完了タイムアウトを持ち、SMCの2〜3回の再送信を許可できるように十分長い必要があります。 TCPファブリック。リンクグループを維持していて、リンクグループの最初のコンタクトセットアップの一部ではないLLCフローの場合、タイマーは短くなる可能性があります。予期される応答を受信すると、タイマーはキャンセルされます。応答を受信せずにタイマーがポップした場合、送信者は回復アクションを開始する必要があります。
During first contact processing, failure of an LLC verification timer is a "should-not-occur" that indicates a problem with one of the endpoints; this is because if there is a "routine" failure in the RoCE fabric that causes an LLC verification send to fail, the sender will get a write completion failure and will then send an SMC Decline to the partner. The only time an LLC verification timer will expire on a first contact is when the sender thinks the send succeeded but it actually didn't. Because of the reliably connected nature of QP connections on the RoCE fabric, this indicates a problem with one of the peers, not with the RoCE fabric.
最初のコンタクト処理中、LLC検証タイマーの失敗は、エンドポイントの1つに問題があることを示す「発生してはならないこと」です。これは、LLC検証の送信が失敗する原因となるRoCEファブリックに「ルーチン」の障害がある場合、送信側は書き込み完了の障害を受け取り、SMC拒否をパートナーに送信するためです。最初の連絡先でLLC検証タイマーが期限切れになる唯一の時間は、送信者が送信が成功したと思ったが実際にはそうしなかったときです。 RoCEファブリック上のQP接続は確実に接続されているため、これは、RoCEファブリックではなく、ピアの1つに問題があることを示しています。
After the reliably connected queue pair for the first SMC-R link in a link group is set up on initial contact, the client sets a timer to wait for a RoCE verification message from the server that the QP is actually connected and usable. If the server experiences a failure sending its QP confirmation message, it will send an SMC Decline, which should arrive at the client before the client's verification timer expires. If the client's timer expires without receiving either an SMC Decline or a RoCE message confirmation from the server, there is a problem with either the server or the TCP fabric. In either case, the client must break the TCP connection and clean up the SMC-R link.
リンクグループ内の最初のSMC-Rリンクの信頼できる接続キューペアが最初の接続で設定された後、クライアントはタイマーを設定して、QPが実際に接続されて使用可能であるというサーバーからのRoCE検証メッセージを待機します。サーバーがQP確認メッセージの送信に失敗した場合、サーバーはSMC拒否を送信します。これは、クライアントの検証タイマーが期限切れになる前にクライアントに到着するはずです。サーバーからSMC拒否またはRoCEメッセージの確認を受信せずにクライアントのタイマーが期限切れになる場合は、サーバーまたはTCPファブリックのいずれかに問題があります。どちらの場合も、クライアントはTCP接続を切断し、SMC-Rリンクをクリーンアップする必要があります。
There are two scenarios in which the client's response to the QP verification message fails to reach the server. The main difference is whether or not the client has successfully completed the send of the CONFIRM LINK response.
QP検証メッセージに対するクライアントの応答がサーバーに到達できない2つのシナリオがあります。主な違いは、クライアントがCONFIRM LINK応答の送信を正常に完了したかどうかです。
In the normal case of a problem with the RoCE path, the client will learn of the failure by getting a write completion failure, before the server's timer expires. In this case, the client sends an SMC Decline CLC message to the server, and the TCP connection falls back to IP.
RoCEパスに問題がある通常のケースでは、サーバーのタイマーが期限切れになる前に、クライアントは書き込み完了エラーを取得することにより、エラーを認識します。この場合、クライアントはSMC Decline CLCメッセージをサーバーに送信し、TCP接続はIPにフォールバックします。
If the client's send of the confirmation message receives a positive return code but for some reason still does not reach the server, or the client's SMC Decline CLC message fails to reach the server after the client fails to send its RoCE confirmation message, then the server's timer will time out and the server must break the TCP connection by sending a RST. This is expected to be a very rare case, because if the client cannot send its CONFIRM LINK response LLC message, the client should get a negative return code and initiate fallback to IP. A client receiving a positive return code on a send that fails to reach the server should also be an extremely rare case.
クライアントの確認メッセージの送信が肯定的な戻りコードを受け取ったが、何らかの理由でサーバーに到達しない場合、またはクライアントがRoCE確認メッセージを送信できなかった後、クライアントのSMC Decline CLCメッセージがサーバーに到達しない場合、サーバーのタイマーがタイムアウトし、サーバーはRSTを送信してTCP接続を切断する必要があります。クライアントがCONFIRM LINK応答のLLCメッセージを送信できない場合、クライアントは負の戻りコードを受け取り、IPへのフォールバックを開始する必要があるため、これは非常にまれなケースであると予想されます。サーバーに到達できない送信で肯定的な戻りコードを受け取るクライアントも、非常にまれなケースです。
The following list describes recovery actions for LLC timeouts. A write completion failure or other indication of send failure for an LLC command is treated the same as a timeout.
次のリストは、LLCタイムアウトの回復アクションを示しています。 LLCコマンドの書き込み完了エラーまたは送信エラーのその他の表示は、タイムアウトと同じように扱われます。
LLC message: CONFIRM LINK from server (first contact, first link in the link group)
LLCメッセージ：CONFIRM LINK from server（first contact、first link in the link group）
Timer waits for: CONFIRM LINK reply from client.
タイマーの待機：クライアントからのリンクの確認応答。
Recovery action: Break the TCP connection by sending a RST, and clean up the link. The server should have received an SMC Decline from the client by now if the client had an LLC send failure.
回復処置：RSTを送信してTCP接続を切断し、リンクをクリーンアップします。クライアントがLLC送信に失敗した場合、サーバーは今までにクライアントからSMC拒否を受信しているはずです。
LLC message: CONFIRM LINK from server (first contact, second link in the link group)
LLCメッセージ：CONFIRM LINK from server（first contact、second link in the link group）
Timer waits for: CONFIRM LINK reply from client.
タイマーの待機：クライアントからのリンクの確認応答。
Recovery action: The second link was not successfully set up. Send a DELETE LINK to the client. Connection data cannot flow in the first link in the link group, until the reply to this DELETE LINK is received, to prevent the peers from being out of sync on the state of the link group.
回復処置：2番目のリンクは正常にセットアップされませんでした。 DELETE LINKをクライアントに送信します。このDELETE LINKへの応答を受信するまで、リンクグループの最初のリンクで接続データを流すことはできません。これにより、ピアがリンクグループの状態で同期されなくなります。
LLC message: CONFIRM LINK from server (not first contact)
LLCメッセージ：サーバーからのリンクを確認（最初の連絡先ではない）
Timer waits for: CONFIRM LINK reply from client.
タイマーの待機：クライアントからのリンクの確認応答。
Recovery action: Clean up the new link, and set a timer to retry. Send a DELETE LINK to the client, in case the client has a longer timer interval, so the client can stop waiting.
回復処置：新しいリンクをクリーンアップし、再試行するタイマーを設定します。クライアントのタイマー間隔が長い場合、クライアントが待機を停止できるように、DELETE LINKをクライアントに送信します。
LLC message: CONFIRM LINK reply from client (first contact)
LLCメッセージ：クライアントからのリンク確認応答（最初の連絡先）
Timer waits for: ADD LINK from server.
タイマーの待機：サーバーからのリンクの追加。
Recovery action: Clean up the SMC-R link, and break the TCP connection by sending a RST over the IP fabric. There is a problem with the server. If the server had a send failure, it should have sent an SMC Decline by now.
回復処置：SMC-Rリンクをクリーンアップし、IPファブリック経由でRSTを送信してTCP接続を切断します。サーバーに問題があります。サーバーで送信エラーが発生した場合は、今までにSMC拒否を送信する必要があります。
LLC message: ADD LINK from server (first contact)
LLCメッセージ：サーバーからのリンクを追加（最初の連絡先）
Timer waits for: ADD LINK reply from client.
タイマーは次を待機します：クライアントからのリンク追加応答。
Recovery action: Break the TCP connection with a RST, and clean up RoCE resources. The connection is past the point where the server can fall back to IP, and if the client had a send problem it should have sent an SMC Decline by now.
リカバリー処置：RSTとのTCP接続を切断し、RoCEリソースをクリーンアップします。接続は、サーバーがIPにフォールバックできるポイントを過ぎており、クライアントに送信問題があった場合、SMC拒否を今までに送信しているはずです。
LLC message: ADD LINK from server (not first contact)
LLCメッセージ：ADD LINK from server（not first contact）
Timer waits for: ADD LINK reply from client.
タイマーは次を待機します：クライアントからのリンク追加応答。
Recovery action: Clean up resources (QP, RKeys, etc.) for the new link, and treat the link over which the ADD LINK was sent as if it had failed. If there is another link available to resend the ADD LINK and the link group still needs another link, retry the ADD LINK over another link in the link group.
リカバリー・アクション：新しいリンクのリソース（QP、RKeysなど）をクリーンアップし、ADD LINKが送信されたリンクを失敗したかのように扱います。追加リンクの再送信に使用できる別のリンクがあり、リンクグループに別のリンクが必要な場合は、リンクグループ内の別のリンクで追加リンクを再試行してください。
LLC message: ADD LINK reply from client (and there are more RKeys to be communicated)
LLCメッセージ：クライアントからのADD LINK応答（通信するRKeyが他にもあります）
Timer waits for: ADD LINK CONTINUATION from server.
タイマーは次を待機します：ADD LINK CONTINUATION from server。
Recovery action: Treat the same as ADD LINK timer failure.
回復処置：ADD LINKタイマー障害と同じように扱います。
LLC message: ADD LINK reply or ADD LINK CONTINUATION reply from client (and there are no more RKeys to be communicated, for the second link in a first contact scenario)
LLCメッセージ：ADD LINK応答またはADD LINK CONTINUATION応答からのクライアント（そして、最初の連絡シナリオの2番目のリンクについて、通信するRKeyはもうありません）
Timer waits for: CONFIRM LINK from the server, over the new link.
タイマーは次を待機します：サーバーからのCONFIRM LINK、新しいリンク上。
Recovery action: The setup of the new link failed. Send a DELETE LINK to the server. Do not consider the socket opened to the client application until receiving confirmation from the server in the form of a DELETE LINK request for this link and sending the reply (to prevent the partners from being out of sync on the state of the link group).
回復処置：新しいリンクのセットアップに失敗しました。 DELETE LINKをサーバーに送信します。このリンクのDELETE LINKリクエストの形式でサーバーから確認を受け取り、返信を送信するまで（クライアントがリンクグループの状態で同期されないようにするため）、クライアントアプリケーションに対して開かれたソケットは考慮しないでください。
Set a timer to send another ADD LINK to the server if there is still an unused RNIC on the client side.
クライアント側に未使用のRNICがまだある場合は、タイマーを設定して別のADD LINKをサーバーに送信します。
LLC message: ADD LINK reply or ADD LINK CONTINUATION reply from client (and there are no more RKeys to be communicated)
LLCメッセージ：クライアントからのADD LINK応答またはADD LINK CONTINUATION応答（および通信するRKeyがありません）
Timer waits for: CONFIRM LINK from the server, over the new link.
タイマーは次を待機します：サーバーからのCONFIRM LINK、新しいリンク上。
Recovery action: Send a DELETE LINK to the server for the new link, then clean up any resource allocated for the new link and set a timer to send an ADD LINK to the server if there is still an unused RNIC on the client side. The setup of the new link failed, but the link over which the ADD LINK exchange occurred is unaffected.
回復アクション：DELETE LINKを新しいリンクのサーバーに送信し、新しいリンクに割り当てられているリソースをすべてクリーンアップし、クライアント側に未使用のRNICがまだある場合はタイマーを設定してADD LINKをサーバーに送信します。新しいリンクのセットアップは失敗しましたが、ADD LINK交換が行われたリンクは影響を受けません。
LLC message: ADD LINK CONTINUATION from server
LLCメッセージ：サーバーからのリンクの継続を追加
Timer waits for: ADD LINK CONTINUATION reply from client.
タイマーは次を待機します：ADD LINK CONTINUATIONクライアントからの応答。
Recovery action: Treat the same as ADD LINK timer failure.
回復処置：ADD LINKタイマー障害と同じように扱います。
LLC message: ADD LINK CONTINUATION reply from client (first contact, and RMB count fields indicate that the server owes more ADD LINK CONTINUATION messages)
LLCメッセージ：クライアントからのADD LINK CONTINUATION応答（最初の連絡先、およびRMBカウントフィールドは、サーバーがさらにADD LINK CONTINUATIONメッセージを借りていることを示します）
Timer waits for: ADD LINK CONTINUATION from server.
タイマーは次を待機します：ADD LINK CONTINUATION from server。
Recovery action: Clean up the SMC-R link, and break the TCP connection by sending a RST. There is a problem with the server.
回復処置：SMC-Rリンクをクリーンアップし、RSTを送信してTCP接続を切断します。サーバーに問題があります。
If the server had a send failure, it should have sent an SMC Decline by now.
サーバーで送信エラーが発生した場合は、今までにSMC拒否を送信する必要があります。
LLC message: ADD LINK CONTINUATION reply from client (not first contact, and RMB count fields indicate that the server owes more ADD LINK CONTINUATION messages)
LLCメッセージ：クライアントからのADD LINK CONTINUATION応答（最初の連絡先ではなく、RMBカウントフィールドは、サーバーが追加のADD LINK CONTINUATIONメッセージを借りていることを示します）
Timer waits for: ADD LINK CONTINUATION from server.
タイマーは次を待機します：ADD LINK CONTINUATION from server。
Recovery action: Treat as if client detected link failure on the link that the ADD LINK exchange is using. Send a DELETE LINK to the server over another active link if one exists; otherwise, clean up the link group.
回復処置：クライアントがADD LINK交換が使用しているリンクでリンク障害を検出した場合と同様に処理します。存在する場合は、DELETE LINKを別のアクティブなリンクを介してサーバーに送信します。それ以外の場合は、リンクグループをクリーンアップします。
LLC message: DELETE LINK from client
LLCメッセージ：DELETE LINK from client
Timer waits for: DELETE LINK request from server.
タイマーの待機：サーバーからのDELETE LINK要求。
Recovery action: If the scope of the request is to delete a single link, the surviving link over which the client sent the DELETE LINK is no longer usable either. If this is the last link in the link group, end TCP connections over the link group by sending RST packets. If there are other surviving links in the link group, resend over a surviving link. Also send a DELETE LINK over a surviving link for the link over which the client attempted to send the initial DELETE LINK message. If the scope of the request is to delete the entire link group, try resending on other links in the link group until success is achieved. If all sends fail, tear down the link group and any TCP connections that exist on it.
回復アクション：要求のスコープが単一のリンクの削除である場合、クライアントがDELETE LINKを送信した生き残ったリンクも使用できなくなります。これがリンクグループの最後のリンクである場合は、RSTパケットを送信して、リンクグループを介したTCP接続を終了します。リンクグループに他の残存リンクがある場合は、残存リンクを介して再送信します。また、クライアントが最初のDELETE LINKメッセージを送信しようとしたリンクの残存リンクを介してDELETE LINKを送信します。リクエストの範囲がリンクグループ全体を削除することである場合は、成功するまでリンクグループ内の他のリンクで再送信してみてください。すべての送信が失敗した場合は、リンクグループとそれに存在するすべてのTCP接続を破棄します。
LLC message: DELETE LINK from server (scope: entire link group)
LLCメッセージ：サーバーからのリンクの削除（スコープ：リンクグループ全体）
Timer waits for: Confirmation from the adapter that the message was delivered.
タイマーの待機：メッセージが配信されたアダプターからの確認。
Recovery action: Tear down the link group and any TCP connections that exist on it.
回復処置：リンクグループとその上に存在するすべてのTCP接続を破棄します。
LLC message: DELETE LINK from server (scope: single link)
LLCメッセージ：DELETE LINK from server（scope：single link）
Timer waits for: DELETE LINK reply from client.
タイマーの待機：クライアントからのDELETE LINK応答。
Recovery action: The link over which the server sent the DELETE LINK is no longer usable either. If this is the last link in the link group, end TCP connections over the link group by sending RST packets. If there are other surviving links in the link group, resend over a surviving link. Also send a DELETE LINK over a surviving link for the link over which the server attempted to send the initial DELETE LINK message. If the scope of the request is to delete the entire link group, try resending on other links in the link group until success is achieved. If all sends fail, tear down the link group and any TCP connections that exist on it.
回復処置：サーバーがDELETE LINKを送信したリンクも使用できなくなります。これがリンクグループの最後のリンクである場合は、RSTパケットを送信して、リンクグループを介したTCP接続を終了します。リンクグループに他の残存リンクがある場合は、残存リンクを介して再送信します。また、サーバーが最初のDELETE LINKメッセージを送信しようとしたリンクの残存リンクを介してDELETE LINKを送信します。リクエストの範囲がリンクグループ全体を削除することである場合は、成功するまでリンクグループ内の他のリンクで再送信してみてください。すべての送信が失敗した場合は、リンクグループとそれに存在するすべてのTCP接続を破棄します。
LLC message: CONFIRM RKEY from client
LLCメッセージ：クライアントからのRKEYの確認
Timer waits for: CONFIRM RKEY reply from server.
タイマーは次を待機します：サーバーからのRFI確認応答。
Recovery action: Perform normal client procedures for detection of failed link. The link over which the message was sent has failed.
回復処置：リンクの障害を検出するための通常のクライアント手順を実行します。メッセージが送信されたリンクが失敗しました。
LLC message: CONFIRM RKEY from server
LLCメッセージ：サーバーからのRKEYの確認
Timer waits for: CONFIRM RKEY reply from client.
タイマーの待機：クライアントからのRKEY応答の確認。
Recovery action: Perform normal server procedures for detection of failed link. The link over which the message was sent has failed.
回復処置：リンクの障害を検出するための通常のサーバー手順を実行します。メッセージが送信されたリンクが失敗しました。
LLC message: TEST LINK from client
LLCメッセージ：クライアントからのTEST LINK
Timer waits for: TEST LINK reply from server.
タイマーの待機：サーバーからのTEST LINK応答。
Recovery action: Perform normal client procedures for detection of failed link. The link over which the message was sent has failed.
回復処置：リンクの障害を検出するための通常のクライアント手順を実行します。メッセージが送信されたリンクが失敗しました。
LLC message: TEST LINK from server
LLCメッセージ：サーバーからのTEST LINK
Timer waits for: TEST LINK reply from client.
タイマーの待機：クライアントからのTEST LINK応答。
Recovery action: Perform normal server procedures for detection of failed link. The link over which the message was sent has failed.
回復処置：リンクの障害を検出するための通常のサーバー手順を実行します。メッセージが送信されたリンクが失敗しました。
The following list describes recovery actions for invalid LLC messages. These could be misformatted or contain out-of-sync data.
次のリストは、無効なLLCメッセージの回復アクションを示しています。これらは誤ったフォーマットであるか、非同期のデータを含んでいる可能性があります。
LLC message received: CONFIRM LINK from server
受信したLLCメッセージ：サーバーからのリンクを確認
What it indicates: Incorrect link information.
意味：リンク情報が正しくありません。
Recovery action: Protocol error. The link must be brought down by sending a DELETE LINK for the link over another link in the link group if one exists. If this is a first contact, fall back to IP by sending an SMC Decline to the server.
回復処置：プロトコルエラー。リンクが存在する場合は、リンクグループ内の別のリンクを介してそのリンクのDELETE LINKを送信して、リンクを停止する必要があります。これが最初の連絡先である場合は、SMC拒否をサーバーに送信してIPにフォールバックします。
LLC message received: ADD LINK
受信したLLCメッセージ：リンクを追加
What it indicates: Undefined enumerated MTU value.
意味：未定義の列挙MTU値。
Recovery action: Send a negative ADD LINK reply with reason code x'2'.
リカバリー処置：理由コードx'2 'の否定のADD LINK応答を送信します。
LLC message received: ADD LINK reply from client
受信したLLCメッセージ：クライアントからのADD LINK応答
What it indicates: Client-side link information that would result in a parallel link being set up.
内容：並列リンクが設定されることになるクライアント側のリンク情報。
Recovery action: Parallel links are not permitted. Delete the link by sending a DELETE LINK to the client over another link in the link group.
回復処置：並列リンクは許可されていません。リンクグループ内の別のリンクを介してクライアントにDELETE LINKを送信して、リンクを削除します。
LLC message received: Any link group command from the server, except DELETE LINK for the entire link group
受信したLLCメッセージ：サーバーからのリンクグループコマンド（リンクグループ全体のDELETE LINKを除く）
What it indicates: Client has sent a DELETE LINK for the link on which the message was received.
メッセージの意味：クライアントがメッセージを受信したリンクの削除リンクを送信しました。
Recovery action: Ignore the LLC message. Worst case: the server will time out. Best case: the DELETE LINK crosses with the command from the server, and the server realizes it failed.
回復処置：LLCメッセージを無視します。最悪の場合：サーバーがタイムアウトします。最良の場合：DELETE LINKはサーバーからのコマンドと交差し、サーバーはそれが失敗したことを認識します。
LLC message received: ADD LINK CONTINUATION from server or ADD LINK CONTINUATION reply from client
受信したLLCメッセージ：サーバーからのリンクの継続の追加またはクライアントからのリンクの継続の追加の応答
What it indicates: Number of RMBs provided doesn't match count given on initial ADD LINK or ADD LINK reply message.
説明：提供されたRMBの数が、最初のADD LINKまたはADD LINK応答メッセージで指定されたカウントと一致しません。
Recovery action: Protocol error. Treat as if detected link outage.
回復処置：プロトコルエラー。リンク障害が検出されたかのように扱います。
LLC message received: DELETE LINK from client
受信したLLCメッセージ：DELETE LINK from client
What it indicates: Link indicated doesn't exist.
意味：示されたリンクは存在しません。
Recovery action: If the link is in the process of being cleaned up, assume timing window and ignore message. Otherwise, send a DELETE LINK reply with reason code 1.
回復処置：リンクがクリーンアップ中の場合、タイミングウィンドウを想定してメッセージを無視します。それ以外の場合は、理由コード1のDELETE LINK応答を送信します。
LLC message received: DELETE LINK from server
受信したLLCメッセージ：サーバーからのリンクの削除
What it indicates: Link indicated doesn't exist.
意味：示されたリンクは存在しません。
Recovery action: Send a DELETE LINK reply with reason code 1.
リカバリー処置：理由コード1のDELETE LINK応答を送信します。
LLC message received: CONFIRM RKEY from either client or server
受信したLLCメッセージ：クライアントまたはサーバーからのRFIの確認
What it indicates: No RKey provided for one or more of the links in the link group.
内容：リンクグループ内の1つ以上のリンクにRKeyが提供されていません。
Recovery action: Treat as if detected failure of the link(s) for which no RKey was provided.
リカバリー処置：RKeyが提供されていないリンクの障害が検出されたかのように扱います。
LLC message received: DELETE RKEY
受信したLLCメッセージ：DELETE RKEY
What it indicates: Specified RKey doesn't exist.
意味：指定されたRKeyは存在しません。
Recovery action: Send a negative DELETE RKEY response.
回復処置：否定のDELETE RKEY応答を送信します。
LLC message received: TEST LINK reply
受信したLLCメッセージ：TEST LINK応答
What it indicates: User data doesn't match what was sent in the TEST LINK request.
意味：ユーザーデータがTEST LINKリクエストで送信されたものと一致しません。
Recovery action: Treat as if detected that the link has gone down. This is a protocol error.
回復処置：リンクがダウンしたことが検出されたかのように扱います。これはプロトコルエラーです。
LLC message received: Unknown LLC type with high-order bits of opcode equal to b'10'
受信したLLCメッセージ：オペコードの上位ビットがb'10 'に等しい不明なLLCタイプ
What it indicates: This is an optional LLC message that the receiver does not support.
意味：これは、受信者がサポートしないオプションのLLCメッセージです。
Recovery action: Ignore (silently discard) the message.
回復処置：メッセージを無視（サイレントに破棄）します。
LLC message received: Any unambiguously incorrect or out-of-sync LLC message
受信したLLCメッセージ：明確に正しくない、または同期していないLLCメッセージ
What it indicates: Link is out of sync.
意味：リンクが同期していません。
Recovery action: Treat as if detected that the link has gone down. Note that an unsupported or unknown LLC opcode whose two high-order bits are b'10' is not an error and must be silently discarded. Any other unknown or unsupported LLC opcode is an error.
回復処置：リンクがダウンしたことが検出されたかのように扱います。 2つの上位ビットがb'10 'であるサポートされていないか不明なLLCオペコードはエラーではないので、黙って破棄する必要があることに注意してください。その他の不明またはサポートされていないLLCオペコードはエラーです。
When there is any failure in setting up the second SMC-R link in an SMC-R link group, including confirmation timer expiration, the SMC-R link group is allowed to continue without available failover. However, this situation is extremely undesirable, and the server must endeavor to correct it as soon as it can.
確認タイマーの期限切れなど、SMC-Rリンクグループの2番目のSMC-Rリンクの設定に失敗した場合、SMC-Rリンクグループは、フェイルオーバーなしで続行できます。ただし、この状況は非常に望ましくないため、サーバーはできるだけ早く修正するように努める必要があります。
The server peer in the SMC-R link group must set a timer to drive it to retry setup of a failed additional SMC-R link. The server will immediately retry the SMC-R link setup when the first of the following events occurs:
SMC-Rリンクグループのサーバーピアは、タイマーを設定して、障害が発生した追加のSMC-Rリンクのセットアップを再試行するように駆動する必要があります。次のイベントの最初のイベントが発生すると、サーバーはすぐにSMC-Rリンクのセットアップを再試行します。
o The retry timer expires.
o 再試行タイマーが期限切れになります。
o A new RNIC becomes available to the server, on the same LAN as the SMC-R link group.
o 新しいRNICは、SMC-Rリンクグループと同じLAN上のサーバーで利用可能になります。
o An ADD LINK LLC request message is received from the client; this indicates the availability of a new RNIC on the client side.
o ADD LINK LLC要求メッセージがクライアントから受信されました。これは、クライアント側での新しいRNICの可用性を示します。
Authors' Addresses
著者のアドレス
Mike Fox IBM 3039 Cornwallis Rd. Research Triangle Park, NC 27709 United States
マイクフォックスIBM 3039コーンウォリスロードResearch Triangle Park、NC 27709アメリカ合衆国
Email: mjfox@us.ibm.com
Constantinos (Gus) Kassimis IBM 3039 Cornwallis Rd. Research Triangle Park, NC 27709 United States
コンスタンチノス（Gus）Kassimis IBM 3039 Cornwallis Rd。 Research Triangle Park、NC 27709アメリカ合衆国
Email: kassimis@us.ibm.com
Jerry Stevens IBM 3039 Cornwallis Rd. Research Triangle Park, NC 27709 United States
ジェリースティーブンスIBM 3039コーンウォリスロード。 Research Triangle Park、NC 27709アメリカ合衆国
Email: sjerry@us.ibm.com