5. UDP 上の DTLS 上の SCTP の考慮事項 (SCTP over DTLS over UDP Considerations)
WebRTC コンテキストにおける SCTP の重要な特性は以下の通りです。
- TCP フレンドリーな輻輳制御 (TCP-friendly Congestion Control) の使用。
- SRTP メディアストリームの輻輳制御との統合のための変更可能な輻輳制御。
- 複数の単方向ストリーム (Unidirectional Streams) のサポート。各ストリームは独自の順序付きメッセージ配信の概念を提供します。
- 順序付きおよび順序なしメッセージ配信のサポート。
- フラグメンテーションと再組み立てを提供することによる任意の大きなユーザーメッセージのサポート。
- PMTU 発見のサポート。
- 信頼性のあるまたは部分的に信頼性のあるメッセージ転送のサポート。
WebRTC データチャネルメカニズムは SCTP マルチホーミング (Multihoming) をサポートしません。SCTP 層は単純にシングルホームホスト上で動作しているかのように振る舞います。これは DTLS 層(接続指向の信頼性のないデータグラムサービス)が公開する抽象化です。
[RFC8261] で定義された DTLS 上の SCTP のカプセル化は、機密性、送信元認証、完全性保護のある転送を提供します。Interactive Connectivity Establishment (ICE) [RFC8445] と組み合わせた UDP 上の DTLS の使用により、IPv4 および IPv6 ベースのネットワークでのミドルボックストラバーサルが可能になります。
WebRTC のプロトコル階層を図 2 に示します。
+------+------+------+
| DCEP | UTF-8|Binary|
| | Data | Data |
+------+------+------+
| SCTP |
+----------------------------------+
| STUN | SRTP | DTLS |
+----------------------------------+
| ICE |
+----------------------------------+
| UDP1 | UDP2 | UDP3 | ... |
+----------------------------------+
図 2: WebRTC プロトコル層
ICE/UDP 層はセッション中に DTLS および SCTP 層と対話することなく IP アドレスの変更を処理できます。ただし、アドレスの変更が発生した場合は SCTP に通知すべきです (SHOULD)。この場合、SCTP はパス MTU を再テストし、輻輳状態を初期状態にリセットすべきです (SHOULD)。
受信した ICMP または ICMPv6 メッセージは、対応するアソシエーションを識別できないため、SCTP 層で処理できません。したがって、SCTP は [RFC4821] で説明されているように、[RFC4820] で指定されたプローブメッセージを使用して、ICMP または ICMPv6 に依存せずにパス MTU 発見を実行することをサポートしなければなりません (MUST)。IP 層の初期パス MTU は、IPv4 では 1200 バイトを超えるべきではなく (SHOULD NOT)、IPv6 では 1280 バイトを超えるべきではありません (SHOULD NOT)。
図 2 に示すプロトコルスタックを使用する場合、DTLS は完全な SCTP データパケットを保護するため、完全な SCTP データパケットの機密性、完全性、送信元認証を提供します。
SCTP はアソシエーション単位で輻輳制御を提供します。これは、単一の SCTP アソシエーション内のすべての SCTP ストリームが同じ輻輳ウィンドウを共有することを意味します。