Network Working Group J. Rosenberg Request for Comments: 4168 Cisco Systems Category: Standards Track H. Schulzrinne Columbia University G. Camarillo Ericsson October 2005 セッション開始プロトコル(SIP)のトランスポートとしての ストリーム制御送信プロトコル(SCTP) The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP) 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準ト ラックプロトコルを規定するものであり、改善のための議論や提案を依頼す るものである。標準化の段階や、プロトコルの位置付けについては、最新版 の"Internet Official Protocol Standards" (STD 1)を参照されたい。この 文書の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2005). 概要 本文書は、SIP (Session Initiation Protocol/セッション開始プロトコル) エンティティ間のトランスポートメカニズムとして、SCTP (Stream Control Transmission Protocol/ストリーム制御送信プロトコル)を使用するメカニズ ムを規定する。SCTPは、大量のメッセージを交換するSIPエンティティ(ゲー トウェイ、プロキシなど)間のトランスポートに、有効な機能をいくつか実 現する新規プロトコルである。SIPはトランスポートに依存していないため、 SCTPのサポートは比較的単純な処理であり、TCPのサポートとほぼ同様で ある。 Rosenberg, et al. Standards Track [Page 1] RFC 4168 SCTP as a Transport for SIP October 2005 目次 1. はじめに ....................................................... 2 2. 用語 ........................................................... 2 3. 考えられる利点 ................................................. 2 3.1. UDP上の利点 ............................................... 3 3.2. TCP上の利点 ............................................... 3 4. トランスポートパラメータ ....................................... 5 5. SCTPの用法 ..................................................... 5 5.1. SIPトランザクションをSCTPストリームにマッピング ........... 5 6. SIPサーバーの位置特定 ......................................... 6 7. セキュリティの考慮事項 ......................................... 7 8. IANA条項 ....................................................... 7 9. 参考文献 ....................................................... 7 9.1. 規範となる参考文献 ....................................... 7 9.2. 有益な参考文献 ........................................... 8 1. はじめに Stream Control Transmission Protocol (SCTP) [4]は、TCPやUDPと同じ層 にあるインターネット(またはイントラネット)用の新規トランスポートプロ トコルとして設計された。SCTPは、従来のSS7シグナリングメッセージを念 頭に置いたトランスポートで設計されている。著者たちは、このようなシグ ナリングのトランスポートをサポートするように設計された多数の機能が、 インターネット上で対話的セッションを開始し管理するときに使用するSIP (Session Initiation Protocol) [5]のトランスポートにも有効であると考 えた。 SIP自体はトランスポートに依存しないため、トランスポートが信頼できる 場合、信頼できない場合、メッセージトランスポートの場合、ストリームト ランスポートの場合でも実行される可能性がある。ただし、UDPとTCP上のト ランスポートについてのみプロシージャが定義されている。本文書は、SCTP 上のSIPのトランスポートを定義する。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119[1]に記載されるとお りに解釈されるべきである。 3. 考えられる利点 RFC 3257は、SCTP [10]の重要な利点の一部のみを提示している。本文書で は、このような利点の一部をまとめ、SIPに関連付ける方法を分析した(より 詳細な分析は[12]を参照)。 Rosenberg, et al. Standards Track [Page 2] RFC 4168 SCTP as a Transport for SIP October 2005 3.1. UDP上の利点 SIPトランスポートに関してSCTPがUDP上で持つ利点は、すべてTCPでも共有さ れる。以下に、TCPまたはSCTPなどのコネクション指向トランスポートプロ トコルが、UDPなどのコネクションレストランスポートプロトコルよりも優 れている一般的な利点について、リストを示す。 高速な再送信: SCTPはパケット損失を迅速に判断する。これは、SACKの用法 と、損失が検出されるときに通常よりもSACKメッセージが高速に送信さ れるメカニズムがあるためである。結果として、SIPがUDP上で実行され るとき(検出にかかる時間は最低でも500ミリ秒以上である)よりも遙かに 高速にSIPメッセージの損失を検出することができる。TCP SACKも存在 し、TCPにも高速な再送信オプションがあることに注意すること。この 場合、既存の接続上では、パケット損失の条件下で呼の確立時間が高速 になるため、これは非常に望ましい方法である。おそらく、これがSIPト ランスポート用SCTPが持つ最も重大な利点である。 輻輳制御: SCTPは、関連するデータ全体について複数制御を維持する。これ は、SIPの場合、2つのエンティティ間のメッセージの集約率を制御でき る、ということを指す。SIPがTCP上で実行されるとき、同じ利点が見込 まれる。ただし、UDP上で実行されると、SIPの輻輳制御の効率は低く なる。これは、すべてのトランザクション全体ではなく、(UDP再送間隔 という意味で計測した場合)輻輳状態をトランザクションごとのベースで 計算するためである。したがって、1つのTCP接続上でN個のメッセージを 送信する場合とは対照的に、輻輳制御のパフォーマンスは、開いているN 個の平行するTCP接続と似ている。 トランスポート層の断片化: SCTPとTCPには、トランスポート層の断片化機能 がある。SIPメッセージがMTUサイズよりも大きい場合、トランスポート 層で断片化される。UDPを使用するときに、断片化がIP層で発生する。IP の断片化によってパケット損失の可能性が高くなるため、NATとファイア ウォールが使用されているときにトラバーサル処理が困難になる。SIP メッセージのサイズが格段に大きくなる場合、この機能は重要になる。 3.2. TCP上の利点 これまでにUDPよりもSCTPとTCPの方が優れている利点を示した。ここでは、 TCPよりもSCTPが優れている利点について分析する。 ラインのヘッド: SCTPはメッセージベースである。対照的にTCPはストリーム ベースである。そのため、SCTPはトランスポート層で複数のシグナリン グメッセージを区別することができる。TCPのみがバイトを理解する。 シグナリングメッセージを構築する受信バイトの構成は、アプリケー ション層で実行される。したがって、TCPは、常に整列したストリームの Rosenberg, et al. Standards Track [Page 3] RFC 4168 SCTP as a Transport for SIP October 2005 バイトをアプリケーションに対して配信する。一方、SCTPは、シグナリ ングメッセージが到達すると直ちに、アプリケーションに配信すること ができる(順序がないサービスを使用する場合)。シグナリングメッセー ジの損失は、残りのメッセージの配信には影響がない。そのため、TCPが 持つラインのヘッドがブロックする問題が回避される。この問題は、複 数の高階層の接続が、1つのTCP接続内で多重化されるときに発生する。 SIPトランザクションは、アプリケーション層接続と考えることができ る。プロキシ間で実行される複数のトランザクションがある。1つのトラ ンザクションのメッセージ損失は、メッセージを送信する異なるトラン ザクションの機能に対して、悪影響を与えない。したがって、多数のト ランザクションが同時に発生しているエンティティでSIPが実行されてい る場合、SCTPには、TCP上のSIPよりもパフォーマンスが優れている可能 性がある(ただし、UDP上のSIPではない。UDP上のSIPは輻輳制御という観 点からは理想的ではない。上記を参照のこと)。 解析が容易: SCTPやUDPなど、メッセージベースのプロトコルが、TCPなどの ストリームベースのプロトコルよりも優れている1つの利点は、アプリ ケーション層でのメッセージ解析が容易なことである。 異なるメッセージ間に(一般的にContent-Lengthヘッダーを使用して)境 界を確立する必要はない。ただし、この利点はほとんど無視できる。 マルチホーミング: SCTP接続は、同じホスト上の複数のIPアドレスと関連付 けることができる。日付は常に1つのアドレス上で送信されるが、そのア ドレスに到達できなくなった場合、そのアドレスに送信されたデータは、 異なるアドレスに移行することができる。そのため、フォールトトレラ ンスが改善される。サーバーの1インターフェースが使用できなくなる ネットワークエラーが発生すると、サービスの運用が継続できなくなる。 SIPサーバーには、大量のフォールトトレランス要件がある可能性があ る。SIPはメッセージ指向であり、ストリーム指向ではないため、[5]で 定義された既存のSRV (サービス選択)プロシージャは、SIPがTCP上で実 行されているときでも、同じ目標を達成することができる、ということ に注意。実際のところ、SRVレコードによって、「connection」を別のホ ストにフェイルオーバーすることができる。SIPプロキシはステートレス に実行できるため、プライマリとバックアップ間でデータを同期するこ となく、フェイルオーバーを達成できる。したがって、SCTPのマルチ ホーミング機能によって最低限の利点が実現する。 注意が必要なのは、SIP用のSCTPが持つほとんどの利点は、損失の条件下で 発生するという点である。したがって、損失がゼロの条件では、SIPのSCTP トランスポートは、TCPトランスポートと同程度のパフォーマンスである。 セットアップ時とスループットに改善が見られる損失条件について、評価す る調査が必要である。 Rosenberg, et al. Standards Track [Page 4] RFC 4168 SCTP as a Transport for SIP October 2005 4. トランスポートパラメータ Viaヘッダーフィールドはトランスポートプロトコル識別子を伝達する。RFC 3261は、SCTP用に値「SCTP」を定義しているが、SCTP上のTLS用のトランス ポートパラメータの値は定義していない。RFC 3261で定義されている 値「TLS」は、TCP上のTLS用の値である。 本文書では、SCTP上のTLS[8]で送信されるリクエストに使用するViaヘッ ダーフィールドで、トランスポート部のために「TLS-SCTP」という値を定義 する。このパラメータについて更新したaugmented BNF (Backus-Naur Form) [2]を次に示す(このパラメータの元のBNFは、RFC 3261を参照のこと)。 transport = "UDP" / "TCP" / "TLS" / "SCTP" / "TLS-SCTP" / other-transport 次は、「SCTP」と「TLS-SCTP」を使用するViaヘッダーフィールドの例で ある。 Via: SIP/2.0/SCTP ws1234.example.com:5060 Via: SIP/2.0/TLS-SCTP ws1234.example.com:5060 5. SCTPの用法 SCTP上でリクエストを送信する規則は、TCPと同じである。唯一の差異は、 SCTP送信者は、リクエストを送信するために、関連付け内の特定のストリー ムを選択する必要があるということである(セクション5.1を参照)。 SIPメッセージ用に定義が必要なSCTP識別子はない、ということに注意。 したがって、SIPメッセージを送信するSCTP DATAチャンクのペイロードプロ トコル識別子は、ゼロに設定しなければならない[MUST]。 どちらのピアでも、継続的なSCTP接続を管理することは、SIPトランスポー ト層の役割である。送信者側では、コアまたはクライアント(またはサー バー)のトランザクションによって、リクエスト(応答)が生成され、トランス ポート層に渡される。トランスポートはリクエストをピアのトランザクショ ン層に送信する。ピアのトランザクション層には、受信リクエスト(または 応答)を適切な既存のサーバー(またはクライアント)トランザクションに配 信する役割がある。受信メッセージについて既存のサーバー(またはクライ アント)トランザクションがない場合、トランスポート層はリクエスト(また は応答)をコアに渡す。このとき、新規のサーバー(またはクライアント)ト ランザクションが構築される可能性もある。 5.1. SIPトランザクションをSCTPストリームにマッピング SIPトランザクションは、ラインのヘッド(HOL/Head Of the Line)のブロッ クを回避する方法で、SCTPストリームにマッピングする必要があるこの要件 を満たすマッピングを実行する方法は多様にあるが、本文書では最も単純な Rosenberg, et al. Standards Track [Page 5] RFC 4168 SCTP as a Transport for SIP October 2005 ものを選択した。SIPエンティティは、順序が指定されていないフラグセッ トでストリームゼロ上で、すべてのSIPメッセージを送信すべきである [SHOULD]。受信側では、SIPエンティティはどのストリームでもSIPメッセー ジを受信できるように準備しなければならない[MUST]。 これまでに、SCTPストリームIDを軽量のSIPトランザクションIDとして使 用することが提案された。SIPには、Viaエントリのbranchパラメータで トランザクションIDを提供できるようになったので(RFC 3261 [5]で 定義)、この提案は不要になった。このトランザクションIDは、前のSIP 仕様[9]でなくなったが、SIPトラフィックを逆多重化するときにSCTPス トリームIDを使用する必要はない。 多くの環境では、SIPにTLS [3]を利用する必要がある。たとえば、SIPS URI をルーティングする場合などである[5]。RFC 3436 [8]で定義されているよ うに、SCTP上で実行されているTLSは、SCTPの順序が指定されていない配信 サービスを使用してはならない[MUST NOT]。 さらに、トランスポート層間で余計な層を使用するSIPと、メッセージを順 序どおりに配信する必要があるSIPは、SCTPの順序が指定されていない配 信サービスを使用してはならない[MUST NOT]。 トランスポート層(TLSなど)からのメッセージを順序どおりに配信する必要が あるSIPアプリケーションは、同じSCTPストリーム上で同じSIPトランザク ションに所属するSIPメッセージを送信すべきである[SHOULD]。さらに、使 用できるストリームが十分にある限り、異なるSCTPストリーム上で異なる SIPトランザクションに所属するメッセージを送信すべきである[SHOULD]。 上記のメカニズムを使用する共通のシナリオは、SCTPをトランスポート プロトコルとして使用したTLS接続上のSIPトラフィックを交換する2つの プロキシから構成される。これは、2つのプロキシ間のすべてのSIPトラ ンザクションは、1つのSCTP関連付け内に確立することができる。 関連付けの両サイドがこの推奨に従う場合、リクエストが特定のストリーム 上で到達したときに、サーバーは異なるストリーム上で自由に応答を返すこ とができる、という点に注意。この方法では、両サイドは、送信方向で使用 できるストリームを管理する。このとき、特定のSIPメッセージを送信する ときにもう一方のサイドが選択するストリームの影響は受けない。これに よって、特定ストリームを中止するときに、不必要な混雑が回避される。 6. SIPサーバーの位置特定 リクエストを送信するときの主な問題は、関連付けを開くことができるよ うに、次ホップのサーバーがSCTPをサポートするかどうかを判断する処理で ある。SIPエンティティは、通常のSIPプロシージャに従って、SCTPをサポー トするサーバーを検出する[6]。 Rosenberg, et al. Standards Track [Page 6] RFC 4168 SCTP as a Transport for SIP October 2005 ただし、SCTPの最上位でTLSを使用するには、追加の定義が必要である。RFC 3263は、SCTP用にNAPTR (Naming Authority Pointer) [7]サービス値 「SIP+D2S」を定義しているが、SCTP上のTLS値については定義していない。 本文書では、SCTP上のTLSをサポートするサーバー用に、NAPTRサービス 値「SIPS+D2S」を定義する。 7. セキュリティの考慮事項 セクション5.1のアドバイスに従い、TLSがRFC 3261 [5]またはRFC 3263 [6] でTLSが必要な場合にSCTP上のTLS [8]を使用する場合、RFC 3261 [5]で指摘 されているセキュリティ問題は、SCTPによって悪化することはない。そのた め、TLS [3]とSCTPの上部でSIPを実行する場合、RFC 3436 [8]に記載されて いるメカニズムを使用しなければならない[MUST]。 8. IANA条項 本文書は、新規のNAPTRサービスフィールド値(SIPS+ D2S)を定義する。 IANAは、この値を「Registry for the SIP SRV Resource Record Services Field」に登録した。結果のエントリは以下のとおり。 サービスフィールド プロトコル 参考文献 -------------------- -------- --------- SIPS+D2S SCTP [RFC4168] 9. 参考文献 9.1. 規範となる参考文献 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [4] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000. [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [6] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002. Rosenberg, et al. Standards Track [Page 7] RFC 4168 SCTP as a Transport for SIP October 2005 [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002. [8] Jungmaier, A., Rescorla, E., and M. Tuexen, "Transport Layer Security over Stream Control Transmission Protocol", RFC 3436, December 2002. 9.2. 有益な参考文献 [9] Handley, M., Schulzrinne, H., Schooler, E., and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [10] Coene, L., "Stream Control Transmission Protocol Applicability Statement", RFC 3257, April 2002. [11] Camarillo, G., "The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)", BCP 99, RFC 3969, December 2004. [12] Camarillo, G., Schulrinne, H., and R. Kantola, "Evaluation of Transport Protocols for the Session Initiation Protocol", IEEE, Network vol. 17, no. 5, 2003. Rosenberg, et al. Standards Track [Page 8] RFC 4168 SCTP as a Transport for SIP October 2005 著者の連絡先 Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, NJ 07054 US Phone: +1 973 952-5000 EMail: jdrosen@cisco.com URI: http://www.jdrosen.net Henning Schulzrinne Columbia University M/S 0401 1214 Amsterdam Ave. New York, NY 10027-7003 US EMail: schulzrinne@cs.columbia.edu Gonzalo Camarillo Ericsson Hirsalantie 11 Jorvas 02420 Finland EMail: Gonzalo.Camarillo@ericsson.com Rosenberg, et al. Standards Track [Page 9] RFC 4168 SCTP as a Transport for SIP October 2005 完全な著作権表示 Copyright (C) The Internet Society (2005). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄 稿者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79 に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者 またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につい ては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能で ある。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 については、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供され ている。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2006年 ----------------------------------------------------------------------- Rosenberg, et al. Standards Track [Page 10]