RFC4377 日本語訳
4377 Operations and Management (OAM) Requirements for Multi-ProtocolLabel Switched (MPLS) Networks. T. Nadeau, M. Morrow, G. Swallow, D.Allan, S. Matsushima. February 2006. (Format: TXT=31889 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Nadeau
Request for Comments: 4377 M. Morrow
Category: Informational G. Swallow
Cisco Systems, Inc.
D. Allan
Nortel Networks
S. Matsushima
Japan Telecom
February 2006
コメントを求めるワーキンググループT.ナドーの要求をネットワークでつないでください: 4377年のM.翌日のカテゴリ: D.アランノーテルがS.日本松島テレコム2006年2月にネットワークでつなぐ情報のG.ツバメシスコシステムズInc.
Operations and Management (OAM) Requirements
for Multi-Protocol Label Switched (MPLS) Networks
マルチプロトコルのための要件がラベルする操作と経営者側(OAM)は(MPLS)ネットワークを切り換えました。
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
要約
This document specifies Operations and Management (OAM) requirements for Multi-Protocol Label Switching (MPLS), as well as for applications of MPLS, such as pseudo-wire voice and virtual private network services. These requirements have been gathered from network operators who have extensive experience deploying MPLS networks.
このドキュメントはMulti-プロトコルLabel Switching(MPLS)のためのOperationsとManagement(OAM)要件を指定します、よくMPLSのアプリケーションのように、疑似ワイヤ声や仮想私設網サービスのように。 MPLSがネットワークであると配布するという広範囲の経験を持っているネットワーク・オペレータからこれらの要件を集めてあります。
Table of Contents
目次
1. Introduction ....................................................2 2. Document Conventions ............................................2 3. Motivations .....................................................4 4. Requirements ....................................................4 5. Security Considerations ........................................11 6. References .....................................................12 7. Acknowledgements ...............................................13
1. 序論…2 2. コンベンションを記録してください…2 3. 動機…4 4. 要件…4 5. セキュリティ問題…11 6. 参照…12 7. 承認…13
Nadeau, et al. Informational [Page 1] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[1ページ]のRFC4377OAM要件
1. Introduction
1. 序論
This document describes requirements for user and data plane Operations and Management (OAM) for Multi-Protocol Label Switching (MPLS). These requirements have been gathered from network operators who have extensive experience deploying MPLS networks. This document specifies OAM requirements for MPLS, as well as for applications of MPLS.
このドキュメントはユーザのための要件とMulti-プロトコルLabel Switching(MPLS)のためのデータ飛行機のOperationsとManagement(OAM)について説明します。 MPLSがネットワークであると配布するという広範囲の経験を持っているネットワーク・オペレータからこれらの要件を集めてあります。 このドキュメントはMPLS、およびMPLSのアプリケーションのためのOAM要件を指定します。
Currently, there are no specific mechanisms proposed to address these requirements. The goal of this document is to identify a commonly applicable set of requirements for MPLS OAM at this time. Specifically, a set of requirements that apply to the most common set of MPLS networks deployed by service provider organizations at the time this document was written. These requirements can then be used as a base for network management tool development and to guide the evolution of currently specified tools, as well as the specification of OAM functions that are intrinsic to protocols used in MPLS networks.
現在、これらの要件を扱うために提案されて、どんな特定のメカニズムもありません。 このドキュメントの目標はこのときMPLS OAMのための一般的に適切なセットの要件を特定することです。 明確に、このドキュメントが書かれたとき、最も一般的なセットのMPLSネットワークに適用される1セットの要件はサービスプロバイダー組織で展開しました。 次に、ネットワークマネージメントツール開発、現在指定されたツールの発展を誘導するのにベースとしてこれらの要件を使用できます、MPLSネットワークに使用されるプロトコルに本質的なOAM機能の仕様と同様に。
2. Document Conventions
2. ドキュメントコンベンション
2.1. Terminology
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]で説明されるように本書では解釈されることであるべきですか?
Queuing/buffering Latency: The delay caused by packet queuing (value
is variable since it is dependent on the
packet arrival rate, the packet length,
and the link throughput).
潜在を列に並ばせるか、またはバッファリングします: 遅れはパケットで列を作りを引き起こしました(それがパケット到着率、パケット長、およびリンクスループットに依存しているので、値は可変です)。
Probe-based-detection: Active measurement tool that can measure
the consistency of an LSP [RFC4379].
徹底的調査ベースの検出: LSP[RFC4379]の一貫性を測定できるアクティブな測定ツール。
Defect: Any error condition that prevents a Label
Switched Path (LSP) from functioning
correctly. For example, loss of an
Interior Gateway Protocol (IGP) path will
most likely result in an LSP not being
able to deliver traffic to its
destination. Another example is the
interruption of the path for a TE tunnel.
These may be due to physical circuit
failures or failure of switching nodes to
operate as expected.
欠陥: Label Switched Path(LSP)が正しく機能するのを防ぐどんなエラー条件。 例えば、Interiorゲートウェイプロトコル(IGP)経路の損失はたぶんトラフィックを送付先に提供できないLSPをもたらすでしょう。 別の例はTEトンネルへの経路の中断です。 これらは実回線の故障か切り換えノードが作動しないことの予想されるようにためであるかもしれません。
Nadeau, et al. Informational [Page 2] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[2ページ]のRFC4377OAM要件
Multi-vendor/multi-provider network
operation typically requires agreed upon
definitions of defects (when it is broken
and when it is not) such that both
recovery procedures and service level
specification impact can be specified.
操作が通常必要とするマルチマルチベンダ/プロバイダーネットワークは、欠陥(それが壊れていて、そうでないときに)の定義のときにリカバリ手順とサービスレベル仕様の両方に影響を与えるようなものを指定できるのに同意しました。
Head-end Label Switching
Router (LSR): The beginning of an LSP. A head-end LSR
is also referred to as an ingress LSR.
ラベル切り換えルータ(LSR)をヘッドで終わらせてください: LSPの始まり。 また、ギヤエンドLSRはイングレスと呼ばれたLSRです。
Tail-end Label Switching
Router (LSR): The end of an LSP. A tail-end LSR is also
referred to as an egress LSR.
末端ラベル切り換えルータ(LSR): LSPの端。 また、末端LSRは出口と呼ばれたLSRです。
Propagation Latency: The delay added by the propagation of the
packet through the link (fixed value that
depends on the distance of the link and
the propagation speed).
伝播潜在: 遅れはリンク(リンクの距離と伝播速度に依存する一定の価値)を通したパケットの伝播で加えました。
Transmission Latency: The delay added by the transmission of the
packet over the link, i.e., the time it
takes to put the packet over the media
(value that depends on the link throughput
and packet length).
トランスミッション潜在: 遅れはリンクの上にパケットのトランスミッションで加えました、すなわち、始める時間はメディアの上にパケットを置きました(リンクスループットとパケット長に依存する値)。
Processing Latency: The delay added by all the operations
related to the switching of labeled
packets (value is node implementation
specific and may be considered fixed and
constant for a given type of equipment).
処理潜在: 遅れはラベルされたパケットの切り換えに関連するすべての操作で加えました(値は、ノード実装特有であり、与えられたタイプの設備に修理されていて一定であると考えられるかもしれません)。
Node Latency: The delay added by the network element
resulting from of the sum of the
transmission, processing, and
queuing/buffering latency.
ノード潜在: 潜在をトランスミッション、処理、および列を作りの合計から生じるか、またはバッファリングするネットワーク要素に従って、遅れは加えました。
One-hop Delay: The fixed delay experienced by a packet to
reach the next hop resulting from the of
the propagation latency, the transmission
latency, and the processing latency.
ワンバウンドの遅れ: 固定遅れが次のホップの結果になることに達するパケットで経験した、伝播潜在、トランスミッション潜在、および処理潜在について。
Minimum Path Latency: The sum of the one-hop delays experienced
by the packet when traveling from the
ingress to the egress LSR.
最小の経路潜在: イングレスから出口LSRまで旅行するときパケットによって経験されたワンバウンドの遅れの合計。
Nadeau, et al. Informational [Page 3] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[3ページ]のRFC4377OAM要件
Variable Path Latency: The variation in the sum of the delays
experienced by packets transiting the
path, otherwise know as jitter.
変化する経路潜在: 遅れの合計の変化が経路を通過するパケットによって経験されて、さもなければ、ジターとして知ってください。
2.2. Acronyms
2.2. 頭文字語
ASBR: Autonomous System Border Router
ASBR: 自律システム境界ルータ
CE: Customer Edge
Ce: 顧客縁
PE: Provider Edge
PE: プロバイダー縁
SP: Service Provider
SP: サービスプロバイダー
ECMP: Equal-Cost Multi-path
ECMP: 等しい費用マルチ経路
LSP: Label Switched Path
LSP: ラベルは経路を切り換えました。
LSP Ping: Label Switched Path Ping
LSPは確認します: ラベルは経路ピングを切り換えました。
LSR: Label Switching Router
LSR: ラベル切り換えルータ
OAM: Operations and Management
OAM: 操作と管理
RSVP: Resource reSerVation Protocol
RSVP: 資源予約プロトコル
LDP: Label Distribution Protocol
自由民主党: ラベル分配プロトコル
DoS: Denial of Service
DoS: サービス妨害
3. Motivations
3. 動機
This document was created to provide requirements that could be used to create consistent and useful OAM functionality that meets operational requirements of those service providers (SPs) who have deployed or are deploying MPLS.
このドキュメントは、展開したか、またはMPLSを配布しているサービスプロバイダー(SPs)の操作上の必要条件を満たす一貫して役に立つOAMの機能性を作成するのに使用できた要件を提供するために作成されました。
4. Requirements
4. 要件
The following sections enumerate the OAM requirements gathered from service providers who have deployed MPLS and services based on MPLS networks. Each requirement is specified in detail to clarify its applicability. Although the requirements specified herein are defined by the IETF, they have been made consistent with requirements gathered by other standards bodies such as the ITU [Y1710].
以下のセクションはMPLSを配布したサービスプロバイダーから集められたOAM要件とMPLSネットワークに基づくサービスを列挙します。 各要件は、適用性をはっきりさせるために詳細に指定されます。 IETFはここに指定された要件を定義しますが、それらをITU[Y1710]などの他の標準化団体によって集められる要件と一致するようにしました。
Nadeau, et al. Informational [Page 4] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[4ページ]のRFC4377OAM要件
4.1. Detection of Label Switched Path Defects
4.1. ラベルの切り換えられた経路欠陥の検出
The ability to detect defects in a broken LSP MUST not require manual hop-by-hop troubleshooting of each LSR used to switch traffic for that LSP. For example, it is not desirable to manually visit each LSR along the data plane path transited by an LSP; instead, this function MUST be automated and able to be performed at some operator specified frequency from the origination point of that LSP. This implies solutions that are interoperable to allow for such automatic operation.
壊れているLSP MUSTに欠陥を検出する能力はホップごとのそのLSPのためにトラフィックを切り換えるのに使用されるそれぞれのLSRの手動のトラブルシューティングを必要としません。 例えば、手動でLSPによって通過されたデータ飛行機経路に沿った各LSRを訪問するのは望ましくはありません。 代わりに、この機能は、自動化されていて何らかのオペレータの指定された頻度でそのLSPの創作先から実行できなければなりません。 これはそのような自動を考慮するのにおいて共同利用できるソリューションを含意します。
Furthermore, the automation of path liveliness is desired in cases where large numbers of LSPs might be tested. For example, automated ingress LSR to egress LSR testing functionality is desired for some LSPs. The goal is to detect LSP path defects before customers do, which requires detection and correction of LSP defects in a manner that is both predictable and within the constraints of the service level agreement under which the service is being offered. Simply put, the sum of the time it takes an OAM tool to detect a defect and the time needed for an operational support system to react to this defect, by possibly correcting it or notifying the customer, must fall within the bounds of the service level agreement in question.
その上、経路活気のオートメーションは多くのLSPsがテストされるかもしれない場合で望まれています。 例えば、出口LSRテストの機能性への自動化されたイングレスLSRはいくつかのLSPsのために望まれています。 目標が顧客が検出する前にLSP経路欠陥を検出することであり、どれがLSPの検出と修正を必要とするかはともに予測できる方法とサービスレベル協定の規制のサービスが提供されている中で亡命されます。 単に、置かれます、ことによるとそれを修正するか、または顧客に通知することによって、欠陥を見つけるのにOAMツールを要して、時間が、操作上のサポート・システムがこの欠陥に反応する必要があった時の合計は問題のサービスレベル協定の領域の中に下がらなければなりません。
Synchronization of detection time bounds by tools used to detect broken LSPs is required. Failure to specify defect detection time bounds may result in an ambiguity in test results. If the time to detect broken LSPs is known, then automated responses can be specified with respect and regard to resiliency and service level specification reporting. Further, if synchronization of detection time bounds is possible, an operational framework can be established to guide the design and specification of MPLS applications.
壊れているLSPsを検出するのに使用されるツールによる検出時間領域の同期が必要です。 欠陥検出時間領域を指定しない場合、試験の成績におけるあいまいさをもたらすかもしれません。 壊れているLSPsを検出する時間が知られているなら、弾性への敬意と尊敬とサービスレベル仕様が報告している状態で、自動化された応答を指定できます。 さらに、検出時間領域の同期が可能であるなら、MPLSアプリケーションのデザインと仕様を誘導するために操作上のフレームワークを確立できます。
Although an ICMP-based ping [RFC792] can be sent through an LSP as an IP payload, the use of this tool to verify the defect-free operation of an LSP has the potential of returning erroneous results (both positive and negative) for a number of reasons. For example, in some cases, because the ICMP traffic is based on legally addressable IP addressing, it is possible for ICMP messages that are originally transmitted inside of an LSP to "fall out of the LSP" at some point along the path. In these cases, since ICMP packets are routable, a falsely positive response may be returned. In other cases, where the data plane of a specific LSP needs to be tested, it is difficult to guarantee that traffic based on an ICMP ping header is parsed and hashed to the same equal-cost multi-paths (ECMP) as the data traffic.
IPペイロードとしてLSPを通してICMPベースのピング[RFC792]を送ることができますが、LSPの無欠陥の操作について確かめるこのツールの使用は様々な意味で(ともに積極的で否定的)であるのに戻っている誤った結果の可能性を持っています。 例えば、ICMPトラフィックが法的にアドレス可能なIPアドレシングに基づいているので、いくつかの場合、元々中に送られるLSPに関するICMPメッセージには、経路に沿った何らかのポイントの「LSPから、落下します」は可能です。 ICMPパケットが発送可能な時からこれらの場合では、間違って積極的な応答を返すかもしれません。 他の場合では、ICMPピングヘッダーに基づくトラフィックがデータ通信量と同じ等しい費用マルチ経路(ECMP)に分析されて、論じ尽くされるのを保証するのは難しいです。そこでは、特定のLSPのデータ飛行機がテストされる必要があります。
Any detection mechanisms that depend on receiving the status via a return path SHOULD provide multiple return options with the expectation that one of them will not be impacted by the original
オリジナルで影響を与えて、SHOULDが期待によるならないそれらの1つがそうである複数のリターンオプションを提供するリターンパスを通って状態を取るのによるどんな検出メカニズム
Nadeau, et al. Informational [Page 5] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[5ページ]のRFC4377OAM要件
defect. An example of a case where a false negative might occur would be a mechanism that requires a functional MPLS return path. Since MPLS LSPs are unidirectional, it is possible that although the forward LSP, which is the LSP under test, might be functioning, the response from the destination LSR might be lost, thus giving the source LSR the false impression that the forward LSP is defective. However, if an alternate return path could be specified -- say IP for example -- then the source could specify this as the return path to the destination, and in this case, would receive a response indicating that the return LSP is defective.
亡命してください。 有病誤診が現れるかもしれないケースに関する例は機能的なMPLSリターンパスを必要とするメカニズムでしょう。 MPLS LSPsが単方向ので、前進のLSP(テスト中のLSPである)が機能しているかもしれませんが、目的地LSRからの応答が失われているのは、可能です、その結果、前進のLSPが欠陥があるという間違った印象をソースLSRに与えます。 しかしながら、代替のリターンパスを指定できるなら(例えばIPを言ってください)、情報筋はリターンパスとして目的地にこれを指定できるでしょうに、そして、この場合、リターンLSPは欠陥があるのを示す応答を受けるでしょう。
The OAM packet MUST follow the customer data path exactly in order to reflect path liveliness used by customer data. Particular cases of interest are forwarding mechanisms, such as ECMP scenarios within the operator's network, whereby flows are load-shared across parallel paths (i.e., equal IGP cost). Where the customer traffic may be spread over multiple paths, the ability to detect failures on any of the path permutations is required. Where the spreading mechanism is payload specific, payloads need to have forwarding that is common with the traffic under test. Satisfying these requirements introduces complexity into ensuring that ECMP connectivity permutations are exercised and that defect detection occurs in a reasonable amount of time.
OAMパケットは、顧客データによって使用される経路活気を反映するためにまさに顧客データ経路に続かなければなりません。 興味がある特定のケースはメカニズムを進めています、オペレータのネットワークの中のECMPシナリオなどのように。流れは平行な経路(すなわち、等しいIGP費用)の向こう側に負荷によってネットワークが共有されています。 顧客トラフィックが複数の経路にわたって広げられるかもしれないところでは、経路順列のどれかに失敗を検出する能力が必要です。 普及のメカニズムがどこのそれを進める持っている特定のペイロードペイロードの必要性であるかはテスト中のトラフィックについて一般的です。 これらの要件を満たすと、ECMP接続性順列が運動させられて、欠陥検出が妥当な時間で起こるのを確実にするのに複雑さは導入されます。
4.2. Diagnosis of a Broken Label Switched Path
4.2. 起伏の多いラベル切り換えられた経路の診断
The ability to diagnose a broken LSP and to isolate the failed component (i.e., link or node) in the path is required. For example, note that specifying recovery actions for mis-branching defects in an LDP network is a particularly difficult case. Diagnosis of defects and isolation of the failed component is best accomplished via a path trace function that can return the entire list of LSRs and links used by a certain LSP (or at least the set of LSRs/links up to the location of the defect). The tracing capability SHOULD include the ability to trace recursive paths, such as when nested LSPs are used. This path trace function MUST also be capable of diagnosing LSP mis- merging by permitting comparison of expected vs. actual forwarding behavior at any LSR in the path. The path trace capability SHOULD be capable of being executed from the head-end Label Switching Router (LSR) and may permit downstream path components to be traced from an intermediate mid-point LSR. Additionally, the path trace function MUST have the ability to support ECMP scenarios described in Section 4.1.
壊れているLSPを診断して、経路で失敗したコンポーネント(すなわち、リンクかノード)を隔離する能力が必要です。 例えば、自由民主党ネットワークで誤分岐欠陥のための回復動作を指定するのが、特に気難しい人であることに注意してください。 あるLSP(または、少なくとも欠陥の位置までのLSRs/リンクのセット)によって使用されたLSRsとリンクの全体のリストを返すことができる経路跡の機能で欠陥の診断と失敗したコンポーネントの分離を実行するのは最も良いです。 追跡能力SHOULDは入れ子にされたLSPsが使用されている時などの再帰的な経路をたどる能力を含んでいます。 また、この経路跡の機能は経路でのいずれの実際の推進の振舞いに対して予想されたLSRの比較を可能にすることによって誤合併しているLSPを診断できなければなりません。 経路跡の能力SHOULDは、ギヤエンドLabel Switching Router(LSR)から実行できて、川下で経路コンポーネントが中間的中点LSRからたどられるのを可能にするかもしれません。 さらに、経路跡の機能には、セクション4.1で説明されたシナリオをECMPにサポートする能力がなければなりません。
Nadeau, et al. Informational [Page 6] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[6ページ]のRFC4377OAM要件
4.3. Path Characterization
4.3. 経路特殊化
The path characterization function is the ability to reveal details of LSR forwarding operations. These details can then be compared during subsequent testing relevant to OAM functionality. This includes but is not limited to:
経路特殊化機能はLSR推進操作の詳細を明らかにする能力です。 そして、OAMの機能性に関連しているその後のテストの間、これらの詳細を比較できます。 含んでいますが、これは制限されません:
- consistent use of pipe or uniform time to live (TTL) models by
an LSR [RFC3443].
- LSR[RFC3443]によってパイプか生きる一定の時間(TTL)の一貫した使用はモデル化されます。
- sufficient details that allow the test origin to exercise all
path permutations related to load spreading (e.g., ECMP).
- テスト発生源がすべての経路順列を運動させることができる十分な詳細は負荷普及(例えば、ECMP)に関連しました。
- stack operations performed by the LSR, such as pushes, pops,
and TTL propagation at penultimate hop LSRs.
- LSRによって実行された終わりから二番目のホップLSRsでのプッシュや、ポップスや、TTL伝播などの操作を積み重ねてください。
4.4. Service Level Agreement Measurement
4.4. サービス・レベル・アグリーメント測定
Mechanisms are required to measure the diverse aspects of Service Level Agreements, which include:
メカニズムはサービス・レベル・アグリーメントのさまざまの局面を測定しなければなりません。(局面は以下の通りです)。
- latency - amount of time required for traffic to transit the
network
- 潜在--時間はトラフィックのためにトランジットへのネットワークを必要としました。
- packet loss
- パケット損失
- jitter - measurement of latency variation
- ジター--潜在変化の測定
- defect free forwarding - the service is considered to be
available, or the service is unavailable and other aspects of
performance measurement do not have meaning.
- 欠陥の無料の推進--サービスが利用可能であると考えられるか、サービスは入手できなく、または性能測定の他の局面には意味がありません。
Such measurements can be made independently of the user traffic or via a hybrid of user traffic measurement and OAM probing.
ユーザトラフィックの如何にかかわらずユーザトラフィック測定とOAMの調べのハイブリッドでそのような測定をすることができます。
At least one mechanism is required to measure the number of OAM packets. In addition, the ability to measure the quantitative aspects of LSPs, such as jitter, delay, latency, and loss, MUST be available in order to determine whether the traffic for a specific LSP is traveling within the operator-specified tolerances.
少なくとも1つのメカニズムが、OAMパケットの数を測定するのに必要です。 さらに、ジターなどのLSPsの量的な局面を測定する能力(遅れ、潜在、および損失)は、特定のLSPのためのトラフィックがオペレータによって指定された寛容の中を移動しているかどうか決定するために利用可能でなければなりません。
Any method considered SHOULD be capable of measuring the latency of an LSP with minimal impact on network resources. See Section 2.1 for definitions of the various quantitative aspects of LSPs.
どんなメソッドも、ネットワーク資源の上に最小量の影響がある状態でSHOULDがLSPの潜在を測定できると考えました。 LSPsの様々な量的な局面の定義に関してセクション2.1を見てください。
Nadeau, et al. Informational [Page 7] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[7ページ]のRFC4377OAM要件
4.5. Frequency of OAM Execution
4.5. OAM実行の頻度
The operator MUST have the flexibility to configure OAM parameters to meet their specific operational requirements.
オペレータには、それらの特定の操作上の必要条件を満たすためにOAMパラメタを構成する柔軟性がなければなりません。
This includes the frequency of the execution of any OAM functions. The ability to synchronize OAM operations is required to permit a consistent measurement of service level agreements. To elaborate, there are defect conditions, such as mis-branching or misdirection of traffic, for which probe-based detection mechanisms that incur significant mismatches in their detection frequency may result in flapping. This can be addressed either by synchronizing the rate or having the probes self-identify their probe rate. For example, when the probing mechanisms are bootstrapping, they might negotiate and ultimately agree on a probing rate, therefore providing a consistent probing frequency and avoiding the aforementioned problems.
これはどんなOAM機能の実行の頻度も含んでいます。 OAM操作を同時にさせる能力が、サービスレベル協定の一貫した測定を可能にするのに必要です。 詳述するために、欠陥状態があります、誤分岐やトラフィックの誤まった指示などのように。((トラフィックのためにばたつくことをもたらすかもしれません)それらの検出頻度における重要なミスマッチを被る徹底的調査ベースの検出メカニズム)。 レートを同期させるか、または徹底的調査にそれらの徹底的調査率を自己に特定させることによって、これを扱うことができます。 例えば、調べメカニズムが結局独力で進むとき、彼らは、交渉して、調べレートに同意するかもしれません、したがって、一貫した調べ頻度を提供して、前述の問題を避けて。
One observation would be that wide-spread deployment of MPLS, common implementation of monitoring tools, and the need for inter-carrier synchronization of defect and service level specification handling will drive specification of OAM parameters to commonly agreed on values. Such values will have to be harmonized with the surrounding technologies (e.g., SONET/SDH, ATM) to be useful. This will become particularly important as networks scale and mis-configuration can result in churn, alarm flapping, etc.
1つの観測はMPLSの広範囲の展開、モニターしているツールの一般的な実装、および欠陥とサービスレベル仕様取り扱いの相互キャリヤー同期の必要性が一般的に同意された値にOAMパラメタの仕様を追い立てるということでしょう。 役に立つ周囲の技術(例えば、Sonet/SDH、ATM)でそのような値は調和させるために望んでいます。 ネットワークが比例するとき、これは特に重要になるでしょう、そして、誤構成は攪乳器、アラームのばたつくことをもたらすことができます。
4.6. Alarm Suppression, Aggregation, and Layer Coordination
4.6. アラーム抑圧、集合、および層のコーディネート
Network elements MUST provide alarm suppression functionality that prevents the generation of a superfluous generation of alarms by simply discarding them (or not generating them in the first place), or by aggregating them together, thereby greatly reducing the number of notifications emitted. When viewed in conjunction with the requirement in Section 4.7 below, this typically requires fault notification to the LSP egress that may have specific time constraints if the application using the LSP independently implements path continuity testing (for example, ATM I.610 Continuity check (CC)[I610]). These constraints apply to LSPs that are monitored. The nature of MPLS applications allows for the possibility of having multiple MPLS applications attempt to respond to defects simultaneously, e.g., layer-3 MPLS VPNs that utilize Traffic Engineered tunnels where a failure occurs on the LSP carrying the Traffic Engineered tunnel. This failure would affect the VPN traffic that uses the tunnel's LSP. Mechanisms are required to coordinate network responses to defects.
ネットワーク要素は単に、それら(第一にそれらを生成しないで)を捨てるか、またはそれらに一緒に集めることによってアラームの余計な世代の世代を防ぐアラーム抑圧の機能性を提供しなければなりません、その結果、放たれた通知の数を大いに減少させます。 以下のセクション4.7における要件に関連して見られると、これは独自にLSPを使用するアプリケーションが経路連続テストを実装するなら(例えば、ATM I.610 Continuityは(CC)[I610]をチェックします)特定の時間規制を持っているかもしれないLSP出口に欠点通知を通常必要とします。 これらの規制はモニターされるLSPsに適用されます。 MPLSアプリケーションの本質は同時に欠陥に応じる複数のMPLSアプリケーション試み、例えば層-3を持っている可能性のために失敗がTraffic Engineeredトンネルを運ぶLSPに起こるTraffic Engineeredトンネルを利用するMPLS VPNsを許容します。 この失敗はトンネルのLSPを使用するVPNトラフィックに影響するでしょう。 メカニズムは欠陥へのネットワーク応答を調整しなければなりません。
Nadeau, et al. Informational [Page 8] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[8ページ]のRFC4377OAM要件
4.7. Support for OAM Inter-working for Fault Notification
4.7. 欠点によって通知を織り込むOAMのサポート
An LSR supporting the inter-working of one or more networking technologies over MPLS MUST be able to translate an MPLS defect into the native technology's error condition. For example, errors occurring over an MPLS transport LSP that supports an emulated ATM VC MUST translate errors into native ATM OAM Alarm Indication Signal (AIS) cells at the termination points of the LSP. The mechanism SHOULD consider possible bounded detection time parameters, e.g., a "hold off" function before reacting to synchronize with the OAM functions.
LSR、MPLS MUSTの上で1つ以上のネットワーク・テクノロジーを織り込むことをサポートして、固有の技術のエラー条件にMPLS欠陥を翻訳できてください。 例えば、見習われたATM VC MUSTをサポートするMPLS輸送LSPの上に発生する誤りはLSPの終了先のネイティブのATM OAM Alarm Indication Signal(AIS)セルに誤りを翻訳します。 メカニズムSHOULDは、可能な境界がある検出が時間パラメタ(例えば、OAM機能に連動するように反応する前の「距離を保ってください」という機能)であると考えます。
One goal would be alarm suppression by the upper layer using the LSP. As observed in Section 4.5, this requires that MPLS perform detection in a bounded timeframe in order to initiate alarm suppression prior to the upper layer independently detecting the defect.
1つの目標はLSPを使用する上側の層のそばでのアラーム抑圧でしょう。 セクション4.5で観測されるように、これは、MPLSが上側の層の前で独自にアラーム抑圧を開始するために欠陥を検出しながら境界がある時間枠で検出を実行するのを必要とします。
4.8. Error Detection and Recovery
4.8. 誤り検出と回復
Recovery from a fault by a network element can be facilitated by MPLS OAM procedures. These procedures will detect a broader range of defects than that of simple link and node failures. Since MPLS LSPs may span multiple routing areas and service provider domains, fault recovery and error detection should be possible in these configurations as well as in the more simplified single-area/domain configurations.
MPLS OAM手順でネットワーク要素に従った欠点からの回復を容易にすることができます。 これらの手順は単リンクとノード障害のものより広い範囲の欠陥を検出するでしょう。 MPLS LSPsが複数のルーティング領域とサービスプロバイダードメインにかかるかもしれないので、欠点回復と誤り検出はこれらの構成と、より簡易型のただ一つの領域/ドメイン構成で可能であるべきです。
Recovery from faults SHOULD be automatic. It is a requirement that faults SHOULD be detected (and possibly corrected) by the network operator prior to customers of the service in question detecting them.
回復、欠点SHOULDから、オートマチックはそうです。 それは欠点SHOULDが彼らを検出しながら問題にサービスの顧客の前にネットワーク・オペレータによって検出されるという(そして、ことによると修正されます)要件です。
4.9. Standard Management Interfaces
4.9. 標準の管理インタフェース
The wide-spread deployment of MPLS requires common information modeling of management and control of OAM functionality. Evidence of this is reflected in the standard IETF MPLS-related MIB modules (e.g., [RFC3813][RFC3812][RFC3814]) for fault, statistics, and configuration management. These standard interfaces provide operators with common programmatic interface access to Operations and Management functions and their statuses. However, gaps in coverage of MIB modules to OAM and other features exist; therefore, MIB modules corresponding to new protocol functions or network tools are required.
MPLSの広範囲の展開は管理の一般的な情報モデルとOAMの機能性のコントロールを必要とします。 この証拠は欠点、統計、および構成管理のために標準のIETF MPLS関連のMIBモジュール(例えば、[RFC3813][RFC3812][RFC3814])に反映されます。 これらの標準インターフェースはOperations、Management機能、およびそれらの状態への一般的なプログラムに従ったインタフェースアクセスをオペレータに提供します。 しかしながら、OAMへのMIBモジュールと他の特徴の適用範囲のギャップは存在しています。 したがって、新しいプロトコル機能かネットワークツールに対応するMIBモジュールが必要です。
Nadeau, et al. Informational [Page 9] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[9ページ]のRFC4377OAM要件
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 MUST be part of any security management related to MPLS OAM tools or techniques.
データか制御飛行機に対してサービス(DoS)攻撃の否定を検出する能力はMPLS OAMツールかテクニックに関連するどんなセキュリティ管理の一部であるに違いありません。
4.11. Per-LSP Accounting Requirements
4.11. 1LSPあたりの会計要件
In an MPLS network, service providers can measure traffic from an LSR to the egress of the network using some MPLS related MIBs, for example. This means that it is reasonable to know how much traffic is traveling from location to location (i.e., a traffic matrix) by analyzing the flow of traffic. Therefore, traffic accounting in an MPLS network can be summarized as the following three items:
MPLSネットワークでは、サービスプロバイダーは例えばいくつかのMPLSの関連するMIBsを使用するLSRからネットワークの出口までのトラフィックを測定できます。 これは、どのくらいのトラフィックがトラフィックの流れを分析することによって位置から位置(すなわち、トラフィックマトリクス)まで移動しているかを知るのが妥当であることを意味します。 したがって、以下の3つの項目としてMPLSネットワークにおけるトラフィック会計をまとめることができます:
(1) Collecting information to design network
(1) ネットワークを設計する情報集め
For the purpose of optimized network design, a service
provider may offer the traffic information. Optimizing
network design needs this information.
最適化されたネットワークデザインの目的のために、サービスプロバイダーは道路交通情報を提供するかもしれません。 ネットワークデザインを最適化すると、この情報は必要とします。
(2) Providing a Service Level Specification
(2) サービスレベル指定を提供すること。
Providers and their customers MAY need to verify high-level
service level specifications, either to continuously optimize
their networks, or to offer guaranteed bandwidth services.
Therefore, traffic accounting to monitor MPLS applications is
required.
プロバイダーと彼らの顧客は、ハイレベルのサービスレベル仕様、絶え間なくそれらのネットワークを最適化するどちらかについて確かめるか、または保証された帯域幅サービスを提供する必要があるかもしれません。 したがって、モニターMPLSアプリケーションについて報告するトラフィックが必要です。
(3) Inter-AS environment
(3) 相互AS環境
Service providers that offer inter-AS services require
accounting of those services.
サービスが必要とする相互ASにそれらのサービスの会計を提供するサービスプロバイダー。
These three motivations need to satisfy the following:
これらの3つの動機が、以下を満たす必要があります:
- In (1) and (2), collection of information on a per-LSP
basis is a minimum level of granularity for collecting
accounting information at both of ingress and egress of an
LSP.
- (1)と(2)では、1LSPあたり1個のベースにおける情報の収集は、イングレスの両方とLSPの出口に課金情報を集めるための最低水準の粒状です。
- In (3), SP's ASBR carry out interconnection functions as an
intermediate LSR. Therefore, identifying a pair of ingress
and egress LSRs using each LSP is needed to determine the
cost of the service that a customer is using.
- (3)では、SPのASBRは中間的LSRとしてインタコネクト機能を行います。 したがって、各LSPを使用することで1組のイングレスと出口LSRsを特定するのが、顧客が利用しているサービスの費用を決定するのに必要です。
Nadeau, et al. Informational [Page 10] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[10ページ]のRFC4377OAM要件
4.11.1. Requirements
4.11.1. 要件
Accounting on a per-LSP basis encompasses the following set of functions:
1LSPあたり1個のベースにおける会計は以下の関数群を取り囲みます:
(1) At an ingress LSR, accounting of traffic through LSPs that
begin at each egress in question.
イングレスLSR、問題のそれぞれの出口で始まるLSPsを通したトラフィックの会計における(1)。
(2) At an intermediate LSR, accounting of traffic through LSPs for
each pair of ingress to egress.
中間的LSR、それぞれの組の出口へのイングレスのためのLSPsを通したトラフィックの会計における(2)。
(3) At egress LSR, accounting of traffic through LSPs for each
ingress.
出口LSRの(3)、各イングレスのためのLSPsを通したトラフィックの会計。
(4) All LSRs containing LSPs that are being measured need to have
a common identifier to distinguish each LSP. The identifier
MUST be unique to each LSP, and its mapping to LSP SHOULD be
provided whether from manual or automatic configuration.
(4) 測定されているLSPsを含むすべてのLSRsが、各LSPを区別するために一般的な識別子を必要とします。 識別子は各LSPにユニークであるに違いありません、そして、それは写像しています。LSP SHOULDに、マニュアルか自動構成にかかわらず供給してください。
In the case of non-merged LSPs, this can be achieved by simply
reading traffic counters for the label stack associated with the
LSP at any LSR along its path. However, in order to measure
merged LSPs, an LSR MUST have a means to distinguish the source of
each flow so as to disambiguate the statistics.
非合併しているLSPsの場合では、経路に沿ったどんなLSRのLSPにも関連しているラベルスタックのために単に交通カウンタを読むことによって、これを達成できます。 しかしながら、測定するために、合併しているLSPs、LSR MUSTには、統計のあいまいさを除くためにそれぞれの流れの源を区別する手段があります。
4.11.2. Location of Accounting
4.11.2. 会計の位置
It is not realistic for LSRs to perform the described operations on all LSPs that exist in a network. At a minimum, per-LSP based accounting SHOULD be performed on the edges of the network -- at the edges of both LSPs and the MPLS domain.
LSRsがネットワークで存在するすべてのLSPsに説明された操作を実行するのは、現実的ではありません。 最小限、SHOULDを説明しながら基づくLSPでは、LSPsとMPLSドメインの両方の縁のネットワークの縁に実行されてください。
5. Security Considerations
5. セキュリティ問題
Provisions to any of the network mechanisms designed to satisfy the requirements described herein are required to prevent their unauthorized use. Likewise, these network mechanisms MUST provide a means by which an operator can prevent denial of service attacks if those network mechanisms are used in such an attack.
ここに説明された要件を満たすように設計されたネットワークメカニズムのどれかへの条項が、彼らの無断使用を防ぐのに必要です。 同様に、これらのネットワークメカニズムはそれらのネットワークメカニズムがそのような攻撃に使用されるならオペレータがサービス不能攻撃を防ぐことができる手段を提供しなければなりません。
LSP mis-merging has security implications beyond that of simply being a network defect. LSP mis-merging can happen due to a number of potential sources of failure, some of which (due to MPLS label stacking) are new to MPLS.
LSP誤合併には、単にネットワーク欠陥であるものを超えてセキュリティ意味があります。 LSP誤合併は失敗の多くの可能な源のため起こることができます。それの或るものは源のためにMPLSに新しいです(MPLSのため、積み重ねをラベルしてください)。
The performance of diagnostic functions and path characterization involve extracting a significant amount of information about network construction that the network operator MAY consider private.
診断機能の性能と経路特殊化は、ネットワーク・オペレータが個人的であると考えるかもしれないネットワーク構築に関して重要な情報量を抽出することを伴います。
Nadeau, et al. Informational [Page 11] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[11ページ]のRFC4377OAM要件
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月。
6.2. Informative References
6.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を飲み込みます。
[RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Traffic Engineering
(TE) Management Information Base (MIB)", RFC 3812, June
2004.
[RFC3812] Srinivasan、C.、Viswanathan、A.、およびT.ナドー、「Multiprotocolは交通工学(Te)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3812、2004年6月。
[RFC3813] Srinivasan, C., Viswanathan, A., and T. Nadeau,
"Multiprotocol Label Switching (MPLS) Label Switching
Router (LSR) Management Information Base (MIB)", RFC 3813,
June 2004.
[RFC3813] Srinivasan、C.、Viswanathan、A.、およびT.ナドー、「Multiprotocolはラベル切り換えルータ(LSR)管理情報ベース(MIB)と切り換え(MPLS)をラベルします」、RFC3813、2004年6月。
[RFC3814] Nadeau, T., Srinivasan, C., and A. Viswanathan,
"Multiprotocol Label Switching (MPLS) Forwarding
Equivalence Class To Next Hop Label Forwarding Entry
(FEC-To-NHLFE) Management Information Base (MIB)", RFC
3814, June 2004.
[RFC3814] ナドー、T.、Srinivasan、C.、およびA.Viswanathan、「次に跳ぶために同値類を進めるMultiprotocolラベル切り換え(MPLS)が推進エントリー(FECからNHLFE)を管理情報ベース(MIB)とラベルします」、RFC3814、2004年6月。
[Y1710] ITU-T Recommendation Y.1710, "Requirements for OAM
Functionality In MPLS Networks"
[Y1710]ITU-T推薦Y.1710、「MPLSネットワークにおけるOAMの機能性のための要件」
[I610] ITU-T Recommendation I.610, "B-ISDN operations and
maintenance principles and functions", February 1999
1999年2月の[I610]ITU-T Recommendation I.610と、「B-ISDN操作、維持原則、および機能」
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2434]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC
792, September 1981.
[RFC792] ポステル、J.、「インターネット・コントロール・メッセージ・プロトコル」、STD5、RFC792、1981年9月。
Nadeau, et al. Informational [Page 12] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[12ページ]のRFC4377OAM要件
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in
Multi-Protocol Label Switching (MPLS) Networks", RFC 3443,
January 2003.
[RFC3443]AgarwalとP.とB.Akyol、「生きるマルチプロトコルラベルスイッチング(MPLS)ネットワークで処理される時間(TTL)」、RFC3443、2003年1月。
7. Acknowledgements
7. 承認
The authors wish to acknowledge and thank the following individuals for their valuable comments to this document: Adrian Smith, British Telecom; Chou Lan Pok, SBC; Mr. Ikejiri, NTT Communications; and Mr. Kumaki, KDDI. Hari Rakotoranto, Miya Kohno, Cisco Systems; Luyuan Fang, AT&T; Danny McPherson, TCB; Dr. Ken Nagami, Ikuo Nakagawa, Intec Netcore, and David Meyer.
作者は、このドキュメントへの彼らの貴重なコメントについて以下の個人に承認して、感謝したがっています: エードリアン・スミス、ブリティッシュ・テレコム。 町ランPok、SBC。 Ikejiriさん、NTTコミュニケーション。 Kumakiさん、KDDI。 ハーリRakotoranto、河野美哉、シスコシステムズ。 Luyuan牙、AT&T。 ダニーMcPherson、TCB。 インテックのケンNagami博士、Ikuo中川、Netcore、およびデヴィッド・マイヤー。
Authors' Addresses
作者のアドレス
Comments should be made directly to the MPLS mailing list at mpls@lists.ietf.org.
mpls@lists.ietf.org でコメントを直接MPLSメーリングリストにするべきです。
Thomas D. Nadeau Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719
トーマスD.ナドーシスコシステムズInc.300ビーバーブルック道路Boxboro、MA 01719
Phone: +1-978-936-1470 EMail: tnadeau@cisco.com
以下に電話をしてください。 +1-978-936-1470 メールしてください: tnadeau@cisco.com
Monique Jeanne Morrow Cisco Systems, Inc. Glatt-Com, 2nd Floor CH-8301 Switzerland
モニークジャンヌ翌日のシスコシステムズInc.グラット-Com、2階のCH-8301スイス
Phone: (0)1 878-9412 EMail: mmorrow@cisco.com
以下に電話をしてください。 (0)1 878-9412 メールしてください: mmorrow@cisco.com
George Swallow Cisco Systems, Inc. 300 Beaver Brook Road Boxboro, MA 01719
ジョージツバメシスコシステムズInc.300ビーバーブルック道路Boxboro、MA 01719
Phone: +1-978-936-1398 EMail: swallow@cisco.com
以下に電話をしてください。 +1-978-936-1398 メールしてください: swallow@cisco.com
Nadeau, et al. Informational [Page 13] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[13ページ]のRFC4377OAM要件
David Allan Nortel Networks 3500 Carling Ave. Ottawa, Ontario, CANADA
デヴィッドアランノーテルは3500縦梁Aveをネットワークでつなぎます。 オタワ、オンタリオ(カナダ)
Phone: 1-613-763-6362 EMail: dallan@nortel.com
以下に電話をしてください。 1-613-763-6362 メールしてください: dallan@nortel.com
Satoru Matsushima Japan Telecom 1-9-1, Higashi-Shinbashi, Minato-ku Tokyo, 105-7316 Japan
Satoru日本松島テレコム1-9-1、Higashi-新橋、東京、港区105-7316日本
Phone: +81-3-6889-1092 EMail: satoru@ft.solteria.net
以下に電話をしてください。 +81-3-6889-1092 メールしてください: satoru@ft.solteria.net
Nadeau, et al. Informational [Page 14] RFC 4377 OAM Requirements for MPLS Networks February 2006
ナドー、他 MPLSネットワーク2006年2月のための情報[14ページ]のRFC4377OAM要件
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)によって提供されます。
Nadeau, et al. Informational [Page 15]
ナドー、他 情報[15ページ]
一覧
スポンサーリンク
