Network Working Group M. Westerlund Request for Comments: 3890 Ericsson Category: Standards Track September 2004 セッション記述プロトコル(SDP)用の トランスポート非依存帯域幅修飾子 A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP) 本文書の位置付け 本文書は、インターネットコミュニティのためのインターネット標準化過程 プロトコルを規定し、改善のための議論や提案を依頼するものである。標準 化の段階や、プロトコルの位置付けについては、最新版の"Internet Official Protocol Standards" (STD 1)を参照されたい。本文書の配信は無 制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、セッション記述プロトコル(Session Description Protocol/SDP) のトランスポート非依存アプリケーション固有最大(Transport Independent Application Specific Maximum/TIAS)帯域幅修飾子(bandwidth modifier)を 定義する。この帯域幅修飾子はトランスポートのオーバーヘッドを含まず、 代わりに追加のパケットレート属性を定義する。トランスポート非依存の ビットレート値と最大パケットレートがあれば、それを利用して、実際に使 用するトランスポート上で実際のビットレートを計算することができる。 既存のSDP帯域幅修飾子とその値には、トランスポートレイヤーとIPレイヤー に必要な帯域幅が含まれる。SDPとともに、Session Announcement Protocol (SAP)、Session Initiation Protocol (SIP)、Real-Time Streaming Protocol (RTSP)などのプロトコルを使用する場合、および関連するホストの トランスポートのオーバーヘッドが異なる場合(たとえば、IPバージョンが異 なるため)、「含まれる低レイヤーの帯域幅」の解釈は明確ではない。 Westerlund Standards Track [Page 1] RFC 3890 Bandwidth Modifier for SDP September 2004 目次 1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. 帯域幅属性 . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. カンファレンス合計 . . . . . . . . . . . . . . . 3 1.1.2. アプリケーション固有最大値 . . . . . . . . . . . 3 1.1.3. RTCPレポート帯域幅 . . . . . . . . . . . . . . . 4 1.2. IPv6とIPv4 . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. 帯域幅の使用率を変えるその他のメカニズム . . . . . . . . 5 1.3.1. IPsec . . . . . . . . . . . . . . . . . . . . . 5 1.3.2. ヘッダーの圧縮 . . . . . . . . . . . . . . . . . 5 2. 定義 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.1. 用語集 . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2. 用語 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. 帯域幅シグナリングの問題 . . . . . . . . . . . . . . . . . . . 6 3.1. 使用するIPバージョン . . . . . . . . . . . . . . . . . . 6 3.2. 他のメカニズムの考慮 . . . . . . . . . . . . . . . . . . 7 3.3. 帯域幅値の変換 . . . . . . . . . . . . . . . . . . . . . 8 3.4. RTCPの問題 . . . . . . . . . . . . . . . . . . . . . . . 8 3.5. 今後の開発 . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. 問題のまとめ . . . . . . . . . . . . . . . . . . . . . . 9 4. 問題の範囲 . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. 要件 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. 解決策 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1. はじめに . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. TIAS帯域幅修飾子 . . . . . . . . . . . . . . . . . . . . 11 6.2.1. 用法 . . . . . . . . . . . . . . . . . . . . . . 11 6.2.2. 定義 . . . . . . . . . . . . . . . . . . . . . . 12 6.2.3. 用法の規則 . . . . . . . . . . . . . . . . . . . 13 6.3. パケットレートパラメータ . . . . . . . . . . . . . . . . 13 6.4. トランスポート依存値への変換 . . . . . . . . . . . . . . 14 6.5. RTCP帯域幅の導出 . . . . . . . . . . . . . . . . . . . . 15 6.5.1. この解決策の目的 . . . . . . . . . . . . . . . . 15 6.6. ABNF定義 . . . . . . . . . . . . . . . . . . . . . . . . 16 6.7. 例 . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7. プロトコルの相互作用 . . . . . . . . . . . . . . . . . . . . . 17 7.1. RTSP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.2. SIP . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.3. SAP . . . . . . . . . . . . . . . . . . . . . . . . . . 18 8. セキュリティの考慮事項 . . . . . . . . . . . . . . . . . . . . 18 9. IANA条項 . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. 規範となる参考文献 . . . . . . . . . . . . . . . . . . . 19 11.2. 有益な参考文献 . . . . . . . . . . . . . . . . . . . . . 19 12. 著者の連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . 21 13. 完全な著作権表記 . . . . . . . . . . . . . . . . . . . . . . . 22 Westerlund Standards Track [Page 2] RFC 3890 Bandwidth Modifier for SDP September 2004 1. はじめに 本仕様の構成内容を以下に示す。このセクションでは、SDP帯域幅修飾子に関 する一部の情報、およびトランスポートのオーバーヘッドに影響を及ぼすさ まざまなメカニズムについて示す。セクション3では、本仕様で解決されない 問題を含め、既知の問題について説明する。セクション4では、本仕様によっ て解決する問題の範囲を示す。セクション5では、問題の範囲に適用可能な要 件を示す。セクション6では、解決策を定義する。解決策とは、1つの新しい 帯域幅修飾子と1つの新しい最大パケットレート属性である。セクション7で は、SIP、RTSP、SAPに関するプロトコルの相互関係に注目する。セクション8 では、セキュリティの考慮事項について論ずる。残りのセクションは、必須 のIANA条項、謝辞、参考文献一覧、著者の連絡先、著作権およびIPR表記であ る。 現在、セッション記述プロトコル(Session Description Protocol/SDP) [1] は何種類かのアプリケーションに使用されている。元のアプリケーションは、 Session Announcement Protocol (SAP) [5]を使用してアナウンスするマルチ キャストセッションのセッション情報と構成である。SDPは、オファー/アン サーモデル[7]を使用するSession Initiation Protocol (SIP) [6]のメディ アネゴシエーションでも、重要なコンポーネントである。Real-Time Streaming Protocol (RTSP) [8]もSDPを利用して、マルチメディアプレゼン テーションを構成するメディアとコーデックをクライアントに宣言している。 1.1. 帯域幅属性 SDP [1]には帯域幅属性があり、その値が参照するビットレートのタイプを指 定するときに使用する修飾子がある。この属性の書式を以下に示す。 b=<修飾子>:<値> 現在、4つの修飾子が定義されており、異なる用途に使用されている。 1.1.1. カンファレンス合計 カンファレンス合計(Conference Total)を指定するには、修飾子「CT」を使 用する。 カンファレンス合計は、カンファレンスセッションが使用する予定の最大帯 域幅を示す。この目的は、このセッションがその他のセッション(RFC 2327 [1]の定義参照)と共存できるかどうかを決定することである。 1.1.2. アプリケーション固有最大値 アプリケーション固有最大帯域幅(Application Specific maximum bandwidth)は、修飾子「AS」で示す。この属性の解釈は、最大帯域幅に関す るアプリケーションの概念によって変わる。RTPアプリケーションの場合、こ の属性はRFC 3550 [4]に定義されているRTPセッション帯域幅である。セッ Westerlund Standards Track [Page 3] RFC 3890 Bandwidth Modifier for SDP September 2004 ション帯域幅には、IPレイヤーまでの低レイヤーを含め、RTPデータトラ フィックが消費する帯域幅が含まれる。したがって、ほとんどの場合、帯域 幅はRTPペイロード、RTPヘッダー、UDP、IPに関して計算される(RFC 2327 [1]の定義参照)。 1.1.3. RTCPレポート帯域幅 RFC 3556 [9]には2つの帯域幅修飾子が定義されている。この「RS」と「RR」 という修飾子は、アクティブなデータ送信者によるRTCPレポート、および他 の参加者(受信者)によるRTCPレポートに割り当てる帯域幅の合計をそれぞれ 定義している。 1.2. IPv6とIPv4 現在、IPバージョンには4 [14]と6 [13]の2つがあり、インターネットで並行 して使用されているため、問題が生じている。一方、移行のメカニズム候補 も複数ある。 - 通信を希望するノードは、IPバージョンを共有しなければならない。 通常、デュアルスタックノードを展開することでこれは達成される。たと えば、IPv4のみのホストは、IPv6のみのホストとは通信できない。 - プロトコルバージョンを共有しないノード間の通信が必要な場合、変換 またはプロキシ処理のメカニズムを使用する必要がある。この目的に対応 するメカニズムを規定する研究が進行中である。 ------------------ ---------------------- | IPv4 domain | | IPv6 Domain | | | ------------- | | | ---------- |-|Translator |-| ---------- | | |Server A| | | or proxy | | |Client B| | | ---------- | ------------- | ---------- | ------------------ ---------------------- 図1. IPv6およびIPv4アドレス間の変換またはプロキシ処理 - IPv6ノードがそれぞれIPv6を実行している異なるドメインに属してい るが、ドメイン間にIPv6接続がない場合、IPv4上でトンネル処理すること でこの問題を解決できる(図2参照)。基本的に、IPv6パケットは、各IPv6 ドメインのエッジにあるトンネル処理エンドポイント間で、IPv4パケット のペイロードとして送信される。IPv4ドメイン上に必要な帯域幅は、IPv6 ドメインとは異なる。ただし、通常はアプリケーションのエンドポイント はトンネル処理を実行しないため、このシナリオを一般的に考慮に入れる ことはできない。 Westerlund Standards Track [Page 4] RFC 3890 Bandwidth Modifier for SDP September 2004 --------------- --------------- --------------- | IPv6 domain | | IPv4 domain | | IPv6 Domain | | | |-------------| | | | ---------- |--||Tunnel ||--| ---------- | | |Server A| | |-------------| | |Client B| | | ---------- | | | | ---------- | --------------- --------------- --------------| 図2. IPv4ドメインを通過するトンネル処理 IPv4には20バイトの最小ヘッダーサイズがある。一方、IPv6ヘッダーの固定 部分は40バイトである。 ヘッダーサイズが異なるということは、2つのIPバージョンに必要なビット レートも異なることを意味する。この違いの重要度は、各パケットのパケッ トレートとペイロードサイズによって変わる。 1.3. 帯域幅の使用率を変えるその他のメカニズム メディアトランスポートより下層のレイヤーでオーバーヘッドを変える可能 性があるそメカニズムは、他にも複数ある。その一部をここで簡単に紹介す る。 1.3.1. IPsec IP Encapsulating Security Payload (ESP) [21]のアプリケーションを通し た機密保護、またはメディアストリームのIP認証ヘッダー(Authentication Header/AH) [20]を使用した完全性保護を実施するために、IPsec [19]をエン ドポイント間に使用することができる。ESPヘッダーとAHヘッダーを追加する ことで、各パケットサイズも増大する。 仮想プライベートネットワークを提供するために、エンドノードとプライ ベートネットワークのセキュリティゲートウェイ間でIPパケット全体をカプ セル化し、それによって、パケットストリームの機密保護、完全性、および 認証を確保する安全なトンネルが実現する。この場合、追加のIPおよびESP ヘッダーによって、パケットサイズが大幅に増大する。 1.3.2. ヘッダー圧縮 リンク上の実際のオーバーヘッドを警告するもう1つのメカニズムはヘッダー 圧縮である。ヘッダー圧縮では、パケットストリーム内にあるほとんどの ネットワークプロトコルのヘッダーフィールドが、静的または予測可能な値 を持つという事実を利用している。通常、圧縮はホップごと(つまり単一リン ク)でのみ実行される。ヘッダー圧縮を実行する通常の理由は、リンクの帯域 幅がかなり制限されているため、スループットで重大な利益が達成されるた めである。 Westerlund Standards Track [Page 5] RFC 3890 Bandwidth Modifier for SDP September 2004 ヘッダー圧縮規格は何種類かある。IPヘッダーのみを圧縮するために、RFC 2507 [10]がある。IP/UDP/RTPヘッダーを含むパケットを圧縮するために、 CRTP [11]が同時に作成された。最近では、Robust Header Compression (ROHC)ワークグループが、IP/UDP、IP/UDP/RTPなどの特定の組み合わせのプ ロトコルを圧縮するためのフレームワークとプロファイル[12]を開発してい る。 2. 定義 2.1. 用語集 ALG - アプリケーションレベルゲートウェイ(Application Level Gateway)。 bps - ビット/秒(bits per second)。 RTSP - リアルタイムストリーミングプロトコル(Real-Time Streaming Protocol)。[8]参照。 SDP - セッション記述プロトコル(Session Description Protocol)。 [1]参照。 SAP - セッションアナウンスメントプロトコル(Session Announcement Protocol)。[5]参照。 SIP - セッション開始プロトコル(Session Initiation Protocol)。 [6]参照。 TIAS - トランスポート非依存アプリケーション固有最大、帯域幅修飾子 (Transport Independent Application Specific maximum, a bandwidth modifier)。 2.2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、 「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、 「OPTIONAL」は、RFC 2119[3]のBCP 14に記載されるとおりに解釈されるべき である。 3. 帯域幅シグナリングの問題 アプリケーションがSDPを使用してそのアプリケーションに必要な帯域幅をシ グナリングしたい場合、低レイヤーの帯域幅値が含まれるため、いくつかの 問題が明らかになる。 3.1. 使用するIPバージョン SDPで帯域幅をシグナリングする場合、たとえば、RTPベースのアプリケー ションとして「b=AS:」を使用する場合、IPv4またはIPv6のオーバーヘッドが 計算されるかどうかは知ることができない。帯域幅値を計算するときに使用 されたプロトコルの指標は、「c=」接続アドレス行で示される。この行には、 データソースまたはシンクのマルチキャストグループアドレスまたはユニ キャストアドレスが含まれる。「c=」行のアドレスタイプは、帯域幅の計算 に使用されたものと同じタイプであると仮定できるが、この点を規定する文 書は存在していないと思われる。 RTSPによってSDPが伝送される場合、この問題はさらにあいまいになる。ユニ キャストオンデマンドストリーミングセッションの通常の用法は、接続デー タアドレスをnullアドレスに設定する方法である。このnullアドレスには、 Westerlund Standards Track [Page 6] RFC 3890 Bandwidth Modifier for SDP September 2004 指標として使用できるアドレスタイプがある。ただし、この点についても、 どの文書でも明確にされていない。 図1は、変換機に関するストリーミングサーバーAとクライアントB間の接続シ ナリオである。BがRTSP上でAからSDPを受信した場合、SDPの帯域幅値が表し ている内容をBが知ることは非常に困難である。以下のような可能性が存在す る。 1. SDPは変わらず、「c=」nullアドレスのタイプはIPv4である。 帯域幅値はIPv4ネットワークに必要な帯域幅を示す。 2. SDPはアプリケーションレベルゲートウェイ(ALG)によって変えられた。 「c=」アドレスはIPv6タイプに変えられる。帯域幅値は変わらない。 3. SDPは変えられ、「c=」アドレスタイプと帯域幅値の両方が変換される。 残念ながら、この処理はほとんど実行できない(3.3参照)。 1の場合、クライアントは、サーバーがIPv4ネットワーク内にあり、帯域幅値 を計算するときにIPv4のオーバーヘッドを使用することを理解できる。クラ イアントが帯域幅値を変換できることはほとんどない(セクション3.3参照)。 2の場合、クライアントはサーバーがIPv4ネットワーク内にあることがわから ない。また、IPv6のオーバーヘッドを含む帯域幅値が計算されないことがわ からない。クライアントがこの値を使用して、ネットワークの端末に十分な リソースがあるかどうかを判断する場合、クライアントは必要なビットレー トを過小評価することになる。結果として、アプリケーションのパフォーマ ンスが悪化する可能性がある。 3の場合、すべてが正しく機能する。ただし、このケースは非常に稀である。 パケットレートに関する詳細情報がない状態で帯域幅値を変換しようとした 場合、値に重大なエラーがもたらされる可能性がある。 3.2. 他のメカニズムの考慮 セクション1.2および1.3には、ヘッダー圧縮およびトンネルなど、低レイ ヤーのヘッダーサイズを変える複数の理由が列挙されている。 このようなメカニズムに関して、考慮に入れるべきさまざまな可能性がある。 Westerlund Standards Track [Page 7] RFC 3890 Bandwidth Modifier for SDP September 2004 エンドポイント間に直接IPsecを使用することは、当然ながら、アプリケー ションに知らせるべきである。そうすることで、追加のヘッダーを考慮に入 れることができるようになる。ただし、受信者がIPsecヘッダーを考慮に入れ て値を変換できない場合、現在のSDP帯域幅修飾子と同じ問題が存在する。 アプリケーションが仮想プライベートネットワークの存在を意識する可能性 は低い。したがって、すべてのトラフィックをトンネルするメカニズムの普 遍性は、値を変換できるかどうかをアプリケーションが考慮することすら妨 げる可能性がある。 ヘッダー圧縮を使用する場合、実際のオーバーヘッドはあまり決定的ではな いが、ほとんどの場合、特定のアプリケーションについて平均のオーバー ヘッドを決定することができる。ネットワークノードが、何らかのタイプの ヘッダー圧縮が採用されることを知っている場合、それを考慮に入れること ができる。RSVP [15]にはRFC 3006 [16]という拡張があり、データ送信者が ネットワークノードにデータフローの圧縮可能性について通知することがで きる。この処理を正確に実行できるようにするには、RFC 3006が提供する圧 縮要素およびパケットレートまたはサイズが必要である。 3.3. 帯域幅値の変換 IPv4オーバーヘッドを使用して計算した帯域幅値をIPv6オーバーヘッドに変 換したい場合、パケットレートが必要である。通常、IPv6の新しい帯域幅値 は「IPv4帯域幅」+「パケットレート」*20バイトである。この20バイトは、 IPv6ヘッダーとIPv4ヘッダー間の一般的な差異である。IPv4オプション[14] またはIPv6拡張ヘッダー[13]を使用する場合、オーバーヘッドの差異は別の 値になる可能性がある。 変換にはストリームのパケットレートが必要なので、これは場合によっては 不可能である。多くのコーデックは、複数の可能なパケット/フレームレート を持つか、ペイロード形式の集約を実行することができる。結果として、 レートは多数になる。したがって、SDPに何か追加情報が必要になる。 「a=ptime:」パラメータは1つの候補になりうる。ただし、通常、このパラ メータは音声コーデックにのみ使用される。この定義[1]は、送信者が無視す ることもできる推奨でしかない。よりよいパラメータが必要である。 3.4. RTCPの問題 変換機に関してIPv4およびIPv6ネットワークのホスト間にRTCPを使用する場 合、同様の問題が存在する。IPv4ドメインから送出されるRTCPトラフィック は、ヘッダーが大きいため、IPv6ドメインで意図されているよりも高いRTCP ビットレートになる。その結果、RTCPトラフィックに必要な帯域幅が最大25% 増大する可能性がある。IPv4ホストの数がIPv6ホストの数よりも大幅に多い Westerlund Standards Track [Page 8] RFC 3890 Bandwidth Modifier for SDP September 2004 とき、小さなRTCPパケットの場合に増加が最大になる。 幸いにも、RTCPはRTPと比較して帯域幅が制限されているため、RTCP帯域幅が RTP帯域幅の5%の場合、最大でも合計セッション帯域幅のわずか1.75%が増加 する結果になる。RTCPのランダム化によって、短期間で容易に同じ規模の結 果になる可能性があるため、この増加は許容可能と見なすことができる。ほ とんどの場合、帯域幅の増加は少なくなる。 同時に、これはIPv4およびIPv6ノード間のレポートにおける不公平という結 果になる。最悪の場合、IPv6ノードは25%長い間隔でレポートする可能性があ る。 このような問題はあまり重要ではないため、複雑な解決策の価値がないと考 えられてきた。したがって、RTCP帯域幅を導出する単純なアルゴリズムのみ が本仕様では定義されている。 3.5. 今後の開発 現在、IETFには、リアルタイムメディアに適した新しいデータグラムトラン スポートプロトコルを設計する研究がある。このプロトコルは、データグラ ム輻輳制御プロトコル(Datagram Congestion Control Protocol/DCCP)と呼ば れる。このプロトコルのヘッダーサイズは、おそらくUDPとは異なる。現在、 UDPはリアルタイムメディアに最もよく使用されているプロトコルである。こ の結果として、トランスポートの組み合わせになる可能性が高い。実際のプ ロトコルSETUP前に決定されない、異なるプールを使用する可能性がある場合、 これは問題になる可能性がある。したがって、この値を事前に計算すること は不可能である。これは、トランスポート非依存帯域幅修飾子が必要なもう1 つの理由である。 DCCPの輻輳制御アルゴリズムは、実際に利用できる帯域幅を制御する。この アルゴリズムによって、SDP帯域幅修飾子を指定してアプリケーションのメ ディアストリームの動的な可能性を宣言するための研究がさらに必要になる 可能性がある。たとえば、アプリケーションが全体で生成できる最小および 最大のメディア帯域幅、または、可能なレートを列挙して特定のビットレー トを生成することのみができるメディアコーデックなどである。ただし、こ れは今後の研究対象であり、現在の解決策の範囲外である。 3.6. 問題のまとめ 現在のSDP帯域幅修飾子の欠点は、低レイヤーに必要な帯域幅も含まれること である。多くの場合、低レイヤーとそのバージョンが計算に含まれたことを 判断することは困難である(特に、異なるドメイン間の変換やプロキシ処理が ある場合)。こそのため、受信者は、実際に使用されている低レイヤーに基づ いて、ある帯域幅を変換する必要があるかどうかを判断できない。 Westerlund Standards Track [Page 9] RFC 3890 Bandwidth Modifier for SDP September 2004 第2に、使用される予定の最大パケットレートを受信者が明確に判断できる属 性は存在しない。この値は、オーバーヘッドの差異が既知の場合、帯域幅値 の正確な変換のために必要である。 4. 問題の範囲 セクション3に記載されている問題は一般的であり、SDP、他のシグナリング プロトコル、およびリソース予約プロトコルを使用するアプリケーションレ ベルのシグナリングに影響がある。ただし、本文書の対象は、SDPのビット レートをシグナリングする際に固有の問題である。他の影響を受けるプロト コルおよび新たに設計されるプロトコルでは、これらの問題を考慮する必要 がある。MMUSIC WGには、SDP-NGというSDPの後継についての研究がある。 SDP-NG [17]で帯域幅を指定するための解決策を設計する際は、本文書に概説 されている問題を考慮することが推奨される。 本仕様は、SDP内でビットレート情報を伝達することのみを対象としているた め、適用対象には制限がある。通常、SDP情報はアプリケーションプロトコル によってエンドツーエンドで伝送されるため、エンドポイント間のノードは ビットレート情報にアクセス権を持たない。通常、その情報を考慮に入れる ことができるのはエンドポイントのみである。内部ノード(interior node)は、 SDP以外の手段を通じて情報を受信する必要が出てくるが、これは本仕様の範 囲外である。 それでも、本仕様で提供しているビットレート情報は、第1ホップのリソース 予約とアドミッション制御などの場合には十分である。また、本仕様は最大 コーデックレートに関する情報を提供しているが、これは低レベルのプロト コルには依存していない。 本仕様は、NATや他のミドルボックスを検出する問題の解決を試みるものでは ない[NOT]。 5. 要件 これまでのセクションで概説した問題と前述の適用可能性に関する問題は、 以下の要件を満たすべきである。 - トランスポートオーバーヘッドの可能な組み合わせすべてについて計算で きるような方法で、帯域幅値を指定しなければならない[SHALL]。 Westerlund Standards Track [Page 10] RFC 3890 Bandwidth Modifier for SDP September 2004 6. 解決策 6.1. はじめに この章では、アプリケーション固有(Application Specific/AS)帯域幅修飾子 に関して本文書で概説した問題の解決策について説明する。この解決策に よって、アプリケーション、またはRTPセッションのデータとRTCPトラフィッ クに必要なビットレートを導き出すことができる。解決策は、新しいトラン スポート非依存アプリケーション固有(Transport Independent Application Specific/TIAS)帯域幅修飾子、および最大パケットレート用の新しいSDP属性 (maxprate)の定義に基づいている。 CTはセッションレベル修飾子であり、扱いは容易ではない。 オーバーヘッドが異なる問題に対処するには、妥当な最悪ケースのオーバー ヘッドを使用してCT値を計算することが推奨される[RECOMMENDED]。 妥当な最悪ケースのオーバーヘッドを計算する例を以下に示す。 最大トランスポートプロトコルのオーバーヘッドを使用し(可変の場合は平均 を使用し)、その値を使用が見込まれる最大IPオーバーヘッドに追加し、さら にデータトラフィックレートを追加する。カンファレンスに使用する個々の メディアストリームにこの処理を実行し、それらを合計する。 RRとRS修飾子[9]を定義どおりに使用し、トランスポートオーバーヘッドを含 める。ホスト間の些細な不公平は許容できると考えられる。 6.2. TIAS帯域幅修飾子 6.2.1. 用法 以下の用途のために、新しい帯域幅修飾子が定義される。 - リソースの予約。リソースの予約に使用するには、単一のビットレート で十分な可能性がある。一部の特性は、ストリーム、コーデックタイプな どから派生する可能性がある。より詳細な情報が必要な場合、別のSDPパ ラメータが必要である。 - 最大メディアコーデックレート。後述する「TIAS」の定義に従うと、ほ とんどのビットレートはメディアコーデックに由来する。 したがって、これはデコーダーが対応する必要がある最大コーデックビッ トレートの優れた指標になる。 - ストリームに必要な通信ビットレート。「TIAS」値と「maxprate」を使 用すると、ストリームに必要になる最大通信ビットレートを判断すること ができる。セッションレベル値を使用して、またはセッションのストリー ムの最大ビットレートをすべて合計することで、受信者は、通信リソース がストリームを処理するために十分かどうかを判断することができる。た Westerlund Standards Track [Page 11] RFC 3890 Bandwidth Modifier for SDP September 2004 とえば、モデムユーザーは、そのセッションがモデムの機能や確立済み接 続に適合しているかどうかを判断することができる。 - RTPセッション帯域幅を判断し、RTCP帯域幅を導出する。 RTPベースのトランスポートの場合、導出されるトランスポート依存属性 は、RTPセッション帯域幅になる。暗黙的な割り当てを使用する場合、 RTCP帯域幅を判断するためにTIAS値を使用することもできる。RTP [4]で は、明示的に指定されていない場合、RTCPは追加の帯域幅(RTPセッション 帯域幅の5%に等しい値)を使用しなければならない、と規定している。 RTCP帯域幅は、[9]に定義されているRRおよびRS修飾子を使用して明示的 に割り当てることができる。 6.2.2. 定義 以下のように、新しいセッションおよびメディアレベル帯域幅修飾子が定義 される。 b=TIAS: ; ABNF定義についてはセクション6.6を参照。 トランスポート非依存アプリケーション固有最大(Transport Independent Application Specific Maximum/TIAS)帯域幅修飾子は、整数のビットレート 値(ビット/秒単位)を持っている。 小数の帯域幅値は、常に直近の整数値に切り上げなければならない[SHALL]。 帯域幅値は、アプリケーション(SDPセッションレベル)またはメディアスト リーム(SDPメディアレベル)が必要とする最大値である。この値には、IP、ま たはTCPやUDPのような他のトランスポートレイヤーを考慮していない。 SDPセッションレベルでは、TIAS値は、すべての宣言済みメディアストリーム を使用する場合に必要な最大合計帯域幅である。この値は個々のメディアス トリーム値すべての合計未満でもよい[MAY]。 これは、すべてのストリームが同じ時点で最大値になる訳ではない、という 可能性のためである。通常、これは格納されているメディアストリームにつ いてのみ検証することができる。 RTPで伝送されるメディアストリームの場合、SDPメディアレベルでTIASを使 用して、RTP「セッション帯域幅」を導出することができる([4]セクション 6.2の定義参照)。RTPで伝送される場合、TIAS値は以下のように定義される。 ビットレートの計算には、[4]に定義されているRTPペイロードのみを使用 しなければならない[SHALL]。つまり、低レイヤー(IP/UDP)とRTPヘッダー (RTPヘッダー、RTPヘッダー拡張、CSRCリスト、他のRTPプロファイル固有 のフィールドを含む)は除外する。 RTPペイロードには、ペイロード形式のヘッダーとデータの両方が含まれ ることに注意。その結果、RTPベースのメディアトランスポート、非RTPト ランスポート、および格納済みメディアについて同じ値を使用できるよう になる。 Westerlund Standards Track [Page 12] RFC 3890 Bandwidth Modifier for SDP September 2004 注意1: bpsの用法は、RFC 2327 [1]に準拠しない。 この変更は、値の解析側には関係なく、値の解釈側のみが意識する必要があ る。この変更が実行される理由は、より優れた解決方法のためであり、RRお よびRS帯域幅修飾子にも使用されてきた([9]参照)。 注意2: RTCP帯域幅は帯域幅値に含まれない。RTCPを使用するアプリケーショ ンの場合、RTCPが使用する帯域幅は、低レイヤーを含むRTPセッション帯域幅 の5%か、RRおよびRS修飾子[9]に従う。TIASを使用する場合のRTCPビットレー トを導出する方法の仕様については、セクション6.5に提示している。 6.2.3. 用法の規則 「TIAS」は、主にSDPメディアレベルに使用することを目的としている。すべ てのメディアストリームが同じトランスポートを使用している場合、セッ ションレベルでSDPに「TIAS」帯域幅値を提示してもよい[MAY]。全メディア ストリームのメディアレベル値の合計が、全ストリームに必要な実際の最大 帯域幅よりも大きい場合、セッションレベルで含めるべきである。ただし、 セッションレベルで提示する場合、メディアレベルでも提示すべきである [SHOULD]。すべてのメディアストリームに同じトランスポートプロトコルを 使用する場合を除き、「TIAS」をセッションレベルに提示してはならない [SHALL NOT]。IPv6/UDP/RTPなど、同じプロトコルの組み合わせを使用する限 り、同じトランスポートが使用される。 「TIAS」を実装しないSDPのアプリケーションとの間で下位互換性を実現する には、「TIAS」を使用するときに「AS」修飾子も含めることが推奨される [RECOMMENDED]。低レイヤーのオーバーヘッドを含む値を提示することは、問 題があるとしても、提示しないよりもよい。 ただし、TIASを実装するSDPアプリケーションは、「AS」値と「TIAS」の両方 が提示された場合、「AS」値を無視し、「TIAS」を代わりに使用すべきであ る[SHOULD]。 RTPで伝送されるストリームにTIASを使用する場合、計算可能であれば、次に 定義する「maxprate」属性を対応するSDPレベルに含めなければならない [SHALL]。 6.3. パケットレートパラメータ 実際に使用される低レイヤーを含む帯域幅値を計算するために、パケット レート属性も定義されている。 SDPのセッションおよびメディアレベル最大パケットレート属性は、以下のよ うに定義される。 a=maxprate: ; ABNF定義についてはセクション6.6を参照。 Westerlund Standards Track [Page 13] RFC 3890 Bandwidth Modifier for SDP September 2004 は、ストリームの最大パケットレートの浮動小数点値(パケッ ト/秒単位)である。パケット数が可変の場合、その値は、ライブストリーム の場合にアプリケーションが生成する可能性がある最大値、または格納済み のオンデマンドストリームの場合は生成済みの最大値にしなければならない [SHALL]。パケットレートを計算するには、1秒ウィンドウ内で送信されたパ ケット数を追加する。maxprateは、ウィンドウがメディアストリーム全体を スライドするときに生成される最大値である。 この値(つまりライブストリーム)を計算できない場合、ある構成およびコン テンツについてコーデックが生成する可能性がある最大パケットレートの推 定値を使用しなければならない[SHALL]。 注意: スライドするウィンドウの計算結果は、常に整数値である。ただし、 属性フィールドは浮動小数点値である。これは、秒当たりの推定または既知 の最大パケットレートは小数の可能性があるためである。 SDPセッションレベルでは、「maxprate」値は、宣言済みメディアストリーム 全体について計算した最大パケットレートである。この値を測定(格納済みメ ディア)または推定(ライブ)できない場合、すべてのメディアレベル値の合計 は天井値(ceiling value)になる。注意: セッションレベルの値は、メディア ストリームの最大値の一時的な分散があるため、個々のメディアストリーム の合計よりも低くなる可能性がある。メディアストリームが異なるトランス ポートを使用する場合、「maxprate」属性はセッションレベルに提示しては ならない[MUST NOT]。メディアストリームが同じトランスポートを使用する 場合、この属性を提示してもよい[MAY]。この属性をセッションレベルに提示 する場合、すべてのメディアストリームのメディアレベルにも提示すべきで ある[SHOULD]。 パケットレートを導き出すことができ、TIASを含める場合、「maxprate」を すべてのトランスポートに含めなければならない[SHALL]。たとえば、TIASと IP/UDP/RTPのようなトランスポートを使用していて、最大パケットレート(実 際の値または推定値)を導き出すことができる場合、「maxprate」を含めなけ ればならない[SHALL]。ただし、(a) トランスポートのパケットレートを導き 出すことができない場合、または(b) TIASを含めない場合、「maxprate」を 含める必要はない。 6.4. トランスポート依存値への変換 トランスポート非依存の帯域幅値(bw-value)を、低レイヤーを含むトランス ポート依存値に変換する場合、以下の処理を実行しなければならない[MUST]。 1. 使用する低レイヤーを決定し、ヘッダーのサイズ合計を計算する(ビット 単位、h-size)。ヘッダーサイズが可変の場合、平均のサイズを使用しな ければならない[SHALL]。RTPでメディアが伝送される場合、低レイヤーは RTPヘッダーとヘッダー拡張(使用する場合)、CSRCリスト、すべてのプロ ファイル固有の拡張を含めなければならない[SHALL]。 Westerlund Standards Track [Page 14] RFC 3890 Bandwidth Modifier for SDP September 2004 2. SDPから最大パケットレートを取得する(prate = maxprate)。 3. ヘッダーサイズにパケットレートを乗じることで、トランスポートの オーバーヘッドを計算する(t-over = h-size * prate)。 4. トランスポートのオーバーヘッドを最も近い整数(バイト単位)に切り上 げる(t-over = CEIL(t-over))。 5. トランスポートのオーバーヘッドをトランスポート非依存の帯域幅値に 追加する(total bit-rate = bw-value + t-over)。 「maxprate」を使用して上記の計算を実行すると、ビットレート値は、メ ディアストリームがトランスポート上で使用する可能性がある、計算で推定 された絶対最大値になる。 6.5. RTCP帯域幅の導出 この章では、IPv4をIPv6に変換することで発生する公正さや可能なビット レートの変化は解決されない。これらの変化は些細であると考えられ、既知 の解決策では、RTP/RTCP実装のコード変更を導入している。このセクション では、明示的に指定されていない場合に、ビットレートを計算してRTCPに割 り当てる矛盾のない方法を提示する。 まず、セクション6.4に従い、計算を実行するエンドポイントで使用する実際 のトランスポートレイヤーを使用して、トランスポート依存のRTPセッション のビットレートを計算する。次に、RTPセッション帯域幅(つまり、通常は計 算値の5%に等しい値)に基づいて、通常どおりにRTCPビットレートを導出する。 6.5.1. この解決策の目的 IPv4ホストとIPv6ホストのどちらにもまったく同じRTCPビットレート値を指 定すると、IPv4ホストの方が高いRTCP送信レートになる。 送信レートとは、ある期間に送信されたRTCPパケット数である。RTCPの送信 は、RTP仕様[4]に定義されている規則に従って制限される。RTCPパケットが 100バイトの場合(UDP/IPv4を含む)、IPv4送信者は約20%高い送信レートにな る。より大きなRTCPパケットの場合、このレートは低くなる。たとえば、パ ケットが300バイトの場合、IPv4ホストはわずか7%高い送信レートになる。 RTPセッションに大きなTIAS/maxprate率を指定するトラフィックパラメータ がある場合、RTCP帯域幅を導出する上記の規則は、固定の割り当てと同じ動 作になる。TIAS/maxprate率が約40バイト/パケットで、RTCPパケットが100バ イトの場合、2つのホストは公平になる。5バイト/パケットのTIAS/maxprate 率の場合、IPv6ホストは約15〜20%多いRTCPパケットを送信することができる。 Westerlund Standards Track [Page 15] RFC 3890 Bandwidth Modifier for SDP September 2004 RTCPパケットが大きくなるほど、送信レートでIPv6ホストが優先される。 まとめると、トランスポート非依存のビットレートおよびパケットレートの 通常の有効な組み合わせであれば、IPバージョンが異なり、オーバーヘッド が異なるホスト間にある公平さの差異は許容範囲である。IPv4ヘッダーと IPv6ヘッダー間にあるオーバーヘッドの差異が20バイトの場合、ユニキャス ト接続の場合に実際に使用されるRTCP帯域幅は、合計セッション帯域幅の約 1%より大きくなることはない。 6.6. ABNF定義 この章では、RFC 2234 [4]のABNFに従って、帯域幅修飾子とパケットレート 属性を定義している。 帯域幅修飾子: TIAS-bandwidth-def = "b" "=" "TIAS" ":" bandwidth-value CRLF bandwidth-value = 1*DIGIT 最大パケットレート属性: max-p-rate-def = "a" "=" "maxprate" ":" packet-rate CRLF packet-rate = 1*DIGIT ["." 1*DIGIT] 6.7. 例 v=0 o=Example_SERVER 3413526809 0 IN IP4 server.example.com s=Example of TIAS and maxprate in use c=IN IP4 0.0.0.0 b=AS:60 b=TIAS:50780 t=0 0 a=control:rtsp://server.example.com/media.3gp a=range:npt=0-150.0 a=maxprate:28.0 m=audio 0 RTP/AVP 97 b=AS:12 b=TIAS:8480 a=maxprate:10.0 a=rtpmap:97 AMR/8000 a=fmtp:97 octet-align; a=control:rtsp://server.example.com/media.3gp/trackID=1 m=video 0 RTP/AVP 99 Westerlund Standards Track [Page 16] RFC 3890 Bandwidth Modifier for SDP September 2004 b=AS:48 b=TIAS:42300 a=maxprate:18.0 a=rtpmap:99 MP4V-ES/90000 a=fmtp:99 profile-level-id=8; config=000001B008000001B509000001010000012000884006682C2090A21F a=control:rtsp://server.example.com/media.3gp/trackID=3 ストリーミングセッションのSDPのこの例には、2つのメディアストリーム、 AMRでエンコーディングした1つの音声ストリーム、およびMPEG-4ビデオエン コーダでエンコーディングした1つのビデオストリームがある。ここでは、 AMRを使用して一定レートのメディアストリームを生成し、10パケット/秒に なるパケット化を使用する。その結果、8480ビット/秒のTIAS帯域幅レート、 および指定された10パケット/秒になる。ビデオストリームはより変化しやす い。ただし、42,300ビット/秒という測定済み最大ペイロードレートである。 ビデオは15フレーム/秒ではあるが、ビデオストリームも可変のパケットレー トである(少なくとも、1秒間のウィンドウの1インスタンス以上に18パケット が含まれる)。 7. プロトコルの相互作用 7.1. RTSP 「TIAS」および「maxprate」パラメータは、本仕様に従って、RTSPとともに 使用することができる。トランスポート依存の帯域幅を計算できるようにす るには、トランスポートヘッダーパラメータのいくつかが必要である。 RTSP SETUPの前に、クライアントが必要な帯域幅を計算することは、問題は ないはずである。この理由は、クライアントが制限された数のトランスポー トセットアップに対応しているためである。SETUPリクエストでサーバーへ実 際にオファーされる内容は、SDP記述の内容によって変わる。「m=」行は、希 望のトランスポートプロファイルをクライアントにシグナリングする。 7.2. SIP 「TIAS」とともに「maxprate」を使用する方法は、現在使用されている 「AS」修飾子の処理方法と同じであるべきである。必要なトランスポートパ ラメータは、「m=」行のトランスポートフィールドで入手できる。アドレス クラスは、「c=」フィールドとクライアントの接続性から判断することがで きる。 Westerlund Standards Track [Page 17] RFC 3890 Bandwidth Modifier for SDP September 2004 7.3. SAP SAPの場合、トランスポート依存のビットレートを計算するために使用できる すべての情報をSDPに提示すべきである。「c=」情報によって、マルチキャス トに使用されるアドレスファミリがわかる。各メディアのRTP/UDPなどのトラ ンスポートレイヤーは、メディア行(「m=」)およびそのトランスポート フィールドで明らかになる。 8. セキュリティの考慮事項 本文書で定義されているパラメータが示す帯域幅値は、完全性が保護されて いなければ変更される可能性がある。帯域幅値を変更すると、だまされた受 信者が、実際に必要な帯域幅よりも多い(または少ない)値を予約する可能性 がある。予約した帯域幅が大きすぎると、ユーザーの代わりに不要な帯域幅 が使用される一方で、相手側が使用できたはずのリソースがブロックされる 可能性がある。予約した帯域幅が小さすぎると、受信側ユーザーの品質に影 響が出る可能性がある。 大きすぎるTIAS値を信頼した場合も、通信およびデコーディングのリソース が不十分なために、受信者がセッションを拒否する結果になる可能性がある。 セキュリティリスクがあるため、不正の実行を防ぎ、ソースを信頼できるよ うに、SDPの完全性を保護し、ソースを認証することが強く推奨される [RECOMMENDED]。また、SDPの受信者は、受信した帯域幅値の分析を実行して、 そのアプリケーションにとって妥当な予想値であることを検証することも推 奨される[RECOMMENDED]。たとえば、単一チャネルのAMRでエンコーディング された音声ストリームが、1000 kbpsを使用するように指定されている場合は 不適切である。 上記のセキュリティ要件の一部は、SDPを使用するシグナリングプロトコルを ミドルボックス経由で機能できるようにする要件(RFC 3303 [18]のセキュリ ティの考慮事項を参照)と矛盾している。 9. IANA条項 本文書は、1つの新しいSDPセッションおよびメディアレベル属性 「maxprate」を登録する(セクション6.3参照)。 標準化過程のRFCに必要な規則に従って、新しいSDP [1]帯域幅修飾子 (bwtype)「TIAS」も登録する。修飾子はセクション6.2で定義されている。 Westerlund Standards Track [Page 18] RFC 3890 Bandwidth Modifier for SDP September 2004 10. 謝辞 著者は、文書のレビュー作業についてGonzalo CamarilloとHesham Solimanに 感謝したい。言葉遣いの見直しと修正の手助け、および旧バージョンの誤り の検出について、Stephen Casnerに多大なる感謝を捧げる。また、改善案を いただいたことについて、Colin Perkins、Geetha Srikantan、Emre Aksuに 感謝を述べたい。 また、本仕様にコメントを寄せてくださったMMUSICワークグループメーリン グリストのメンバーにも感謝したい。 11. 参考文献 11.1. 規範となる参考文献 [1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998. [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [4] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 11.2. 有益な参考文献 [5] Handley, M., Perkins, C., and E. Whelan, "Session Announcement Protocol", RFC 2974, October 2000. [6] 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. [7] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, June 2002. [8] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [9] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, July 2003. Westerlund Standards Track [Page 19] RFC 3890 Bandwidth Modifier for SDP September 2004 [10] Degermark, M., Nordgren, B., and S. Pink, "IP Header Compression", RFC 2507, February 1999. [11] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [12] Bormann, C., Burmeister, C., Degermark, M., Fukushima, H., Hannu, H., Jonsson, L-E., Hakenberg, R., Koren, T., Le, K., Liu, Z., Martensson, A., Miyazaki, A., Svanbro, K., Wiebke, T., Yoshimura, T., and H. Zheng, "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed ", RFC 3095, July 2001. [13] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [14] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [15] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [16] Davie, B., Iturralde, C., Oran, D., Casner, S., and J. Wroclawski, "Integrated Services in the Presence of Compressible Flows", RFC 3006, November 2000. [17] Kutscher, Ott, Bormann, "Session Description and Capability Negotiation," Work in Progress, March 2003. [18] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and A. Rayhan, "Middlebox communication architecture and framework", RFC 3303, August 2002. [19] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [20] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [21] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. Westerlund Standards Track [Page 20] RFC 3890 Bandwidth Modifier for SDP September 2004 12. 著者の連絡先 Magnus Westerlund Ericsson Research Ericsson AB Torshamnsgatan 23 SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com Westerlund Standards Track [Page 21] RFC 3890 Bandwidth Modifier for SDP September 2004 13. 完全な著作権表記 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78 に記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、イン ターネット協会およびIETFは、この情報がいかなる権利も侵害していないと いう保証、商用利用および特定目的への適合性への保証を含め、また、これ らだけに限らずすべての保証について、明示的もしくは暗黙的の保証は行わ れない。 知的所有権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知 的所有権または他の諸権利の有効性または範囲に関して、またはこのような 権利下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何 ら見解を持たない。このような権利を確認する独自の取り組みを行ったこと も示さない。RFC文書の権利に関するIETFの手続きの情報は、BCP 78および BCP 79に記載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者 またはユーザーが一般的なライセンスまたは許可の取得を試みた結果につい ては、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能で ある。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性が ある、すべての著作権、特許または特許アプリケーション、あるいは他の所 有権について、すべての関連団体に対して配慮するよう依頼している。情報 は、IETF (ietf-ipr@ietf.org)宛てに送信していただきたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2008年 ----------------------------------------------------------------------- Westerlund Standards Track [Page 22]