RFC2380 日本語訳
2380 RSVP over ATM Implementation Requirements. L. Berger. August 1998. (Format: TXT=31234 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group L. Berger Request for Comments: 2380 FORE Systems Category: Standards Track August 1998
コメントを求めるワーキンググループL.バーガー要求をネットワークでつないでください: 2380年の前面のシステムカテゴリ: 標準化過程1998年8月
RSVP over ATM Implementation Requirements
気圧実現要件の上のRSVP
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 (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 All rights reserved。
Abstract
要約
This memo presents specific implementation requirements for running RSVP over ATM switched virtual circuits (SVCs). It presents requirements that ensure interoperability between multiple implementations and conformance to the RSVP and Integrated Services specifications. A separate document [5] provides specific guidelines for running over today's ATM networks. The general problem is discussed in [9]. Integrated Services to ATM service mappings are covered in [6]. The full set of documents present the background and information needed to implement Integrated Services and RSVP over ATM.
このメモはATM交換仮想回路(SVCs)の上に走行RSVPのための特定の実現要件を提示します。 それは複数の実現と順応の間の相互運用性をRSVPとIntegrated Servicesに確実にする要件に仕様を提示します。 別々のドキュメント[5]は今日のATMネットワークをひくための特別な基準を提供します。 [9]で一般的問題について議論します。 ATMサービス対応表への統合Servicesは[6]で覆われています。 ATMの上のドキュメントプレゼントのバックグラウンド、Integrated Servicesを実行するのに必要である情報、およびRSVPのフルセット。
Table of Contents
目次
1. Introduction ................................................. 2
1.1 Terms .................................................... 2
1.2 Assumptions .............................................. 3
2. General RSVP Session Support ................................. 4
2.1 RSVP Message VC Usage .................................... 4
2.2 VC Initiation ............................................ 4
2.3 VC Teardown .............................................. 5
2.4 Dynamic QoS .............................................. 6
2.5 Encapsulation ............................................ 6
3. Multicast RSVP Session Support ............................... 7
3.1 Data VC Management for Heterogeneous Sessions ............ 7
3.2 Multicast End-Point Identification ....................... 8
3.3 Multicast Data Distribution .............................. 9
3.4 Receiver Transitions ..................................... 11
1. 序論… 2 1.1の用語… 2 1.2の仮定… 3 2. 一般RSVPセッションサポート… 4 2.1 RSVPメッセージVC用法… 4 2.2 VC開始… 4 2.3VC分解… 5 2.4 ダイナミックなQoS… 6 2.5カプセル化… 6 3. マルチキャストRSVPセッションサポート… 7 3.1 異種のセッションのためのデータVC管理… 7 3.2 マルチキャストエンドポイント識別… 8 3.3 マルチキャスト情報配給… 9 3.4受信機は移行します… 11
Berger Standards Track [Page 1] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[1ページ]。
4. Security Considerations ...................................... 11 5. Acknowledgments .............................................. 11 6. Author's Address ............................................. 12 REFERENCES ...................................................... 13 FULL COPYRIGHT STATEMENT ........................................ 14
4. セキュリティ問題… 11 5. 承認… 11 6. 作者のアドレス… 12の参照箇所… 13 完全な著作権宣言文… 14
1. Introduction
1. 序論
This memo discusses running IP over ATM in an environment where SVCs are used to support QoS flows and RSVP is used as the internet level QoS signaling protocol. It applies when using CLIP/ION, LANE2.0 and MPOA [4] methods for supporting IP over ATM. The general issues related to running RSVP [8] over ATM have been covered in several papers including [9] and other earlier work. This document is intended as a companion to [9,5]. The reader should be familiar with both documents.
このメモは、SVCsがQoS流れを支持するのに使用されるところでATMで環境でIPを経営しているのを議論します、そして、インターネットレベルQoSシグナリングが議定書を作るとき、RSVPは使用されています。 ATMの上でIPを支持するのにCLIP/ION、LANE2.0、およびMPOA[4]方法を使用するとき、それは適用されます。 [9]と他の以前の仕事を含んでいて、数個の書類でATMの上でRSVP[8]を走らせると関連する一般答弁をカバーしています。 このドキュメントは仲間として[9、5]まで意図します。 読者は両方のドキュメントに詳しいはずです。
This document defines the specific requirements for implementations using ATM UNI3.x and 4.0. These requirements must be adhered to by all RSVP over ATM implementations to ensure interoperability. Further recommendations to guide implementers of RSVP over ATM are provided in [5].
このドキュメントは、ATM UNI3.xと4.0を使用することで実現のための決められた一定の要求を定義します。 すべてのRSVPが、相互運用性を確実にするためにATM実現の上でこれらの要件を固く守らなければなりません。 ATMの上にRSVPのimplementersを動かすというさらなる推薦を[5]に提供します。
The rest of this section will define terms and assumptions. Section 2 will cover implementation guidelines common to all RSVP session. Section 3 will cover implementation guidelines specific to multicast sessions.
このセクションの残りは用語と仮定を定義するでしょう。 セクション2はすべてのRSVPセッションに共通の実施要綱をカバーするでしょう。 セクション3はマルチキャストセッションに特定の実施要綱をカバーするでしょう。
1.1 Terms
1.1 用語
The terms "reservation" and "flow" are used in many contexts, often with different meaning. These terms are used in this document with the following meaning:
用語「予約」と「流れ」は多くの文脈でしばしば異なった意味で使用されます。 これらの用語は本書では以下の意味と共に使用されます:
o Reservation is used in this document to refer to an RSVP
initiated request for resources. RSVP initiates requests for
resources based on RESV message processing. RESV messages that
simply refresh state do not trigger resource requests. Resource
requests may be made based on RSVP sessions and RSVP reservation
styles. RSVP styles dictate whether the reserved resources are
used by one sender or shared by multiple senders. See [8] for
details of each. Each new request is referred to in this
document as an RSVP reservation, or simply reservation.
o 予約は参照するこのドキュメントで使用されて、RSVPがリソースに関する要求を開始したということです。 RSVPはRESVメッセージ処理に基づくリソースに関する要求を開始します。 単に状態をリフレッシュするRESVメッセージが資源要求の引き金となりません。 RSVPセッションとRSVP予約スタイルに基づいて資源要求をするかもしれません。 RSVPスタイルは、予約されたリソースが1人の送付者によって使用されるか、または複数の送付者によって共有されるかを決めます。 それぞれの詳細のための[8]を見てください。 それぞれの新しい要求は本書ではRSVPの予約、または単に予約と呼ばれます。
Berger Standards Track [Page 2] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[2ページ]。
o Flow is used to refer to the data traffic associated with a
particular reservation. The specific meaning of flow is RSVP
style dependent. For shared style reservations, there is one
flow per session. For distinct style reservations, there is one
flow per sender (per session).
o 流れは、特定の予約に関連しているデータ通信量を示すのに使用されます。 流れの特定の意味はRSVPスタイル扶養家族です。 共有されたスタイルの予約のために、1セッションあたり1回の流れがあります。 異なったスタイルの予約のために、送付者(1セッションあたりの)あたり1回の流れがあります。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[7]で説明されるように本書では解釈されることであるべきですか?
1.2 Assumptions
1.2 仮定
The following assumptions are made:
以下の仮定はされます:
o RSVP
o RSVP
We assume RSVP as the internet signaling protocol which is
described in [8]. The reader is assumed to be familiar with
[8].
私たちは[8]で説明されるインターネットシグナリングプロトコルとしてRSVPを仮定します。 読者が[8]によく知られさせると思われます。
o IPv4 and IPv6
o IPv4とIPv6
RSVP support has been defined for both IPv4 and IPv6. The
guidelines in this document are intended to be used to support
RSVP with either IPv4 or IPv6. This document does not require
one version over the other.
RSVPサポートはIPv4とIPv6の両方のために定義されました。 本書では、IPv4かIPv6のどちらかと共にRSVPを支持するのにガイドラインが使用されることを意図します。 このドキュメントはもう片方に関して1つのバージョンを必要としません。
o Best effort service model
o ベストエフォート型サービスモデル
The current Internet only supports best effort service. We
assume that as additional components of the Integrated Services
model are defined, best effort service must continue to be
supported.
現在のインターネットはベストエフォート型サービスを支持するだけです。 私たちは、Integrated Servicesモデルの追加部品が定義されるときベストエフォート型サービスが、支持され続けなければならないと思います。
o ATM UNI 3.x and 4.0
o 気圧UNI 3.xと4.0
We assume ATM service as defined by UNI 3.x and 4.0. ATM
provides both point-to-point and point-to-multipoint Virtual
Circuits (VCs) with a specified Quality of Service (QoS). ATM
provides both Permanent Virtual Circuits (PVCs) and Switched
Virtual Circuits (SVCs). In the Permanent Virtual Circuit (PVC)
environment, PVCs are typically used as point-to-point link
replacements. So the support issues are similar to point-to-
point links. This memo assumes that SVCs are used to support
RSVP over ATM.
私たちは、UNI 3.xと4.0によって定義されるようにATMがサービスであると思います。 ATMはポイントツーポイントとポイントツーマルチポイントVirtual Circuitsの両方(VCs)をService(QoS)の指定されたQualityに供給します。 ATMはPermanent Virtual Circuits(PVCs)とSwitched Virtual Circuits(SVCs)の両方を提供します。 Permanent Virtual Circuit(PVC)環境で、PVCsはポイントツーポイント接続交換として通常使用されます。 それで、サポート問題はポイントからポイントへのリンクと同様です。 このメモは、SVCsがATMの上でRSVPを支持するのに使用されると仮定します。
Berger Standards Track [Page 3] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[3ページ]。
2. General RSVP Session Support
2. 一般RSVPセッションサポート
This section provides implementation requirements that are common for all (both unicast and multicast) RSVP sessions. The section covers VC usage, QoS VC initiation, VC teardown, handling requested changes in QoS, and encapsulation.
このセクションはすべての(ユニキャストとマルチキャストの両方)に、一般的な実現要件にRSVPセッションを提供します。 セクションはVC用法、QoS VC開始、QoSにおける要求された変化を扱うVC分解、およびカプセル化を含んでいます。
2.1 RSVP Message VC Usage
2.1 RSVPメッセージVC用法
There are several RSVP Message VC Usage options available to implementers. Implementers must select which VC to use for RSVP messages and how to aggregate RSVP sessions over QoS VCs. These options have been covered in [9] and some specific implementation guidelines are stated in [5]. In order to ensure interoperability between implementations that follow different options, RSVP over ATM implementations MUST NOT send RSVP (control) messages on the same QoS VC as RSVP associated data packets. RSVP over ATM implementations MAY send RSVP messages on either the best effort data path or on a separate control VC.
implementersに利用可能ないくつかのRSVP Message VC Usageオプションがあります。 ImplementersはRSVPメッセージにどのVCを使用するか、そして、どのようにQoS VCsの上のRSVPセッションを集めるかを選択しなければなりません。 [9]でこれらのオプションをカバーしています、そして、いくつかの特定の実施要綱が[5]に述べられています。 異なったオプションに続く実現の間の相互運用性を確実にするために、ATM実現の上のRSVPはRSVP関連データパケットと同じQoS VCでRSVP(コントロール)にメッセージを送ってはいけません。 ATM実現の上のRSVPはベストエフォート型データ経路の上、または、別々のコントロールVCの上でメッセージをRSVPに送るかもしれません。
Since RSVP (control) messages and RSVP associated data packets are not sent on the same VCs, it is possible for a VC supporting one type of traffic to fail while the other remains in place. When the VC associated with data packets fails and cannot be reestablished, RSVP SHOULD treat this as an allocation failure. When the VC used to forward RSVP control messages is abnormally released and cannot be reestablished, the RSVP associated QoS VCs MUST also be released. The release of the associated data VCs is required to maintain the synchronization between forwarding and reservation states for the associated data flows.
RSVP(コントロール)メッセージとRSVP関連データパケットが同じVCsに送られないので、もう片方が適所に残っている間、失敗するように1つのタイプの交通を支持するVCに、それは可能です。 データ・パケットに関連しているVCが失敗して、復職できないとき、RSVP SHOULDは割り振りの失敗としてこれを扱います。 また、コントロールメッセージをRSVPに転送するのに使用されるVCを異常にリリースして、復職させることができないとき、RSVPの関連QoS VCsをリリースしなければなりません。 関連データVCsのリリースが、関連データのための推進と予約州の間の同期が流れると主張するのに必要です。
2.2 VC Initiation
2.2 VC開始
There is an apparent mismatch between RSVP and ATM. Specifically, RSVP control is receiver oriented and ATM control is sender oriented. This initially may seem like a major issue but really is not. While RSVP reservation (RESV) requests are generated at the receiver, actual allocation of resources takes place at the subnet sender.
RSVPとATMの間には、見かけのミスマッチがあります。 明確に、RSVPコントロールは受信機指向しています、そして、ATMコントロールは適応する送付者です。 これは、初めは、主要な問題のように見えるかもしれませんが、本当にありません。 RSVP条件(RESV)要求は受信機で発生しますが、リソースの実際の配分はサブネット送付者で行われます。
For data flows, this means that subnet senders MUST establish all QoS VCs and the RSVP enabled subnet receiver MUST be able to accept incoming QoS VCs. These restrictions are consistent with RSVP version 1 processing rules and allow senders to use different flow to VC mappings and even different QoS renegotiation techniques without interoperability problems. All RSVP over ATM approaches that have VCs initiated and controlled by the subnet senders will interoperate. Figure 1 shows this model of data flow VC initiation.
データフローに関しては、これは、サブネット送付者がすべてのQoS VCsを設立しなければならないことを意味します、そして、可能にされたサブネット受信機ができるに違いないRSVPは入って来るQoS VCsを受け入れます。 これらの制限は、RSVPバージョン1処理規則と一致していて、送付者が相互運用性問題なしでVCマッピングと異なったQoS renegotiationのテクニックさえへの異なった流れを使用するのを許容します。VCsがサブネット送付者によって開始されて、制御されるATMアプローチの上のすべてのRSVPが共同利用するでしょう。 図1はデータフローVC開始のこのモデルを示しています。
Berger Standards Track [Page 4] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[4ページ]。
Data Flow ==========>
データフロー==========>。
+-----+
| | --------------> +----+
| Src | --------------> | R1 |
| *| --------------> +----+
+-----+ QoS VCs
/\
||
VC ||
Initiator
+-----+ | | -------------->+----+ | Src| -------------->| R1| | *| -------------->+----+ +-----+ QoS VCs/\|| VC|| 創始者
Figure 1: Data Flow VC Initiation
図1: データフローVC開始
RSVP over ATM implementations MAY send data in the backwards direction on an RSVP initiated QoS point-to-point VC. When sending in the backwards data path, the sender MUST ensure that the data conforms to the backwards direction traffic parameters. Since the traffic parameters are set by the VC initiator, it is quite likely that no resources will be requested for traffic originating at the called party. It should be noted that the backwards data path is not available with point-to-multipoint VCs.
RSVPに関する遅れている指示のATM実現5月の送信データの上のRSVPはQoSポイントツーポイントVCを開始しました。 遅れているデータ経路を送るとき、送付者は、データが遅れている指示交通パラメタに従うのを保証しなければなりません。 交通パラメタがVC創始者によって設定されるので、リソースは全く被呼者で由来する交通にかなり要求されそうにないでしょう。 遅れているデータ経路がポイントツーマルチポイントVCsと共に利用可能でないことに注意されるべきです。
2.3 VC Teardown
2.3 VC分解
VCs supporting IP over ATM data are typically torndown based on inactivity timers. This mechanism is used since IP is connectionless and there is therefore no way to know when a VC is no longer needed. Since RSVP provides explicit mechanisms (messages and timeouts) to determine when an associated data VC is no longer needed, the traditional VC timeout mechanisms are not needed. Additionally, under normal operations RSVP implementations expect to be able to allocate resources and have those resources remain allocated until released at the direction of RSVP. Therefore, data VCs set up to support RSVP controlled flows should only be released at the direction of RSVP. Such VCs must not be timed out due to inactivity by either the VC initiator or the VC receiver. This conflicts with VCs timing out as described in RFC 1755 [11], section 3.4 on VC Teardown. RFC 1755 recommends tearing down a VC that is inactive for a certain length of time. Twenty minutes is recommended. This timeout is typically implemented at both the VC initiator and the VC receiver. Although, section 3.1 of the update to RFC 1755 [12] states that inactivity timers must not be used at the VC receiver.
通常、ATMデータの上でIPを支持するVCsは不活発タイマに基づくtorndownです。 IPがコネクションレスであり、したがって、VCはいつもう必要でないかを知る方法が全くないので、このメカニズムは使用されています。 RSVPが関連データVCはいつもう必要でないかを決定するために、明白なメカニズム(メッセージとタイムアウト)を提供するので、伝統的なVCタイムアウトメカニズムは必要ではありません。 さらに、リソースを割り当てて、それらのリソースをRSVPの指示に基づきリリースされるまで割り当てたままで残らせることができると通常操作RSVP実現で予想してください。 したがって、データVCsはセットアップします。制御されて、RSVPを支持するために、流れはRSVPの指示に基づきリリースされるだけであるべきです。 そのようなVCsは不活発による外でVC創始者かVC受信機のどちらかによって調節されてはいけません。これはRFC1755[11]の説明されるとしてのVCsタイミングと衝突します、VC Teardownの上のセクション3.4。 RFC1755は、ある長さの時に不活発なVCを取りこわすことを勧めます。 20分はお勧めです。 このタイムアウトがVC創始者とVC受信機の両方で通常実行される、RFC1755[12]へのアップデートのセクション3.1は、VC受信機で不活発タイマを使用してはいけないと述べます。
In RSVP over ATM implementations, the configurable inactivity timer mentioned in [11] MUST be set to "infinite" for VCs initiated at the request of RSVP. Setting the inactivity timer value at the VC initiator should not be problematic since the proper value can be
ATM実現の上のRSVPでは、RSVPの依頼で開始されたVCsのために[11]で言及された構成可能な不活発タイマを「無限」に設定しなければなりません。 固有値が問題が多いことができるので、VC創始者における不活発タイマ価値を設定するのは問題が多いはずがありません。
Berger Standards Track [Page 5] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[5ページ]。
relayed internally at the originator. Setting the inactivity timer at the VC receiver is more difficult, and would require some mechanism to signal that an incoming VC was RSVP initiated. To avoid this complexity and to conform to [12], RSVP over ATM implementations MUST not use an inactivity timer to clear any received connections.
創始者で内部的にリレーされます。 VC受信機に不活発タイマを設定するのは、より難しく、入って来るVCが開始されたRSVPであったと合図するために何らかのメカニズムを必要とするでしょう。 この複雑さを避けて、[12]に従うなら、ATM実現の上のRSVPは、どんな容認された接続もきれいにするのに不活発タイマを使用してはいけません。
2.4 Dynamic QoS
2.4 ダイナミックなQoS
As stated in [9], there is a mismatch in the service provided by RSVP and that provided by ATM UNI3.x and 4.0. RSVP allows modifications to QoS parameters at any time while ATM does not support any modifications to QoS parameters post VC setup. See [9] for more detail.
[9]に述べられているように、ミスマッチがRSVPによって提供されたサービスとATM UNI3.xと4.0提供されたそれにあります。 RSVPはQoSパラメタへのいつでもATMがQoSパラメタへの少しの変更も支持しない間、変更にポストVCセットアップを許します。 その他の詳細のための[9]を見てください。
The method for supporting changes in RSVP reservations is to attempt to replace an existing VC with a new appropriately sized VC. During setup of the replacement VC, the old VC MUST be left in place unmodified. The old VC is left unmodified to minimize interruption of QoS data delivery. Once the replacement VC is established, data transmission is shifted to the new VC, and only then is the old VC closed.
RSVPの予約における変化を支持するための方法は既存のVCを新しい適切に大きさで分けられたVCに取り替えるのを試みることです。 交換VC、老人VC MUSTをセットアップしてください。適所から、変更されていないままにされます。 古いVCはQoSデータ配送の中断を最小にするために変更されていないままにされます。 一度、交換VCは設立されます、そして、データ伝送は新しいVCに移行します、そして、次に、古いVCは閉じられるだけです。
If setup of the replacement VC fails, then the old QoS VC MUST continue to be used. When the new reservation is greater than the old reservation, the reservation request MUST be answered with an error. When the new reservation is less than the old reservation, the request MUST be treated as if the modification was successful. While leaving the larger allocation in place is suboptimal, it maximizes delivery of service to the user. The behavior is also required in order to conform to RSVP error handling as defined in sections 2.5, 3.1.8 and 3.11.2 of [8]. Implementations SHOULD retry replacing a too large VC after some appropriate elapsed time.
交換VCのセットアップが失敗するなら、古いQoS VCは、使用され続けなければなりません。 新しい予約が古い予約より大きいときに、誤りで予約の要請に答えなければなりません。 新しい予約が古い予約以下であるときに、まるで変更がうまくいくかのように要求を扱わなければなりません。 適所により大きい配分を残すのは準最適ですが、それはユーザに対するサービスの配送を最大にします。 また、振舞いが、[8]についてセクション2.5、3.1.8と3.11で.2を定義するときRSVPエラー処理に従うのに必要です。 実現SHOULDは、いくつかの適切な経過時間の後に大き過ぎるVCを取り替えながら、再試行します。
One additional issue is that only one QoS change can be processed at one time per reservation. If the (RSVP) requested QoS is changed while the first replacement VC is still being setup, then the replacement VC SHOULD BE released and the whole VC replacement process is restarted. Implementations MAY also limit number of changes processed in a time period per [9].
1つの追加設定はひところ予約単位で1つのQoS変化しか処理できないということです。 最初の交換VCがまだセットアップである間、(RSVP)要求されたQoSを変えるなら、VC SHOULD BEがリリースした交換と全体のVC交換の過程を再開します。 また、実現は1[9]あたり1回の期間に処理された変化の数を制限するかもしれません。
2.5 Encapsulation
2.5 カプセル化
There are multiple encapsulation options for data sent over RSVP triggered QoS VCs. All RSVP over ATM implementations MUST be able to support LLC encapsulation per RFC 1483 [10] on such QoS VCs. Implementations MAY negotiate alternative encapsulations using the B-LLI negotiation procedures defined in ATM Signalling, see [11] for
データのためのオプションがRSVPの上で引き起こされたQoS VCsを送った複数のカプセル化があります。 ATM実現の上のすべてのRSVPがそのようなQoS VCsでRFC1483[10]あたりのLLCカプセル化を支持できなければなりません。 手順がATM Signallingで定義して、[11]を見るB-LLI交渉を使用して、実現は代替のカプセル化を交渉するかもしれません。
Berger Standards Track [Page 6] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[6ページ]。
details. When a QoS VC is only being used to carry IP packets, implementations SHOULD negotiate VC based multiplexing to avoid incurring the overhead of the LLC header.
詳細。 QoS VCがIPパケットを運ぶのに使用されているだけであるとき、実現SHOULDはLLCヘッダーのオーバーヘッドを被るのを避けるために多重送信しながら基づくVCを交渉します。
3. Multicast RSVP Session Support
3. マルチキャストRSVPセッションサポート
There are several aspects to running RSVP over ATM that are unique to multicast sessions. This section addresses multicast end-point identification, multicast data distribution, multicast receiver transitions and next-hops requesting different QoS values (heterogeneity) which includes the handling of multicast best effort receivers. Handling of best effort receivers is not strictly an RSVP issue, but needs to be addressed by any RSVP over ATM implementation in order to maintain expected best effort internet service.
マルチキャストセッションにユニークなATMの上に走行RSVPへのいくつかの局面があります。 異なったQoSがマルチキャストのベストエフォート型受信機の取り扱いを含んでいる(異種性)を評価するよう要求しながら、このセクションはマルチキャストエンドポイント識別、マルチキャスト情報配給、マルチキャスト受信機変遷、および次のホップを記述します。 ベストエフォート型受信機の取り扱いは厳密にそうではありません。しかし、RSVP問題、予想されたベストエフォート型インターネットサービスを維持するためにATM実現の上にどんなRSVPによっても記述されるべき必要性。
3.1 Data VC Management for Heterogeneous Sessions
3.1 異種のセッションのためのデータVC管理
The issues relating to data VC management of heterogeneous sessions are covered in detail in [9]. In summary, heterogeneity occurs when receivers request different levels of QoS within a single session, and also when some receivers do not request any QoS. Both types of heterogeneity are shown in figure 2.
異種のセッションのデータVC管理に関連する問題は[9]で詳細にカバーされています。 受信機がただ一つのセッション以内のQoSについて異なったレベルを要求して、また、いくつかの受信機が少しのQoSも要求しないとき要求するとき、概要では、異種性は起こります。 異種性の両方のタイプは2が中で計算するのが示されます。
+----+
+------> | R1 |
| +----+
|
| +----+
+-----+ -----+ +--> | R2 |
| | ---------+ +----+ Receiver Request Types:
| Src | ----> QoS 1 and QoS 2
| | .........+ +----+ ....> Best-Effort
+-----+ .....+ +..> | R3 |
: +----+
/\ :
|| : +----+
|| +......> | R4 |
|| +----+
Single
IP Mulicast
Group
+----+ +------>| R1| | +----+ | | +----+ +-----+ -----+ +-->。| R2| | | ---------+ +----+ 受信機要求タイプ: | Src| ---->QoS1とQoS2| | .........+ +----+ ....>のベストエフォート型+-----+ .....+ +..>| R3| : +----+ /\ : || : +----+ || +......>| R4| || +----+ ただ一つのIP Mulicastグループ
Figure 2: Types of Multicast Receivers
図2: マルチキャスト受信機のタイプ
[9] provides four models for dealing with heterogeneity: full heterogeneity, limited heterogeneity, homogeneous, and modified homogeneous models. No matter which model or combination of models is used by an implementation, implementations MUST NOT normally send
[9]は4つのモデルを異種性に対処するのに提供します: 完全な異種性、限られた異種性、均質の、そして、変更された均質モデル。 モデルのどのモデルか組み合わせが実現で使用されても、通常、実現は発信してはいけません。
Berger Standards Track [Page 7] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[7ページ]。
more than one copy of a particular data packet to a particular next- hop (ATM end-point). Some transient duplicate transmission is acceptable, but only during VC setup and transition.
次の特定のホップ(ATMエンドポイント)への特定のデータ・パケットのコピー複数の部。 許容できますがVCセットアップと変遷だけの間何らかの一時的な写し送信。
Implementations MUST also ensure that data traffic is sent to best effort receivers. Data traffic MAY be sent to best effort receivers via best effort or QoS VCs as is appropriate for the implemented model. In all cases, implementations MUST NOT create VCs in such a way that data cannot be sent to best effort receivers. This includes the case of not being able to add a best effort receiver to a QoS VC, but does not include the case where best effort VCs cannot be setup. The failure to establish best effort VCs is considered to be a general IP over ATM failure and is therefore beyond the scope of this document.
また、実現は、データ通信量がベストエフォート型受信機に送られるのを確実にしなければなりません。 そのままでベストエフォート型を通したベストエフォート型受信機かQoS VCsにデータ通信量を実行されたモデルに適切な状態で送るかもしれません。 すべての場合では、実現はベストエフォート型受信機にデータを送ることができないような方法でVCsを作成してはいけません。 これは、ベストエフォート型受信機をQoS VCに加えることができないケースを含んでいますが、ベストエフォート型VCsがセットアップであるはずがないケースは含んでいません。 ベストエフォート型VCsを設立しない場合、ATMの故障の上の一般的なIPであると考えられて、したがって、このドキュメントの範囲を超えています。
There is an interesting interaction between dynamic QoS and heterogeneous requests when using the limited heterogeneity, homogeneous, or modified homogeneous models. In the case where a RESV message is received from a new next-hop and the requested resources are larger than any existing reservation, both dynamic QoS and heterogeneity need to be addressed. A key issue is whether to first add the new next-hop or to change to the new QoS. This is a fairly straight forward special case. Since the older, smaller reservation does not support the new next-hop, the dynamic QoS process SHOULD be initiated first. Since the new QoS is only needed by the new next-hop, it SHOULD be the first end-point of the new VC. This way signaling is minimized when the setup to the new next-hop fails.
限られた異種性を使用するとき、ダイナミックなQoSと異種の要求とのおもしろい相互作用があります、均質の、または、変更された均質モデル。 新しい次のホップからRESVメッセージを受け取って、要求されたリソースがどんな既存の予約よりも大きい場合では、ダイナミックなQoSと異種性の両方が、記述される必要があります。 主要な問題は最初に、新しい次のホップを加えるか、または新しいQoSに変化するということです。 これはかなりまっすぐな前進の特別なそうです。 より古くて、より小さい予約以来、新しさが次に飛び越すサポート、ダイナミックなQoSの過程SHOULDは最初に、開始されませんか? 新しさ以来、QoSは新しい次のホップによって必要とされるだけであり、それはSHOULDです。新しさVCの最初のエンドポイントになってください。 このように、新しい次のホップへのセットアップが失敗すると、シグナリングは最小にされます。
3.2 Multicast End-Point Identification
3.2 マルチキャストエンドポイント識別
Implementations must be able to identify ATM end-points participating in an IP multicast group. The ATM end-points will be IP multicast receivers and/or next-hops. Both QoS and best effort end-points must be identified. RSVP next-hop information will usually provide QoS end-points, but not best effort end-points.
実現はIPマルチキャストグループに参加するATMエンドポイントを特定できなければなりません。 ATMエンドポイントは、IPマルチキャスト受信機、そして/または、次のホップになるでしょう。 QoSとベストエフォート型エンドポイントの両方を特定しなければなりません。 通常、RSVP次のホップ情報はベストエフォート型エンドポイントではなく、エンドポイントをQoSに供給するでしょう。
There is a special case where RSVP next-hop information will not provide the appropriate end-points. This occurs when a next-hop is not RSVP capable and RSVP is being automatically tunneled. In this case a PATH message travels through a non-RSVP egress router on the way to the next-hop RSVP node. When the next-hop RSVP node sends a RESV message it may arrive at the source via a different route than used by the PATH message. The source will get the RESV message, but will not know which ATM end-point should be associated with the reservation. For unicast sessions, there is no problem since the ATM end-point will be the IP next-hop router. There is a problem with
特別なケースがRSVP次のホップ情報が適切なエンドポイントを提供しないところにあります。 次のホップができるRSVPでなく、RSVPが自動的にトンネルを堀られているとき、これは起こります。 この場合、PATHメッセージは非RSVP出口ルータを通って次のホップRSVPノードへの途中に移動します。 次のホップRSVPノードがRESVメッセージを送るとき、それはPATHメッセージによって使用されるのと異なったルートでソースに到着するかもしれません。 情報筋は、RESVメッセージを得ますが、どのATMエンドポイントが予約に関連しているべきであるかを知らないでしょう。 ユニキャストセッションの間、ATMエンドポイントがIP次のホップルータになるので、問題が全くありません。 問題があります。
Berger Standards Track [Page 8] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[8ページ]。
multicast, since multicast routing may not be able to uniquely identify the IP next-hop router. It is therefore possible for a multicast end-point to not be properly identified.
マルチキャストルーティングが唯一IP次のホップルータを特定できないかもしれなくて以来のマルチキャスト。 したがって、マルチキャストエンドポイントが適切に特定されないのは、可能です。
In certain cases it is also possible to identify the list of all best effort end-points. Some multicast over ATM control mechanisms, such as MARS in mesh mode, can be used to identify all end-points of a multicast group. Also, some multicast routing protocols can provide all next-hops for a particular multicast group. In both cases, RSVP over ATM implementations can obtain a full list of end-points, both QoS and non-QoS, using the appropriate mechanisms. The full list can then be compared against the RSVP identified end-points to determine the list of best effort receivers.
ある場合には、また、すべてのベストエフォート型エンドポイントのリストを特定するのも可能です。 マルチキャストグループのすべてのエンドポイントを特定するのに、ATM制御機構の上の何らかのマルチキャスト(メッシュの火星などのモード)を使用できます。 また、いくつかのマルチキャストルーティング・プロトコルがすべての次のホップを特定のマルチキャストグループに提供できます。 どちらの場合も、ATM実現の上のRSVPはエンドポイントに関する完全リスト、QoSと非QoSの両方を入手できます、適切な手段を使用して。次に、リストを決定する特定されたエンドポイントのRSVPのベストエフォート型受信機に対して完全リストは比較できます。
While there are cases where QoS and best effort end-points can be identified, there is no straightforward solution to uniquely identifying end-points of multicast traffic handled by non-RSVP next-hops. The preferred solution is to use multicast control mechanisms and routing protocols that support unique end-point identification. In cases where such mechanisms and routing protocols are unavailable, all IP routers that will be used to support RSVP over ATM should support RSVP. To ensure proper behavior, baseline RSVP over ATM implementations MUST only establish RSVP-initiated VCs to RSVP capable end-points. It is permissible to allow a user to override this behavior.
ケースがQoSとベストエフォート型エンドポイントを特定できるところにありますが、唯一次のホップで非RSVPによって扱われたマルチキャスト交通のエンドポイントを特定するどんな簡単な解決策もありません。 都合のよい解決策はユニークなエンドポイント識別を支持するマルチキャスト制御機構とルーティング・プロトコルを使用することです。 そのようなメカニズムとルーティング・プロトコルが入手できない場合では、ATMの上でRSVPを支持するのに使用されるすべてのIPルータがRSVPを支持するべきです。 適切な振舞いを確実にするために、ATM実現の上の基線RSVPはRSVPのできるエンドポイントにRSVPによって開始されたVCsを設立するだけでよいです。 ユーザがこの振舞いをくつがえすのを許容するのは許されています。
3.3 Multicast Data Distribution
3.3 マルチキャスト情報配給
Two basic models exist for IP multicast data distribution over ATM. In one model, senders establish point-to-multipoint VCs to all ATM attached destinations, and data is then sent over these VCs. This model is often called "multicast mesh" or "VC mesh" mode distribution. In the second model, senders send data over point-to- point VCs to a central point and the central point relays the data onto point-to-multipoint VCs that have been established to all receivers of the IP multicast group. This model is often referred to as "multicast server" mode distribution. Figure 3 shows data flow for both modes of IP multicast data distribution.
2人の基本型がATMの上のIPマルチキャスト情報配給のために存在します。 1つのモデルでは、送付者はすべてのATMの付属目的地にポイントツーマルチポイントVCsを設立します、そして、次に、これらのVCsの上にデータを送ります。 このモデルはしばしば「マルチキャストメッシュ」か「VCメッシュ」モード分配と呼ばれます。 第2代モデルでは、主要なポイントと主要なポイントへのポイントからポイントの上の送付者送信データVCsはIPマルチキャストグループのすべての受信機に設立されたポイントツーマルチポイントVCsにデータをリレーします。 このモデルはしばしば「マルチキャストサーバ」モード分配と呼ばれます。 図3はIPマルチキャスト情報配給の両方の方法のためのデータフローを示しています。
Berger Standards Track [Page 9] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[9ページ]。
_________
/ \
/ Multicast \
\ Server /
\_________/
^ | |
| | +--------+
+-----+ | | |
| | -------+ | | Data Flow:
| Src | ...+......|....+ V ----> Server
| | : | : +----+ ....> Mesh
+-----+ : | +...>| R1 |
: | +----+
: V
: +----+
+..> | R2 |
+----+
_________ /\/マルチキャスト\\サーバ/\_________/ ^ | | | | +--------+ +-----+ | | | | | -------+ | | データは流れます: | Src| ...+......|....+ V---->サーバ| | : | : +----+ ....>メッシュ+-----+ : | +...>| R1| : | +----+ : V: +----+ +..>| R2| +----+
Figure 3: IP Multicast Data Distribution Over ATM
図3: 気圧でのIPマルチキャスト情報配給
The goal of RSVP over ATM solutions is to ensure that IP multicast data is distributed with appropriate QoS. Current multicast servers [1,2] do not support any mechanisms for communicating QoS requirements to a multicast server. For this reason, RSVP over ATM implementations SHOULD support "mesh-mode" distribution for RSVP controlled multicast flows. When using multicast servers that do not support QoS requests, a sender MUST set the service, not global, break bit(s). Use of the service-specific break bit tells the receiver(s) that RSVP and Integrated Services are supported by the router but that the service cannot be delivered over the ATM network for the specific request.
ATM解決策の上のRSVPの目標はIPマルチキャストデータが適切なQoSと共に分配されるのを保証することです。 現在のマルチキャストサーバ[1、2]は、QoS要件をマルチキャストサーバに伝えるためにどんなメカニズムもサポートしません。この理由で、RSVPのためのATM実現SHOULDサポート「メッシュモード」分配の上のRSVPはマルチキャスト流れを制御しました。 QoS要求を支持しないマルチキャストサーバを使用するとき、送付者はグローバルな中断ビットではなく、サービスを設定しなければなりません。 サービス特有の中断ビットの使用は、RSVPとIntegrated Servicesがルータによって支持されますが、特定の要求のためにATMネットワークの上にサービスを提供できないと受信機に言います。
In the case of MARS [1], the selection of distribution modes is administratively controlled. Therefore network administrators that desire proper RSVP over ATM operation MUST appropriately configure their network to support mesh mode distribution for multicast groups that will be used in RSVP sessions. For LANE1.0 networks the only multicast distribution option is over the LANE Broadcast and Unknown Server which means that the break bit MUST always be set. For LANE2.0 [3] there are provisions that allow for non-server solutions with which it may be possible to ensure proper QoS delivery.
火星[1]の場合では、分配モードの品揃えは行政上制御されます。 したがって、ATM操作の上で適切なRSVPを望んでいるネットワーク管理者は、RSVPセッションのときに使用されるマルチキャストグループのためにメッシュモード分配を支持するために適切に彼らのネットワークを構成しなければなりません。 LANE1.0ネットワークにおいて、いつも中断ビットを設定しなければならないことを意味するレーンのBroadcastとUnknown Serverの上に唯一のマルチキャスト分配オプションがあります。 LANE2.0[3]のために、適切なQoS配送を確実にするのが可能であるかもしれない非サーバソリューションを考慮する条項があります。
Berger Standards Track [Page 10] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[10ページ]。
3.4 Receiver Transitions
3.4 受信機変遷
When setting up a point-to-multipoint VCs there will be a time when some receivers have been added to a QoS VC and some have not.
ポイントツーマルチポイントをセットアップするとき、そこのVCsはいくつかの受信機がQoS VCに加えられる時になるでしょう、そして、何かはそのような時ではありません。
During such transition times it is possible to start sending data on the newly established VC. If data is sent both on the new VC and the old VC, then data will be delivered with proper QoS to some receivers and with the old QoS to all receivers. Additionally, the QoS receivers would get duplicate data. If data is sent just on the new QoS VC, the receivers that have not yet been added will miss data. So, the issue comes down to whether to send to both the old and new VCs, or to just send to one of the VCs. In one case duplicate data will be received, in the other some data may not be received. This issue needs to be considered for three cases: when establishing the first QoS VC, when establishing a VC to support a QoS change, and when adding a new end-point to an already established QoS VC.
そのようなトランジッションタイムの間、新設されたVCにデータを送り始めるのは可能です。 新しいVCと古いVCにデータを送ると、いくつかの受信機への適切なQoSとすべての受信機への古いQoSと共にデータを送るでしょう。 さらに、QoS受信機は重複データを得るでしょう。 まさしく新しいQoS VCにデータを送ると、まだ加えられていない受信機はデータを逃すでしょう。 それで、問題は両方の古くて新しいVCsに発信するか、またはただVCsの1つに発信するかまで来ます。 ある場合では、重複データを受け取って、もう片方では、いくつかのデータは受け取らないかもしれません。 この問題は、3つのケースのために考えられる必要があります: QoSが変えるサポート、既に確立したQoS VCに新しいエンドポイントを加える時VCを設立するのに、最初のQoS VCを設立するとき。
The first two cases are essentially the same. In both, it is possible to send data on the partially completed new VC. In both, there is the option of duplicate or lost data. In order to ensure predictable behavior and to conform to the requirement to deliver data to all receivers, data MUST NOT be sent on new VCs until all parties have been added. This will ensure that all data is only delivered once to all receivers.
最初の2つのケースが本質的には同じです。 両方では、部分的に完成した新しいVCにデータを送るのは可能です。 両方に、写しかロストデータのオプションがあります。 予測できる振舞いを確実にして、すべての受信機にデータを渡すという要件に従うために、すべてのパーティーが加えられるまで、新しいVCsにデータを送ってはいけません。 これは、すべてのデータが一度すべての受信機に渡されるだけであるのを確実にするでしょう。
The last case differs from the others and occurs when an end-point must be added to an existing QoS VC. In this case the end-point must be both added to the QoS VC and dropped from a best effort VC. The issue is which to do first. If the add is first requested, then the end-point may get duplicate data. If the drop is requested first, then the end-point may miss data. In order to avoid loss of data, the add MUST be completed first and then followed by the drop. This behavior requires receivers to be prepared to receive some duplicate packets at times of QoS setup.
最後のケースは、他のものと異なっていて、既存のQoS VCにエンドポイントを加えなければならないとき、浮かびます。 この場合、エンドポイントをQoS VCに加えられて、ベストエフォート型VCから落とさなければなりません。 問題は最初にどれをするかということです。 1番目が要求されていて、次に、エンドポイントが重複データを得るかもしれないと言い足してください。 低下が最初に要求されるなら、エンドポイントはデータを逃すかもしれません。 データの喪失を避けてください、最初に、終了しなければならなくて、低下がその時続いたと言い足してください。 この振舞いは、受信機が時にはQoSセットアップについていくつかの写しパケットを受けるように準備されるのを必要とします。
4. Security Considerations
4. セキュリティ問題
The same considerations stated in [8] and [11] apply to this document. There are no additional security issues raised in this document.
[8]と[11]に述べられた同じ問題はこのドキュメントに適用されます。 本書では提起された追加担保問題が全くありません。
5. Acknowledgments
5. 承認
This work is based on earlier drafts and comments from the ISSLL working group. The author would like to acknowledge their contribution, most notably Steve Berson who coauthored one of the drafts.
この仕事はISSLLワーキンググループからの以前の草稿とコメントに基づいています。 作者は彼らの貢献、最も著しく草稿の1つについて共同執筆したスティーブBersonを承認したがっています。
Berger Standards Track [Page 11] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[11ページ]。
6. Author's Address
6. 作者のアドレス
Lou Berger FORE Systems 1595 Spring Hill Road 5th Floor Vienna, VA 22182
ルウバーガー前面のシステム1595スプリングヒル道路第5Floorウィーン、ヴァージニア 22182
Phone: +1 703-245-4527 EMail: lberger@fore.com
以下に電話をしてください。 +1 703-245-4527 メールしてください: lberger@fore.com
Berger Standards Track [Page 12] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[12ページ]。
REFERENCES
参照
[1] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
Networks," RFC 2022, November 1996.
[1] アーミテージ、G.、「UNI3.0/3.1の上のMulticastのサポートはATM Networksを基礎づけた」RFC2022、1996年11月。
[2] The ATM Forum, "LAN Emulation Over ATM Specification", Version
1.0.
[2] 気圧フォーラム、「気圧仕様の上のLANエミュレーション」、バージョン1.0。
[3] The ATM Forum, "LAN Emulation over ATM Version 2 - LUNI
Specification", April 1997.
[3] 気圧フォーラム、「気圧バージョン2の上のLANエミュレーション--、ルーニ仕様、」、4月1997日
[4] The ATM Forum, "MPOA Baseline Version 1", May 1997.
[4] 気圧フォーラム、「MPOA、基線バージョン1インチと、1997インチ年5月。
[5] Berger, L., "RSVP over ATM Implementation Guidelines", BCP 24,
RFC 2379, August 1998.
[5] バーガー、L.、「気圧実施要綱の上のRSVP」、BCP24、RFC2379、1998年8月。
[6] Borden, M., and M. Garrett, "Interoperation of Controlled-Load
and Guaranteed-Service with ATM", RFC 2381, August 1998.
[6]ボーデン、M.、およびM.ギャレット、「気圧がある制御負荷と保証されたサービスのInteroperation」、RFC2381、1998年8月。
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[8] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[8] ブレーデン、R.、チャン、L.、Berson、S.、ハーツォグ、S.、およびS.ジャマン、「資源予約は(RSVP)について議定書の中で述べます--バージョン1の機能的な仕様」、RFC2205、1997年9月。
[9] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and
J. Krawczyk, "A Framework for Integrated Services and RSVP over
ATM", RFC 2382, August 1998.
[9] クローリー、E.、バーガー、L.、Berson、S.、ベイカー、F.、ボーデン、M.、およびJ.Krawczyk、「気圧での統合サービスとRSVPのための枠組み」、RFC2382(1998年8月)。
[10] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation
Layer 5", RFC 1483, July 1993.
[10] Heinanen、J.、「気圧適合の上のMultiprotocolカプセル化は1993年7月に5インチ、RFC1483を層にします」。
[11] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and
A. Malis, "ATM Signalling Support for IP over ATM", RFC 1755,
February 1995.
[11] ペレス、M.、Liaw、F.、グロースマン、D.、マンキン、A.、ホフマン、E.、およびA.Malis、「気圧でのIPの気圧合図サポート」、RFC1755(1995年2月)。
[12] Maher, M., "ATM Signalling Support for IP over ATM - UNI 4.0
Update", RFC 2331, April 1998.
[12] マーヘル、M.、「気圧でUNI4.0にIPのサポートを示す気圧、アップデート、」、RFC2331、4月1998日
Berger Standards Track [Page 13] RFC 2380 RSVP over ATM Implementation Requirements August 1998
バーガーStandardsは1998年8月に気圧実現要件の上でRFC2380RSVPを追跡します[13ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (1998). All Rights Reserved.
Copyright(C)インターネット協会(1998)。 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.
このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Berger Standards Track [Page 14]
バーガー標準化過程[14ページ]
一覧
スポンサーリンク
