RFC3524 日本語訳
3524 Mapping of Media Streams to Resource Reservation Flows. G.Camarillo, A. Monrad. April 2003. (Format: TXT=11249 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group G. Camarillo
Request for Comments: 3524 A. Monrad
Category: Standards Track Ericsson
April 2003
コメントを求めるワーキンググループG.キャマリロの要求をネットワークでつないでください: 3524年のA.Monradカテゴリ: 標準化過程エリクソン2003年4月
Mapping of Media Streams to Resource Reservation Flows
資源予約へのメディアストリームに関するマッピングは流れます。
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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).
このドキュメントはSession記述プロトコル(SDP)組分けフレームワークと拡大を定義します。 それは、ただ一つの資源予約流動に写像されるようメディアストリームのグループに要求するのを許容します。 必要であるSDP構文はSingle予約Flow(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
1. 序論… 2 1.1用語… 2 2. SRF意味論… 2 3. 適用性声明… 3 4. 例… 3 5. IANA問題… 4 6. セキュリティ問題… 4 7. 承認… 4 8. 標準の参照… 5 9. 有益な参照… 5 10. 作者のアドレス… 5 11. 完全な著作権宣言文… 6
Camarillo & Monrad Standards Track [Page 1] RFC 3524 Mapping Media Streams to Resource Reservation Flows April 2003
2003年4月にメディアストリームを資源予約流れに写像するキャマリロとMonrad標準化過程[1ページ]RFC3524
1. Introduction
1. 序論
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パケットを受けるとき、それは、パケットを流れに写像するためにフィルタを適用します。属します。 ルータは流れに対応するService(QoS)のQualityを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つのメディアストリームとのマルチメディアセッションは、3番目のメディアストリームが2番目の予約流動を使用している間それらの2つがただ一つの予約流動に写像されるのを必要とするかもしれません。
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を使用して、Single予約Flow(SRF)と呼ばれる新しい「意味論」属性を定義します。
1.1 Terminology
1.1 用語
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTが解釈されるのは中でBCP14について説明しました、RFC2119[3]ということであり、対応する一口実装のために要件レベルを示すべきであるかをさせましょう。
2. SRF Semantics
2. SRF意味論
We define a new "semantics" attribute within the SDP grouping framework [2]: Single Reservation Flow (SRF).
私たちはフレームワーク[2]を分類するSDPの中で新しい「意味論」属性を定義します: 予約流れ(SRF)を選抜してください。
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意味論SHOULDを使用することで分類されました。同じ資源予約流動に写像されます。 それがするメディア系列は特定のSRFグループSHOULD NOTに属しません。そのSRFグループに使用される予約流動に写像されてください。
Camarillo & Monrad Standards Track [Page 2] RFC 3524 Mapping Media Streams to Resource Reservation Flows April 2003
2003年4月にメディアストリームを資源予約流れに写像するキャマリロとMonrad標準化過程[2ページ]RFC3524
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グループがただ一つのメディア系列から成るかもしれないことに注意してください。 定義に続いて、その場合、上では、そのメディア系列が1つの予約流動に写像されるでしょう。 その予約流動はそのメディア系列と、他のどんなメディア系列からもトラフィックを運ばないでしょう。
3. Applicability Statement
3. 適用性証明
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.
資源予約がいくつかのシナリオをうまくいく方法で、本書では説明されたメカニズムを使用するのは不要になります。 いくつかの資源予約プロトコルで、SDPセッションが記述であると生成する実体はセッションのための両方の方向(すなわち、sendrecv)によるリソースを割り当てることができます。 この場合、セッション記述缶のジェネレータはメディア流れと予約流れのどんな特定のマッピングも選びました。
The mechanism described in this document is useful when the remote party needs to be involved in the resource reservation.
リモートパーティーが、資源予約にかかわる必要があるとき、本書では説明されたメカニズムは役に立ちます。
4. Examples
4. 例
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.
この例のために、私たちは、予約流れを証明するためにSDPセッションとRSVP[5]を輸送するのにSIP[4]を使用するのを選びました。 しかしながら、SDP構文に影響しないで、代わりに他のプロトコルかメカニズムを使用できました。
A user agent receives a SIP INVITE with the SDP below:
ユーザエージェントは以下のSDPと共にSIP 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
ローラ289083124 289083124IN IP4 1v=0o=.example.com tが0 0c=IN IP4と等しい、192.0、.0、.1、=グループ: SRF=オーディオの30000RTP/AVP0 1 2m aが: 1mの中間の=ビデオと等しい、30002RTP/AVP31aが等しい、中間、: 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セッションを確立するでしょう。 RSVPセッションは三重によって定義されます: (DestAddress、ProtocolId[DstPort]。) テーブル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つのメディアストリームを写像できるでしょうに。
Camarillo & Monrad Standards Track [Page 3] RFC 3524 Mapping Media Streams to Resource Reservation Flows April 2003
2003年4月にメディアストリームを資源予約流れに写像するキャマリロとMonrad標準化過程[3ページ]RFC3524
Session Number DestAddress ProtocolId DstPort
________________________________________________
1 192.0.0.1 UDP any
セッション番号DestAddress ProtocolId DstPort________________________________________________ 1 192.0 .0、.1UDP、いくらか。
Table 1: Parameters needed to establish the RSVP session
テーブル1: パラメタは、RSVPセッションを確立する必要がありました。
5. IANA Considerations
5. IANA問題
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はフレームワーク[2]を分類するSDPのために以下の新しい「意味論」属性を示しました。 「グループ」SDP AttributeのためにSemanticsの下のSDPパラメタ登録( http://www.iana.org/assignments/sdp-parameters )にそれを登録してあります:
Semantics Token Reference ------------------- ----- --------- Single Reservation flow SRF [RFC3524]
意味論トークン参照------------------- ----- --------- 独身の予約流れSRF[RFC3524]
6. Security Considerations
6. セキュリティ問題
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セッション記述に適用されるのは、STRONGLY RECOMMENDEDです。 SIPで運ばれたセッション記述のために、S/MIMEは終わりから終わりへの保全そのような保護を提供する自然な選択です、RFC3261[4]で説明されるように。 他のアプリケーションは異なった形式の保全保護を使用するかもしれません。
7. Acknowledgements
7. 承認
Jonathan Rosenberg provided useful comments about the applicability of the mechanism described in this document.
ジョナサン・ローゼンバーグは本書では説明されたメカニズムの適用性に関して役に立つコメントを提供しました。
Camarillo & Monrad Standards Track [Page 4] RFC 3524 Mapping Media Streams to Resource Reservation Flows April 2003
2003年4月にメディアストリームを資源予約流れに写像するキャマリロとMonrad標準化過程[4ページ]RFC3524
8. Normative References
8. 引用規格
[1] Handley, M. and V. Jacobson, "SDP: Session Description
Protocol", RFC 2327, April 1998.
[1] ハンドレー、M.、およびV.ジェーコブソン、「SDP:」 「セッション記述プロトコル」、RFC2327、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のキーワード」、BCP14、RFC2119、1997年3月。
9. Informative References
9. 有益な参照
[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.学生は「以下をちびちび飲みます」。 「セッション開始プロトコル」、RFC3261、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.ジャマン、「リソースReSerVationは(RSVP)について議定書の中で述べます--バージョン1Functional Specification」、RFC2205、1997年9月。
10. Authors' Addresses
10. 作者のアドレス
Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland
ゴンサロキャマリロエリクソンは合図研究研究室を進めました。 フィン-02420Jorvasフィンランド
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
Camarillo & Monrad Standards Track [Page 5] RFC 3524 Mapping Media Streams to Resource Reservation Flows April 2003
2003年4月にメディアストリームを資源予約流れに写像するキャマリロとMonrad標準化過程[5ページ]RFC3524
11. Full Copyright Statement
11. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Camarillo & Monrad Standards Track [Page 6]
キャマリロとMonrad標準化過程[6ページ]
一覧
スポンサーリンク
