Network Working Group G. Camarillo
Request for Comments: 3524 A. Monrad
Category: Standards Track Ericsson
April 2003
Mapping of Media Streams to Resource Reservation Flows
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
Abstract
抽象
This document defines an extension to the Session Description Protocol (SDP) grouping framework. It allows requesting a group of media streams to be mapped into a single resource reservation flow. The SDP syntax needed is defined, as well as a new "semantics" attribute called Single Reservation Flow (SRF).
この文書では、セッション記述プロトコル（SDP）グループ化フレームワークの拡張を定義します。これは、メディアストリームのグループは、単一のリソース予約フローにマッピングすることを要求することができます。必要な構文が定義されているSDP、ならびに単一予約の流れ（SRF）と呼ばれる新しい「意味論」属性。
Table of Contents
目次
1. Introduction ........................................ 2
1.1 Terminology .................................... 2
2. SRF Semantics ....................................... 2
3. Applicability Statement ............................. 3
4. Examples ............................................ 3
5. IANA Considerations ................................. 4
6. Security Considerations ............................. 4
7. Acknowledgements .................................... 4
8. Normative References ................................ 5
9. Informative References .............................. 5
10. Authors' Addresses .................................. 5
11. Full Copyright Statement ............................ 6
Resource reservation protocols assign network resources to particular flows of IP packets. When a router receives an IP packet, it applies a filter in order to map the packet to the flow it belongs. The router provides the IP packet with the Quality of Service (QoS) corresponding to its flow. Routers typically use the source and the destination IP addresses and port numbers to filter packets.
リソース予約プロトコルはIPパケットの特定のフローにネットワークリソースを割り当てます。ルータがIPパケットを受信すると、それが属するフローにパケットをマッピングするためにフィルタを適用します。ルータはその流れに対応するサービスの品質（QoS）を持つIPパケットを提供します。ルータは、一般的にパケットをフィルタリングするために、送信元と宛先IPアドレスとポート番号を使用します。
Multimedia sessions typically contain multiple media streams (e.g. an audio stream and a video stream). In order to provide QoS for a multimedia session it is necessary to map all the media streams to resource reservation flows. This mapping can be performed in different ways. Two possible ways are to map all the media streams to a single resource reservation flow or to map every single media stream to a different resource reservation flow. Some applications require that the former type of mapping is performed while other applications require the latter. It is even possible that a mixture of both mappings is required for a particular media session. For instance, a multimedia session with three media streams might require that two of them are mapped into a single reservation flow while the third media stream uses a second reservation flow.
マルチメディアセッションは、典型的には、複数のメディアストリーム（例えば、オーディオストリームとビデオストリーム）を含みます。マルチメディアセッションのためのQoSを提供するためには、予約の流れ資源化に、すべてのメディアストリームをマッピングする必要があります。このマッピングは、様々な方法で行うことができます。 2つの可能な方法は、単一のリソース予約の流れへのすべてのメディアストリームをマッピングするために、異なるリソース予約の流れにすべての単一のメディアストリームをマッピングするためにあります。一部のアプリケーションは、他のアプリケーションは、後者を必要とするマッピングの前者が実行されることを必要とします。両方のマッピングの混合物は、特定のメディアセッションのために必要とされることも可能です。例えば、3つのメディアストリームとのマルチメディアセッションは、第三のメディアストリームが第二の予約フローを使用しながら、それらの二つが単一の予約フローにマッピングされることを必要とするかもしれません。
This document defines the SDP [1] syntax needed to express how media streams need to be mapped into reservation flows. For this purpose, we use the SDP grouping framework [2] and define a new "semantics" attribute called Single Reservation Flow (SRF).
この文書では、メディアストリームは、予約フローにマッピングする必要がある方法を表現するのに必要なSDP [1]シンタックスを定義します。この目的のために、我々は[2] SDPのグループ化フレームワークを使用し、シングル予約の流れ（SRF）と呼ばれる新しい「意味論」の属性を定義します。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3] and indicate requirement levels for compliant SIP implementations.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119に記載されているように、[3]に解釈されるべきであり、準拠SIP実装の要求レベルを示します。
We define a new "semantics" attribute within the SDP grouping framework [2]: Single Reservation Flow (SRF).
シングル予約の流れ（SRF）：私たちは、SDPのグループ化フレームワーク[2]内に新しい「意味論」の属性を定義します。
Media lines grouped using SRF semantics SHOULD be mapped into the same resource reservation flow. Media lines that do not belong to a particular SRF group SHOULD NOT be mapped into the reservation flow used for that SRF group.
SRFのセマンティクスを使用してグループ化されたメディアラインが同じリソース予約・フローにマップする必要があります。特定のSRFグループに属していないメディアラインがそのSRFグループのために使用された予約の流れにマップされるべきではありません。
Note that an SRF group MAY consist of a single media line. In that case, following the definition above, that media line will be mapped into one reservation flow. That reservation flow will carry traffic from that media line, and from no other media lines.
SRFグループは、単一のメディアラインから構成されてもよいことに注意してください。その場合には、上記の定義以下、そのメディア・ラインは、一つの予約フローにマッピングされます。その予約の流れは、そのメディアラインから、無他のメディアラインからのトラフィックを運ぶでしょう。
The way resource reservation works in some scenarios makes it unnecessary to use the mechanism described in this document. Some resource reservation protocols allow the entity generating the SDP session description to allocate resources in both directions (i.e., sendrecv) for the session. In this case, the generator of the session description can chose any particular mapping of media flows and reservation flows.
リソース予約は、いくつかのシナリオで動作する方法は、この文書で説明するメカニズムを使用することが不要になります。いくつかのリソース予約プロトコルは、エンティティがセッションの両方向（すなわち、SENDRECV）内のリソースを割り当てるためにSDPセッション記述を生成することを可能にします。この場合には、セッション記述の発生は、メディアフロー及び予約フローの任意の特定のマッピングを選択することができます。
The mechanism described in this document is useful when the remote party needs to be involved in the resource reservation.
相手は、リソース予約に関与する必要があるときに、この文書で説明するメカニズムが便利です。
For this example, we have chosen to use SIP [4] to transport SDP sessions and RSVP [5] to establish reservation flows. However, other protocols or mechanisms could be used instead without affecting the SDP syntax.
この例では、[5]予約フローを確立すること[4] SDPセッションとRSVPを輸送するためにSIPを使用することを選択しました。しかし、他のプロトコルまたはメカニズムは、SDP構文に影響を与えることなく、代わりに使用することができます。
A user agent receives a SIP INVITE with the SDP below:
ユーザエージェントは、SIPは、以下SDPと共にINVITEを受信します。
v=0 o=Laura 289083124 289083124 IN IP4 one.example.com t=0 0 c=IN IP4 192.0.0.1 a=group:SRF 1 2 m=audio 30000 RTP/AVP 0 a=mid:1 m=video 30002 RTP/AVP 31 a=mid:2
IP4 IN IP4 one.example.com T = 0のC = IN V = 0 0 =ローラ289083124 289083124は、=グループを192.0.0.1：SRF 1 2 M =オーディオ30000 RTP / AVP 0 =ミッド：1 M =ビデオ30002 RTP / AVP 31 =中旬：2
This user agent uses RSVP to perform resource reservation. Since both media streams are part of an SRF group, the user agent will establish a single RSVP session. An RSVP session is defined by the triple: (DestAddress, ProtocolId[, DstPort]). Table 1 shows the parameters used to establish the RSVP session.
このユーザエージェントは、リソース予約を実行するためにRSVPを使用しています。両方のメディアストリームは、SRFグループの一部であるので、ユーザエージェントは、単一のRSVPセッションを確立します。 （DestAddress、ProtocolId [DstPortの]）：RSVPセッションは三重によって定義されます。表1は、RSVPセッションを確立するために使用されるパラメータを示しています。
If the same user agent received an SDP session description with the same media streams but without the group line, it would be free to map the two media streams into two different RSVP sessions.
同じユーザーエージェントが同じメディアストリームとが、グループラインなしSDPセッション記述を受信した場合、2つの異なるRSVPセッションに2つのメディアストリームをマッピングする自由であろう。
Session Number DestAddress ProtocolId DstPort
________________________________________________
1 192.0.0.1 UDP any
Table 1: Parameters needed to establish the RSVP session
表1：RSVPセッションを確立するために必要なパラメータ
IANA has registered the following new "semantics" attribute for the SDP grouping framework [2]. It has been registered in the SDP parameters registry (http://www.iana.org/assignments/sdp-parameters) under Semantics for the "group" SDP Attribute:
IANAはSDPのグループ化フレームワーク[2]については、以下の新しい「意味論」属性を登録しています。それは、「グループ」SDP属性のセマンティクスの下でSDPパラメータレジストリ（http://www.iana.org/assignments/sdp-parameters）に登録されています。
Semantics Token Reference
------------------- ----- ---------
Single Reservation flow SRF [RFC3524]
An attacker adding group lines using the SRF semantics to an SDP session description could force a user agent to establish a larger or a smaller number of resource reservation flows than needed. This could consume extra resources in the end-point or degrade the quality of service for a particular session. It is thus STRONGLY RECOMMENDED that integrity protection be applied to the SDP session descriptions. For session descriptions carried in SIP, S/MIME is the natural choice to provide such end-to-end integrity protection, as described in RFC 3261 [4]. Other applications MAY use a different form of integrity protection.
SDPセッション記述にSRFセマンティクスを使用して、攻撃者は追加グループ株は、より大きな又はリソース予約の少ない数が必要以上にフローを確立するために、ユーザーエージェントを強制することができました。これは、エンドポイントで余分なリソースを消費するか、特定のセッションのためのサービスの品質を低下させることができます。したがって、強く完全性保護がSDPセッション記述に適用されることが推奨されます。 SIPで運ばれるセッション記述のために、S / MIMEは、RFC 3261に記載されているように、そのようなエンドツーエンドの完全性保護を提供するために、自然な選択である[4]。他のアプリケーションは、完全性保護の異なる形式を使用するかもしれません。
Jonathan Rosenberg provided useful comments about the applicability of the mechanism described in this document.
ジョナサンローゼンバーグは、この文書で説明するメカニズムの適用性に関する有用なコメントを提供しました。
[1] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[1]ハンドレー、M.およびV. Jacobsonの "SDP：セッション記述プロトコル"、RFC 2327、1998年4月。
[2] Camarillo, G., Eriksson, G., Holler, J. and H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", December 2002.
[2]キャマリロ、G.、エリクソン、G.、大声、J.、およびH. Schulzrinneと、 "セッション記述プロトコル（SDP）におけるメディア行のグループ化"、2002年12月。
[3] Bradner, S., "Key words for use in RFCs to indicate requirement levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーの、S.、 "要件レベルを示すRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月を。
[4] 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.
[4]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル"、 RFC 3261、2002年6月。
[5] Braden, R., Zhang, L., Berson, S., Herzog, S. and S. Jamin, "Resource ReSerVation protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[5]ブレーデン、R.、チャン、L.、Berson氏、S.、ハーツォグ、S.、およびS.ヤミン、 "リソース予約プロトコル（RSVP） - バージョン1機能仕様"、RFC 2205、1997年9月。
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロ・カマリロエリクソン高度なシグナリング研究所。 FIN-02420 Jorvasフィンランド
EMail: Gonzalo.Camarillo@ericsson.com
メールアドレス：Gonzalo.Camarillo@ericsson.com
Atle Monrad Ericsson N-4898 Grimstad Norway
Atle MonradエリクソンN-4898グリムスターノルウェー
EMail: atle.monrad@ericsson.com
メールアドレス：atle.monrad@ericsson.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
著作権（C）インターネット協会（2003）。全著作権所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上記の制限は永久で、インターネット学会やその後継者や譲渡者によって取り消されることはありません。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とインターネットソサエティおよびインターネットエンジニアリングタスクフォースはすべての保証を否認し、明示または黙示、その情報の利用がない任意の保証を含むがこれらに限定されない「として、」上に設けられています特定の目的への権利または商品性または適合性の黙示の保証を侵害します。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。