RFC4687 日本語訳
4687 Operations and Management (OAM) Requirements forPoint-to-Multipoint MPLS Networks. S. Yasukawa, A. Farrel, D. King,T. Nadeau. September 2006. (Format: TXT=30486 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Yasukawa
Request for Comments: 4687 NTT Corporation
Category: Informational A. Farrel
Old Dog Consulting
D. King
Aria Networks Ltd.
T. Nadeau
Cisco Systems, Inc.
September 2006
Yasukawaがコメントのために要求するワーキンググループS.をネットワークでつないでください: 4687年のNTT社のカテゴリ: 犬のコンサルティングD.キングアリアネットワーク株式会社T.ナドーシスコシステムズInc.2006年9月に年取った情報のA.ファレル
Operations and Management (OAM) Requirements
for Point-to-Multipoint MPLS Networks
ポイントツーマルチポイントMPLSネットワークのための操作と管理(OAM)要件
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
Abstract
要約
Multi-Protocol Label Switching (MPLS) has been extended to encompass point-to-multipoint (P2MP) Label Switched Paths (LSPs). As with point-to-point MPLS LSPs, the requirement to detect, handle, and diagnose control and data plane defects is critical.
マルチプロトコルLabel Switching(MPLS)は、ポイントツーマルチポイント(P2MP)ラベルSwitched Paths(LSPs)を取り囲むために広げられました。 ポイントツーポイントMPLS LSPsのように、コントロールとデータ飛行機欠陥を検出して、扱って、診断するという要件は批判的です。
For operators deploying services based on P2MP MPLS LSPs, the detection and specification of how to handle those defects are important because such defects not only may affect the fundamentals of an MPLS network, but also may impact service level specification commitments for customers of their network.
そのような欠陥がMPLSネットワークの原理に影響するかもしれないだけではないので、P2MP MPLS LSPsに基づくサービスを配備しているオペレータにとって、どうそれらの欠陥を扱うかに関する検出と仕様は重要ですが、衝撃サービスが彼らのネットワークの顧客のために仕様委任をまた平らにしますように。
This document describes requirements for data plane operations and management for P2MP MPLS LSPs. These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs and multicast LSPs.
このドキュメントはデータ飛行機操作のための要件とP2MP MPLS LSPsのための管理について説明します。 これらの要件は、P2MP MPLS LSPsのすべてのフォームに適用して、P2MP Traffic Engineered(TE)LSPsとマルチキャストLSPsを含んでいます。
Yasukawa, et al. Informational [Page 1] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[1ページ]のRFC4687OAM Reqs
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
2.1. Conventions Used in This Document ..........................3
2.2. Terminology ................................................3
2.3. Acronyms ...................................................3
3. Motivations .....................................................4
4. General Requirements ............................................4
4.1. Detection of Label Switch Path Defects .....................5
4.2. Diagnosis of a Broken Label Switch Path ....................6
4.3. Path Characterization ......................................6
4.4. Service Level Agreement Measurement ........................7
4.5. Frequency of OAM Execution .................................8
4.6. Alarm Suppression, Aggregation, and Layer Coordination .....8
4.7. Support for OAM Interworking for Fault Notification ........8
4.8. Error Detection and Recovery ...............................9
4.9. Standard Management Interfaces .............................9
4.10. Detection of Denial of Service Attacks ...................10
4.11. Per-LSP Accounting Requirements ..........................10
5. Security Considerations ........................................10
6. References .....................................................11
6.1. Normative References ......................................11
6.2. Informative References ....................................11
7. Acknowledgements ...............................................12
1. 序論…3 2. 用語…3 2.1. このドキュメントで中古のコンベンション…3 2.2. 用語…3 2.3. 頭文字語…3 3. 動機…4 4. 一般要件…4 4.1. ラベルスイッチ経路の検出は亡命されます…5 4.2. 起伏の多いラベルスイッチ経路の診断…6 4.3. 経路特殊化…6 4.4. 平らな協定測定を修理してください…7 4.5. OAM実行の頻度…8 4.6. 抑圧、集合、および層のコーディネートを驚かせてください…8 4.7. 欠点によって通知を織り込むOAMのために、支持します。8 4.8. 誤り検出と回復…9 4.9. 標準の管理は連結します…9 4.10. サービス妨害の検出は攻撃されます…10 4.11. 1LSPあたりの会計要件…10 5. セキュリティ問題…10 6. 参照…11 6.1. 標準の参照…11 6.2. 有益な参照…11 7. 承認…12
Yasukawa, et al. Informational [Page 2] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[2ページ]のRFC4687OAM Reqs
1. Introduction
1. 序論
This document describes requirements for data plane operations and management (OAM) for point-to-multipoint (P2MP) Multi-Protocol Label Switching (MPLS). This document specifies OAM requirements for P2MP MPLS, as well as for applications of P2MP MPLS.
このドキュメントはポイントツーマルチポイント(P2MP)マルチプロトコルLabel Switching(MPLS)のためにデータ飛行機操作と管理(OAM)のための要件について説明します。 このドキュメントはP2MP MPLS、およびP2MP MPLSのアプリケーションのためのOAM要件を指定します。
These requirements apply to all forms of P2MP MPLS LSPs, and include P2MP Traffic Engineered (TE) LSPs [RFC4461] and [P2MP-RSVP], as well as multicast LDP LSPs [MCAST-LDP].
これらの要件は、P2MP MPLS LSPsのすべてのフォームに適用して、P2MP Traffic Engineered LSPs[RFC4461]と[P2MP-RSVP](TE)を含んでいます、マルチキャスト自由民主党LSPs[MCAST-自由民主党]と同様に。
Note that the requirements for OAM for P2MP MPLS build heavily on the requirements for OAM for point-to-point MPLS. These latter requirements are described in [RFC4377] and are not repeated in this document.
P2MP MPLSのためのOAMのための要件がポイントツーポイントMPLSのためにOAMのための要件に大いに建てることに注意してください。 これらの後者の要件は、[RFC4377]で説明されて、本書では繰り返されません。
For a generic framework for OAM in MPLS networks, refer to [RFC4378].
MPLSネットワークにおけるOAMのための一般的な枠組みについて、[RFC4378]を参照してください。
2. Terminology
2. 用語
2.1. Conventions Used in This Document
2.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 [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[RFC2119]で説明されるように本書では解釈されることであるべきですか?
The requirements in this document apply to OAM mechanism and protocol development, as opposed to the usual application of RFC 2119 requirements to an actual protocol, as this document does not specify a protocol.
要件は本書ではOAMメカニズムとプロトコル開発に適用されます、実際のプロトコルへのRFC2119要件の普通のアプリケーションと対照的に、このドキュメントがプロトコルを指定しないとき。
2.2. Terminology
2.2. 用語
Definitions of key terms for MPLS OAM are found in [RFC4377] and the reader is assumed to be familiar with those definitions, which are not repeated here.
MPLS OAMに、主要な用語の定義は[RFC4377]で見つけられます、そして、読者がそれらの定義によく知られさせると思われます。(定義はここで繰り返されません)。
[RFC4461] includes some important definitions and terms for use within the context of P2MP MPLS. The reader should be familiar with at least the terminology section of that document.
[RFC4461]はP2MP MPLSの文脈の中の使用のためのいくつかの重要な定義と用語を含んでいます。 読者は少なくともそのドキュメントの用語部に詳しいはずです。
2.3. Acronyms
2.3. 頭文字語
The following acronyms are used in this document.
以下の頭文字語は本書では使用されます。
CE: Customer Edge DoS: Denial of service ECMP: Equal Cost Multipath
Ce: 顧客縁のDoS: サービスECMPの否定: 等しい費用多重通路
Yasukawa, et al. Informational [Page 3] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[3ページ]のRFC4687OAM Reqs
LDP: Label Distribution Protocol LSP: Label Switched Path LSR: Label Switching Router OAM: Operations and Management RSVP: Resource reSerVation Protocol P2MP: Point-to-Multipoint SP: Service Provider TE: Traffic Engineering
自由民主党: プロトコルLSPと分配をラベルしてください: ラベルは経路LSRを切り換えました: 切り換えルータOAMをラベルしてください: 操作と管理RSVP: 資源予約プロトコルP2MP: ポイントツーマルチポイントSP: サービスプロバイダーTe: 交通工学
3. Motivations
3. 動機
OAM for MPLS networks has been established as a fundamental requirement both through operational experience and through its documentation in numerous Internet Drafts. Many such documents (for example, [RFC4379], [RFC3812], [RFC3813], [RFC3814], and [RFC3815]) developed specific solutions to individual issues or problems. Coordination of the full OAM requirements for MPLS was achieved by [RFC4377] in recognition of the fact that the previous piecemeal approach could lead to inconsistent and inefficient applicability of OAM techniques across the MPLS architecture, and might require significant modifications to operational procedures and systems in order to provide consistent and useful OAM functionality.
MPLSネットワークのためのOAMは運用経験を通して多数のインターネットDraftsのそのドキュメンテーションを通して基本的な要件と書き立てられました。 そのような多くのドキュメント(例えば、RFC4379、RFC3812、RFC3813、RFC3814、およびRFC3815)が個々の問題か問題の特定の解決策を見いだしました; MPLSに、完全なOAM要件のコーディネートは前の個別的アプローチがMPLS構造の向こう側にOAMのテクニックの矛盾して効率の悪い適用性につながることができて、一貫して役に立つOAMの機能性を提供するために操作手順とシステムへの重要な変更を必要とするかもしれないという事実の認識でRFC4377によって達成されました。
This document builds on these realizations and extends the statements of MPLS OAM requirements to cover the new area of P2MP MPLS. That is, this document captures the requirements for P2MP MPLS OAM in advance of the development of specific solutions.
このドキュメントは、これらの実現のときに建てて、P2MP MPLSの新しい領域をカバーするというMPLS OAM要件の声明を広げています。 すなわち、このドキュメントは特定の解決策の開発の前にP2MP MPLS OAMのための要件を得ます。
Nevertheless, at the time of writing, some effort had already been expended to extend existing MPLS OAM solutions to cover P2MP MPLS (for example, [P2MP-LSP-PING]). While this approach of extending existing solutions may be reasonable, in order to ensure a consistent OAM framework it is necessary to articulate the full set of requirements in a single document. This will facilitate a uniform set of MPLS OAM solutions spanning multiple MPLS deployments and concurrent applications.
それにもかかわらず、これを書いている時点で、P2MP MPLS(例えば、[P2MP-LSP-PING])を覆うために既存のMPLS OAM解決策を広げるために既に何らかの努力を費やしてありました。 既存の解決策を広げるこのアプローチは合理的であるかもしれませんが、一貫したOAM枠組みを確実にするために、ただ一つのドキュメントにおける、要件のフルセットについて明確に話すのが必要です。 これは複数のMPLS展開と共存出願にかかる一定のMPLS OAM解決策を容易にするでしょう。
4. General Requirements
4. 一般要件
The general requirements described in this section are similar to those described for point-to-point MPLS in [RFC4377]. The subsections below do not repeat material from [RFC4377], but simply give references to that document.
このセクションで説明された一般的な要件は[RFC4377]のポイントツーポイントMPLSのために説明されたものと同様です。 以下の小区分は[RFC4377]からの材料を繰り返しませんが、単にそのドキュメントの参照をお願いします。
However, where the requirements for P2MP MPLS OAM differ from or are more extensive than those expressed in [RFC4377], additional text is supplied.
しかしながら、P2MP MPLS OAMのための要件が[RFC4377]で言い表されたものより異なっているか、または大規模であるところに、追加テキストを供給します。
Yasukawa, et al. Informational [Page 4] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[4ページ]のRFC4687OAM Reqs
In general, it should be noted that P2MP LSPs introduce a scalability issue with respect to OAM that is not present in point-to-point MPLS. That is, an individual P2MP LSP will have more than one egress and the path to those egresses will very probably not be linear (for example, it may have a tree structure). Since the number of egresses for a single P2MP LSP is unknown and not bounded by any small number, it follows that all mechanisms defined for OAM support MUST scale well with the number of egresses and the complexity of the path of the LSP. Mechanisms that are able to deal with individual egresses will scale no worse than similar mechanisms for point-to-point LSPs, but it is desirable to develop mechanisms that are able to leverage the fact that multiple egresses are associated with a single LSP, and so achieve better scaling.
一般に、P2MP LSPsが指すポイントの現在のMPLSでないOAMに関してスケーラビリティ問題を紹介することに注意されるべきです。 すなわち、個々のP2MP LSPには、1つ以上の出口があるでしょう、そして、それらの出口への経路は非常にたぶん直線的でないでしょう(例えば、それには、木構造があるかもしれません)。 独身のP2MP LSPのための出口の数が未知であり、どんな少ない数に従ってもバウンドしなかったので、OAMサポートのために定義されたすべてのメカニズムが出口の数とLSPの経路の複雑さでよく比例しなければならないということになります。 個々の出口に対処できるメカニズムはポイントツーポイントLSPsのために同様のメカニズムよりひどく比例しないでしょうが、複数の出口が独身のLSPに関連しているという事実に投機するので、より良いスケーリングを達成できるメカニズムを開発するのは望ましいです。
4.1. Detection of Label Switch Path Defects
4.1. ラベルスイッチ経路欠陥の検出
The ability to detect defects in a P2MP LSP SHOULD not require manual, hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP, and SHOULD rely on proactive OAM procedures (such as continuous path connectivity and Service Level Agreement (SLA) measurement mechanisms). Any solutions SHOULD either extend or work in close conjunction with existing solutions developed for point-to- point MPLS, such as those specified in [RFC4379] where this requirement is not contradicted by the other requirements in this section. This will leverage existing software and hardware deployments.
P2MP LSP SHOULDに欠陥を検出する能力は手動と、ホップごとのそのLSPのために交通を切り換えるのに使用されるそれぞれのLSRのトラブルシューティングを必要としません、そして、SHOULDは先を見越すOAM手順(連続した経路の接続性とサービス・レベル・アグリーメント(SLA)測定メカニズムなどの)を当てにします。 どんな解決策SHOULDもこの要件がこのセクションで他の要件によって矛盾されないところで[RFC4379]で指定されたものなどのポイントからポイントへのMPLSのための既存の解決策が見いだされている近い接続詞で広がっているか、または働いています。 これは既存のソフトウェアとハードウェア展開に投機するでしょう。
Note that P2MP LSPs may introduce additional scaling concerns for LSP probing by tools such as [RFC4379]. As the number of leaves of a P2MP LSP increases it potentially becomes more expensive to inspect the LSP to detect defects. Any tool developed for this purpose MUST be cognitive of this issue and MUST include techniques to reduce the scaling impact of an increase in the number of leaves. Nevertheless, it should also be noted that the introduction of additional leaves may mean that the use of techniques such as [RFC4379] are less appropriate for defect detection with P2MP LSPs, while the technique may still remain useful for defect diagnosis as described in the next section.
P2MP LSPsが[RFC4379]などのツールで調べるLSPに関する追加スケーリング心配を導入するかもしれないことに注意してください。 P2MP LSPの葉の数が増加するのに従って、欠陥を検出するためにLSPを点検するのは潜在的により高価になります。 このために開発されたどんなツールも、この問題で認識的でなければならなく、葉の数の増加のスケーリング影響を減少させるためにテクニックを含まなければなりません。 それにもかかわらず、また、追加葉の導入が、P2MP LSPsとの欠陥検出には、[RFC4379]などのテクニックの使用がそれほど適切でないことを意味するかもしれないことに注意されるべきです、テクニックは次のセクションで説明されるようにまだ欠陥診断の役に立ったままで残っているかもしれませんが。
Due to the above scaling concerns, LSRs or other network resources MUST NOT be overwhelmed by the operation of normal proactive OAM procedures, and measures taken to protect LSRs and network resources against being overwhelmed MUST NOT degrade the operational value or responsiveness of proactive OAM procedures. Note that reactive OAM may violate these limits (i.e., cause visible traffic degradation) if it is necessary or useful to try to fix whatever has gone wrong.
上のスケーリング関心のため、正常な先を見越すOAM手順の操作でLSRsか他のネットワーク資源を圧倒してはいけません、そして、圧倒されることに対してLSRsとネットワーク資源を保護するために実施される対策は先を見越すOAM手順の操作上の値か反応性を下げてはいけません。 修理しようとするのが必要であるか、または役に立つなら何が支障をきたしたかとしても反応OAMがこれらの限界(すなわち、目に見える交通退行を引き起こす)に違反するかもしれないことに注意してください。
Yasukawa, et al. Informational [Page 5] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[5ページ]のRFC4687OAM Reqs
By "overwhelmed" we mean that it MUST NOT be possible for an LSR to be so busy handling proactive OAM that it is unable to continue to process control or data plane traffic at its advertised rate. Similarly, a network resource (such as a data link) MUST NOT be carrying so much proactive OAM traffic that it is unable to carry the advertised data rate. At the same time, it is important to configure proactive OAM, if it is in use, not to raise alarms caused by the failure to receive an OAM message if the component responsible for processing the messages is unable to process because other components are consuming too many system resources -- such alarms might turn out to be false.
「圧倒されること」で、私たちは、広告を出している速度で工程管理かデータ空輸に続くことができないのがLSRがとても忙しい取り扱いの先を見越すOAMであることで可能であるはずがないと言っています。 同様に、ネットワーク資源(データ・リンクなどの)がとても多くの先を見越すOAM交通を運んではいけないので、それは広告を出しているデータ信号速度を運ぶことができません。 同時に、先を見越すOAMを構成するのは重要です、それが他のコンポーネントがあまりに多くのシステム資源を消費しているのでメッセージを処理するのに原因となるコンポーネントが処理できないならOAMメッセージを受け取らないことによってもたらされた懸念を上げないように使用中であるなら--そのようなアラームは誤っていると判明するかもしれません。
In practice, of course, the requirements in the previous paragraph may be met by careful specification of the anticipated data throughput of LSRs or data links. However, it should be recalled that proactive OAM procedures may be scaled linearly with the number of LSPs, and the number of LSPs is not necessarily a function of the available bandwidth in an LSR or on a data link.
もちろん、実際には、前のパラグラフの必要条件はLSRsかデータ・リンクの予期されたデータスループットの慎重な仕様で満たされるかもしれません。 しかしながら、先を見越すOAM手順がLSPsの数で直線的にスケーリングされたかもしれないと思い出されるべきであり、LSPsの数は必ずLSRかデータ・リンクにおける利用可能な帯域幅の機能であるというわけではありません。
4.2. Diagnosis of a Broken Label Switch Path
4.2. 起伏の多いラベルスイッチ経路の診断
The ability to diagnose a broken P2MP LSP and to isolate the failed component (i.e., link or node) in the path is REQUIRED. These functions include a path connectivity test that can test all branches and leaves of a P2MP LSP for reachability, as well as a path tracing function. Note that this requirement is distinct from the requirement to detect errors or failures described in the previous section. In practice, Detection and Diagnosis/Isolation MAY be performed by separate or the same mechanisms according to the way in which the other requirements are met.
壊れているP2MP LSPを診断して、経路で失敗したコンポーネント(すなわち、リンクかノード)を隔離する能力はREQUIREDです。 これらの機能はすべてのブランチを検査できて、いなくなる可到達性のためのP2MP LSPの経路接続性テストを含んでいます、パス追跡機能と同様に。 この要件が前項で説明された誤りか失敗を検出するという要件と異なっていることに注意してください。 実際には、他の必要条件が満たされる方法によると、DetectionとDiagnosis/孤立は別々であるか同じメカニズムによって実行されるかもしれません。
It MUST be possible for the operator (or an automated process) to stipulate a timeout after which the failure to see a response shall be flagged as an error.
オペレータ(または、自動化された過程)が応答を見ない場合誤りとして旗を揚げられるタイムアウトを規定するのは、可能であるに違いありません。
Any mechanism developed to perform these functions is subject to the scalability concerns expressed in section 4.
これらの機能を実行するために開発されたどんなメカニズムもセクション4で述べられたスケーラビリティ関心を必要としています。
4.3. Path Characterization
4.3. 経路特殊化
The path characterization function [RFC4377] is the ability to reveal details of LSR forwarding operations for P2MP LSPs. These details can then be compared later during subsequent testing relevant to OAM functionality. Therefore, LSRs supporting P2MP LSPs MUST provide mechanisms that allow operators to interrogate and characterize P2MP paths.
経路特殊化機能[RFC4377]はP2MP LSPsのためにLSR推進操作の詳細を明らかにする能力です。 そして、後でOAMの機能性に関連しているその後のテストの間、これらの詳細を比較できます。 したがって、P2MP LSPsを支持するLSRsはオペレータがP2MP経路を査問して、特徴付けるメカニズムを、提供しなければなりません。
Yasukawa, et al. Informational [Page 6] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[6ページ]のRFC4687OAM Reqs
Since P2MP paths are more complex than the paths of point-to-point LSPs, the scaling concerns expressed in section 4 apply.
P2MP経路がポイントツーポイントLSPsの経路より複雑であるので、セクション4で述べられたスケーリング関心は適用されます。
Note that path characterization SHOULD lead to the operator being able to determine the full tree for a P2MP LSP. That is, it is not sufficient to know the list of LSRs in the tree, but it is important to know their relative order and where the LSP branches.
経路特殊化SHOULDがP2MP LSPのために完全木を決定できるオペレータに通じることに注意してください。 すなわち、木でLSRsのリストを知るのが十分ではありませんが、彼らの相対オーダとLSPがどこで分岐するかを知るのは重要です。
Since, in some cases, the control plane state and data paths may branch at different points from the control plane and data plane topologies (for example, Figure 1), it is not sufficient to present the order of LSRs, but it is important that the branching points on that tree are clearly identified.
コントロール飛行機状態とデータ経路がいくつかの場合制御飛行機とデータ飛行機topologies(例えば、図1)と異なったポイントで分岐するかもしれないので、LSRsの注文を提示するのが十分ではありませんが、その木の分岐ポイントが明確に特定されるのは、重要です。
E
/
A---B---C===D
\
F
E/A---B---C===D\F
Figure 1. An example P2MP tree where the data path and control
plane state branch at C, but the topology branches at D.
図1。 データ経路とコントロール飛行機状態がCで分岐しますが、トポロジーがDで分岐する例のP2MP木。
A diagnostic tool that meets the path characterization requirements SHOULD collect information that is easy to process to determine the P2MP tree for a P2MP LSP, rather than provide information that must be post-processed with some complexity.
何らかの複雑さでSHOULDがP2MP LSPのためにそれを情報に提供するよりむしろP2MP木を決定するために処理しやすい情報を集めるという経路特殊化必要条件を満たす診断用道具を後処理しなければなりません。
4.4. Service Level Agreement Measurement
4.4. サービス・レベル・アグリーメント測定
Mechanisms are required to measure the diverse aspects of Service Level Agreements for services that utilize P2MP LSPs. The aspects are listed in [RFC4377].
メカニズムはP2MP LSPsを利用するサービスのためのサービス・レベル・アグリーメントのさまざまの局面を測定しなければなりません。 局面は[RFC4377]に記載されています。
Service Level Agreements are often measured in terms of the quality and rate of data delivery. In the context of P2MP MPLS, data is delivered to multiple egress nodes. The mechanisms MUST, therefore, be capable of measuring the aspects of Service Level Agreements as they apply to each of the egress points to a P2MP LSP. At the same time, in order to diagnose issues with meeting Service Level Agreements, mechanisms SHOULD be provided to measure the aspects of the agreements at key points within the network such as at branch nodes on the P2MP tree.
サービス・レベル・アグリーメントはデータ配送の品質と速度でしばしば測定されます。 P2MP MPLSの文脈では、データは複数の出口ノードに果たされます。 したがって、メカニズムは、それぞれの出口ポイントに適用しながら、サービス・レベル・アグリーメントの局面をP2MP LSPに測定できなければなりません。 同時に、ミーティングサービス・レベル・アグリーメントの問題を診断するために、P2MPがブランチノードなどのようにオンなネットワークの中で要所で協定の局面を測定するために木に登るなら、メカニズムSHOULDは診断します。
Yasukawa, et al. Informational [Page 7] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[7ページ]のRFC4687OAM Reqs
4.5. Frequency of OAM Execution
4.5. OAM実行の頻度
As stipulated in [RFC4377], the operator MUST have the flexibility to configure OAM parameters to meet their specific operational requirements. This requirement is potentially more important in P2MP deployments where the effects of the execution of OAM functions can be potentially much greater than in a non-P2MP configuration. For example, a mechanism that causes each egress of a P2MP LSP to respond could result in a large burst of responses to a single OAM request.
[RFC4377]で規定されているように、オペレータにはそれらの特定の操作上の必要条件を満たすためにOAMパラメタを構成する柔軟性がなければなりません。 OAM機能の実行の効果が潜在的にはるかにすばらしい場合があるところでは、P2MP展開ではこの要件が非P2MP構成より潜在的に重要です。 例えば、P2MP LSPの各出口が応じるメカニズムはただ一つのOAM要求への応答の大きい炸裂をもたらすかもしれません。
Therefore, solutions produced SHOULD NOT impose any fixed limitations on the frequency of the execution of any OAM functions.
したがって、解決策の生産されたSHOULD NOTはどんなOAM機能の実行の頻度にもどんな固定制限も課します。
4.6. Alarm Suppression, Aggregation, and Layer Coordination
4.6. アラーム抑圧、集合、および層のコーディネート
As described in [RFC4377], network elements MUST provide alarm suppression and aggregation mechanisms to prevent the generation of superfluous alarms within or across network layers. The same time constraint issues identified in [RFC4377] also apply to P2MP LSPs.
[RFC4377]で説明されるように、ネットワーク要素はネットワーク層以内かネットワーク層の向こう側に余計なアラームの世代を防ぐためにアラーム抑圧と凝集機構を提供しなければなりません。 また、[RFC4377]で特定された同じ時間規制問題はP2MP LSPsに適用されます。
A P2MP LSP also brings the possibility of a single fault causing a larger number of alarms than for a point-to-point LSP. This can happen because there are a larger number of downstream LSRs (for example, a larger number of egresses). The resultant multiplier in the number of alarms could cause swamping of the alarm management systems to which the alarms are reported, and serves as a multiplier to the number of potentially duplicate alarms raised by the network.
また、P2MP LSPはただ一つの欠点が二地点間LSPより多くの懸念をもたらす可能性をもたらします。 多くの川下のLSRs(例えば、より多くの出口)があるので、これは起こることができます。 アラームの数における結果の乗数は、アラームが報告されるアラームマネージメントシステムの湿地帯を引き起こす場合があって、乗数として潜在的にネットワークによって上げられた写しアラームの数に機能します。
Alarm aggregation or limitation techniques MUST be applied within any solution, or be available within an implementation, so that this scaling issue can be reduced. Note that this requirement introduces a second dimension to the concept of alarm aggregation. Where previously it applied to the correlation and suppression of alarms generated by different network layers, it now also applies to similar techniques applied to alarms generated by multiple downstream LSRs.
アラーム集合か制限のテクニックが、どんな解決策の中でも適用されるか、または実現の中で利用可能であるに違いありません、このスケーリング問題が減少できるように。 この要件がアラーム集合の概念に2番目の寸法を紹介することに注意してください。 また、以前に異なったネットワーク層で発生するアラームの相関関係と秘匿に適用されたところでは、それは現在、複数の川下LSRsによって発生したアラームに適用された同様のテクニックに適用されます。
4.7. Support for OAM Interworking for Fault Notification
4.7. 欠点によって通知を織り込むOAMのサポート
[RFC4377] specifies that an LSR supporting the interworking of one or more networking technologies over MPLS MUST be able to translate an MPLS defect into the native technology's error condition. This also applies to any LSR supporting P2MP LSPs. However, careful attention to the requirements for alarm suppression stipulated therein and in section 4.6 SHOULD be observed.
[RFC4377]は、MPLS MUSTの上で1つ以上のネットワーク・テクノロジーを織り込むことを支持するLSRが固有の技術のエラー条件にMPLS欠陥を翻訳できると指定します。 また、これはP2MP LSPsを支持するどんなLSRにも適用されます。 しかしながら、アラーム抑圧のための要件に関する慎重な注意はそこにとセクション4.6でSHOULDを規定しました。観測されます。
Note that the time constraints for fault notification and alarm propagation affect the solutions that might be applied to the scalability problem inherent in certain OAM techniques applied to
欠点通知とアラーム伝播が、あるOAMのテクニックの固有であるスケーラビリティ問題に適用されるかもしれない解決策に影響するので時間規制が、申し込んだことに注意してください。
Yasukawa, et al. Informational [Page 8] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[8ページ]のRFC4687OAM Reqs
P2MP LSPs. For example, a solution to the issue of a large number of egresses all responding to some form of probe request at the same time might be to make the probes less frequent -- but this might affect the ability to detect and/or report faults.
P2MP LSPs。 例えば、同時に何らかの形式の徹底的調査要求にすべて応じる多くの出口の問題の解決が徹底的調査をより頻繁でなくすることであるかもしれませんが、これは欠点を検出する、そして/または、報告する能力に影響するかもしれません。
Where fault notification to the egress is required, there is the possibility that a single fault will give rise to multiple notifications, one to each egress node of the P2MP that is downstream of the fault. Any mechanisms MUST manage this scaling issue while still continuing to deliver fault notifications in a timely manner.
出口への欠点通知が必要であるところに、ただ一つの欠点が複数の通知(川下にある欠点のP2MPのそれぞれの出口ノードへの1)をもたらす可能性があります。 まだ直ちに欠点通知を提供してい続けている間、どんなメカニズムもこのスケーリング問題を管理しなければなりません。
Where fault notification to the ingress is required, the mechanisms MUST ensure that the notification identifies the egress nodes of the P2MP LSP that are impacted (that is, those downstream of the fault) and does not falsely imply that all egress nodes are impacted.
イングレスへの欠点通知が必要であるところでは、メカニズムは、通知が、影響を与えられたP2MP LSP(すなわち、欠点の川下であるもの)の出口ノードを特定して、すべての出口ノードに影響を与えられるのを間違って含意しないのを確実にしなければなりません。
4.8. Error Detection and Recovery
4.8. 誤り検出と回復
Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. As described in [RFC4377], these procedures will detect a broad range of defects, and SHOULD be operable where MPLS P2MP LSPs span multiple routing areas or multiple Service Provider domains.
MPLS OAM手順でネットワーク要素に従った欠点からの回復を容易にすることができます。 これらの手順は[RFC4377]で説明されるように広範囲な欠陥、およびSHOULDを検出するでしょう。MPLS P2MP LSPsが複数のルーティング領域か複数のService Providerドメインにかかるところで手術可能であってください。
The same requirements as those expressed in [RFC4377] with respect to automatic repair and operator intervention ahead of customer detection of faults apply to P2MP LSPs.
ものが欠点の顧客検出の前に[RFC4377]で自動修理とオペレータ介入に関して言い表したように同じ要件はP2MP LSPsに適用されます。
It should be observed that faults in P2MP LSPs MAY be recovered through techniques described in [P2MP-RSVP].
P2MP LSPsの欠点が[P2MP-RSVP]で説明されたテクニックで回復されるかもしれないのが観測されるべきです。
4.9. Standard Management Interfaces
4.9. 標準の管理インタフェース
The widespread deployment of MPLS requires common information modeling of management and control of OAM functionality. This is reflected in the integration of standard MPLS-related MIBs [RFC3812], [RFC3813], [RFC3814], [RFC3815] for fault, statistics, and configuration management. These standard interfaces provide operators with common programmatic interface access to operations and management functions and their status.
MPLSの広範囲の展開は管理の一般的な情報モデルとOAMの機能性のコントロールを必要とします。 これは標準のMPLS関連のMIBs[RFC3812]、[RFC3813]、[RFC3814]、欠点のための[RFC3815]、統計、および構成管理の統合に反映されます。 これらの標準インターフェースは操作、管理機能、およびそれらの状態への一般的なプログラムに従ったインタフェースアクセスをオペレータに提供します。
The standard MPLS-related MIB modules [RFC3812], [RFC3813], [RFC3814], and [RFC3815] SHOULD be extended wherever possible, to support P2MP LSPs, the associated OAM functions on these LSPs, and the applications that utilize P2MP LSPs. Extending them will facilitate the reuse of existing management software both in LSRs and in management systems. In cases where the existing MIB modules cannot be extended, then new MIB modules MUST be created.
標準のMPLS関連のMIBモジュール[RFC3812]、[RFC3813]、[RFC3814]、および[RFC3815]SHOULDがP2MP LSPsを支持するためにどこでも、可能であるところで広げられて、関連OAMはこれらのLSPs、およびP2MP LSPsを利用するアプリケーションのときに機能します。 それらを広げていると、LSRsとマネージメントシステムにおける、既存の管理ソフトウェアの再利用は容易にされるでしょう。次に、既存のMIBモジュールを広げることができない場合では、新しいMIBモジュールを作成しなければなりません。
Yasukawa, et al. Informational [Page 9] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[9ページ]のRFC4687OAM Reqs
4.10. Detection of Denial of Service Attacks
4.10. サービス不能攻撃の検出
The ability to detect denial of service (DoS) attacks against the data or control planes that signal P2MP LSPs MUST be part of any security management related to MPLS OAM tools or techniques.
信号P2MP LSPsがどんなセキュリティ管理の一部であるに違いないというデータか制御飛行機に対するサービス(DoS)攻撃の否定も検出する能力はMPLS OAMツールかテクニックに関連しました。
4.11. Per-LSP Accounting Requirements
4.11. 1LSPあたりの会計要件
In an MPLS network where P2MP LSPs are in use, Service Providers can measure traffic from an LSR to the egress of the network using some MPLS-related MIB modules (see section 4.9), for example. Other interfaces MAY exist as well and enable the creation of traffic matrices so that it is possible to know how much traffic is traveling from where to where within the network.
P2MP LSPsが使用中であるMPLSネットワークでは、Service Providersは、例えば、いくつかのMPLS関連のMIBモジュール(セクション4.9を見る)を使用することでLSRからネットワークの出口までの交通を測定できます。 他のインタフェースがまた、存在していて、交通マトリクスの創造を可能にするかもしれないので、どのくらいの交通がネットワークの中をどこからどこまで旅行するかであるかを知るのは可能です。
Analysis of traffic flows to produce a traffic matrix is more complicated where P2MP LSPs are deployed because there is no simple pairing relationship between an ingress and a single egress. Fundamental to understanding traffic flows within a network that supports P2MP LSPs will be the knowledge of where the traffic is branched for each LSP within the network, that is, where within the network the branch nodes for the LSPs are located and what their relationship is to links and other LSRs. Traffic flow and accounting tools MUST take this fact into account.
イングレスと単一の出口の間には、どんな簡単な組み合わせ関係もないので、P2MP LSPsが配備されるところでは、交通マトリクスを作り出す交通の流れの分析が、より複雑です。 P2MP LSPsを支持するネットワークの中の交通の流れが交通があるところに関する知識はネットワークの中の各LSPのために分岐しました、すなわち、LSPsのためのブランチノードがネットワークの中に位置しているところでことであることを理解していることへの基本的と彼らの関係が何であるかというリンクと他のLSRsへのことです。 交通の流れと会計ツールはこの事実を考慮に入れなければなりません。
5. Security Considerations
5. セキュリティ問題
This document introduces no new security issues compared with [RFC4377]. It is worth highlighting, however, that any tool designed to satisfy the requirements described in this document MUST include provisions to prevent its unauthorized use. Likewise, these tools MUST provide a means by which an operator can prevent denial of service attacks if those tools are used in such an attack. LSP mis- merging is described in [RFC4377] where it is pointed out that it has security implications beyond simply being a network defect. It needs to be stressed that it is in the nature of P2MP traffic flows that any erroneous delivery (such as caused by LSP mis-merging) is likely to have more far-reaching consequences since the traffic will be mis-delivered to multiple receivers.
このドキュメントは[RFC4377]と比べてどんな新しい安全保障問題も紹介しません。 しかしながら、本書では説明された要件を満たすように設計されたどんなツールも無断使用を防ぐために条項を含んでいなければならないのは強調する価値があります。 同様に、これらのツールはそれらのツールがそのような攻撃に使用されるならオペレータがサービス不能攻撃を防ぐことができる手段を提供しなければなりません。 LSP、誤合併は単にネットワーク欠陥であることを超えてそれにはセキュリティ意味があると指摘される[RFC4377]で説明されます。 それは、圧力を加えられる必要があります。交通が複数の受信機に誤渡すようになるので、P2MP交通の流れの自然では、どんな誤った配送(LSP誤合併で引き起こされるように)もより遠大な結果を持っていそうです。
As with the OAM functions described in [RFC4377], the performance of diagnostic functions and path characterization may involve the extraction of a significant amount of information about network construction. The network operator MAY consider this information private and wish to take steps to secure it, but further, the volume of this information may be considered as a threat to the integrity of
OAM機能が[RFC4377]で説明されている場合、診断機能と経路特殊化の性能はネットワーク構築に関して重要な情報量の抽出にかかわるかもしれません。 オペレータが兵卒と取るという願望がそれを安全にするために踏まれますが、さらに、この情報のボリュームが保全への脅威であるとみなされるかもしれないというこの情報を考えるかもしれないネットワーク
Yasukawa, et al. Informational [Page 10] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[10ページ]のRFC4687OAM Reqs
the network if it is extracted in bulk. This issue may be greater in P2MP MPLS because of the potential for a large number of receivers on a single LSP and the consequent extensive path of the LSP.
ネットワークはそれであるなら大量に抜粋されます。 P2MP MPLSでは、この問題はLSPの独身のLSPと結果の大規模な経路の多くの受信機の可能性のために、より重要であるかもしれません。
6. References
6. 参照
6.1. Normative References
6.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[RFC4377] Nadeau, T., Morrow, M., Swallow, G., Allan, D., and
S. Matsushima, "Operations and Management (OAM)
Requirements for Multi-Protocol Label Switched
(MPLS) Networks", RFC 4377, February 2006.
[RFC4377] ナドー、T.、翌日、M.、ツバメ、G.、アラン、D.、およびS.松島、「マルチプロトコルのための要件がラベルする操作と経営者側(OAM)は(MPLS)ネットワークを切り換えました」、RFC4377、2006年2月。
6.2. Informative References
6.2. 有益な参照
[MCAST-LDP] Minei, I., Ed., Kompella, K., Wijnands, I., Ed., and
B. Thomas, "Label Distribution Protocol Extensions
for Point-to-Multipoint and Multipoint-to-Multipoint
Label Switched Paths", Work in Progress, June 2006.
[MCAST-自由民主党]Minei、I.(エド)、Kompella(K.、Wijnands、I.(エド)、およびB.トーマス)は「ポイントツーマルチポイントのためのプロトコル拡大と多点から多点へのラベル切り換えられた経路と分配をラベルします」、処理中の作業、2006年6月。
[P2MP-LSP-PING] Yasukawa, S., Farrel, A., Ali, Z., and B. Fenner,
"Detecting Data Plane Failures in Point-to-
Multipoint MPLS Traffic Engineering - Extensions to
LSP Ping", Work in Progress, April 2006.
[P2MP-LSP-ピング] Yasukawa、S.、ファレル、A.、アリ、Z.、およびB.フェナー、「ポイントから多点へのMPLS交通工学でのデータ飛行機の故障を検出します--LSPへの拡大は確認します」、処理中の作業、2006年4月。
[P2MP-RSVP] Aggarwal, R., Papadimitriou, D., and S. Yasukawa,
"Extensions to RSVP-TE for Point to Multipoint TE
LSPs", Work in Progress, July 2006.
R.、Papadimitriou、D.、およびS.Yasukawa、「多点Te LSPsへのポイントRSVP-Teへの拡大」という[P2MP-RSVP]Aggarwalは進行中(2006年7月)で働いています。
[RFC3812] Srinivasan, C., Viswanathan, A. and T. Nadeau,
"MPLS Traffic Engineering Management Information
Base Using SMIv2", RFC3812, June 2004.
[RFC3812] SrinivasanとC.とViswanathanとA.とT.ナドー、「2004年6月にSMIv2"、RFC3812を使用するMPLS交通技術管理部会。」
[RFC3813] Srinivasan, C., Viswanathan, A. and T. Nadeau,
"MPLS Label Switch Router Management Information
Base Using SMIv2", RFC3813, June 2004.
[RFC3813] Srinivasan、C.、Viswanathan、A.、およびT.ナドー、「SMIv2"を使用するRFC3813とMPLSは2004年6月にスイッチルータ管理情報ベースをラベルします」。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan,
"Multiprotocol Label Switching (MPLS) FEC-To-NHLFE
(FTN) Management Information Base", RFC3814, June
2004.
[RFC3814] ナドー、T.、Srinivasan、C.、およびA.Viswanathan、「Multiprotocolラベルの切り換え(MPLS)のFECからNHLFE(FTN)への管理情報ベース」、RFC3814、2004年6月。
Yasukawa, et al. Informational [Page 11] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[11ページ]のRFC4687OAM Reqs
[RFC3815] Cucchiara, J., Sjostrand, H., and Luciani, J.,
"Definitions of Managed Objects for the
Multiprotocol Label Switching (MPLS), Label
Distribution Protocol (LDP)", RFC 3815, June 2004.
[RFC3815] CucchiaraとJ.とシェストランド、H.とLuciani、J.、「Multiprotocolラベル切り換え(MPLS)のための管理オブジェクトの定義、ラベル分配は(自由民主党)について議定書の中で述べます」、RFC3815、2004年6月。
[RFC4378] Allan, D. and T. Nadeau, "A Framework for Multi-
Protocol Label Switching (MPLS) Operations and
Management (OAM)", RFC 4378, February 2006.
[RFC4378] アランとD.とT.ナドー、「マルチプロトコルラベル切り換え(MPLS)操作と管理(OAM)のための枠組み」、RFC4378、2006年2月。
[RFC4379] Kompella, K. and G. Swallow, "Detecting Multi-
Protocol Label Switched (MPLS) Data Plane Failures",
RFC 4379, February 2006.
[RFC4379] Kompella、K.、およびG.は2006年2月に「マルチプロトコルのラベルの切り換えられた(MPLS)データ飛行機の故障を検出すること」でのRFC4379を飲み込みます。
[RFC4461] Yasukawa, S., Ed., "Signaling Requirements for
Point-to-Multipoint Traffic-Engineered MPLS Label
Switched Paths (LSPs)", RFC 4461, April 2006.
[RFC4461] エドYasukawa、S.、RFC4461、「ポイントツーマルチポイントの交通で設計されたMPLSラベルの切り換えられた経路(LSPs)のための要件に合図すること」での4月2006日
7. Acknowledgements
7. 承認
The authors wish to acknowledge and thank the following individuals for their valuable comments on this document: Rahul Aggarwal, Neil Harrison, Ben Niven-Jenkins, and Dimitri Papadimitriou.
作者は、このドキュメントの彼らの貴重なコメントについて以下の個人に承認して、感謝したがっています: Rahul Aggarwal、ニール・ハリソン、ベン・ニーヴン-ジェンキンス、およびディミトリPapadimitriou。
Yasukawa, et al. Informational [Page 12] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[12ページ]のRFC4687OAM Reqs
Authors' Addresses
作者のアドレス
Seisho Yasukawa NTT Corporation (R&D Strategy Department) 3-1, Otemachi 2-Chome Chiyodaku, Tokyo 100-8116 Japan
Seisho Yasukawa NTT社(研究開発戦略部)の3-1、2丁目の千代田区、東京日本大手町100-8116
Phone: +81 3 5205 5341 EMail: s.yasukawa@hco.ntt.co.jp
以下に電話をしてください。 +81 3 5205 5341はメールされます: s.yasukawa@hco.ntt.co.jp
Adrian Farrel Old Dog Consulting
エードリアンのファレルの古い犬のコンサルティング
Phone: +44 (0) 1978 860944 EMail: adrian@olddog.co.uk
以下に電話をしてください。 +44 (0) 1978 860944はメールされます: adrian@olddog.co.uk
Daniel King Aria Networks Ltd.
ダニエルAria王は株式会社をネットワークでつなぎます。
Phone: +44 (0)1249 665923 EMail: daniel.king@aria-networks.com
以下に電話をしてください。 +44 (0) 1249 665923はメールされます: daniel.king@aria-networks.com
Thomas D. Nadeau Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719
トーマスD.ナドーシスコシステムズInc.1414マサチューセッツAve。 Boxborough、MA 01719
EMail: tnadeau@cisco.com
メール: tnadeau@cisco.com
Yasukawa, et al. Informational [Page 13] RFC 4687 OAM Reqs for Point-to-Multipoint MPLS September 2006
Yasukawa、他 ポイントツーマルチポイントMPLS2006年9月のための情報[13ページ]のRFC4687OAM Reqs
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(2006)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を記述してください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Yasukawa, et al. Informational [Page 14]
Yasukawa、他 情報[14ページ]
一覧
スポンサーリンク
