RFC4378 日本語訳

Network Working Group                                      D. Allan, Ed.
Request for Comments: 4378                               Nortel Networks
Category: Informational                                   T. Nadeau, Ed.
                                                     Cisco Systems, Inc.
                                                           February 2006

ワーキンググループのD.アラン、エドをネットワークでつないでください。コメントのために以下を要求してください。 4378 ノーテルはカテゴリをネットワークでつなぎます: エド情報のT.ナドー、シスコシステムズInc.2006年2月

         A Framework for Multi-Protocol Label Switching (MPLS)
                    Operations and Management (OAM)

マルチプロトコルラベルスイッチング(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

要約

   This document is a framework for how data plane protocols can be
   applied to operations and maintenance procedures for Multi-Protocol
   Label Switching (MPLS).  The document is structured to outline how
   Operations and Management (OAM) functionality can be used to assist
   in fault, configuration, accounting, performance, and security
   management, commonly known by the acronym FCAPS.

このドキュメントは、どうデータ飛行機プロトコルを操作に適用できるように枠組みとMulti-プロトコルLabel Switching(MPLS)のための保守手順であるか。 ドキュメントは、頭文字語FCAPSによって一般的に知られていた欠点、構成、会計、性能、およびセキュリティ管理を助けるのにどうOperationsとManagement(OAM)の機能性を使用できるかを概説するために構造化されます。

Table of Contents

目次

   1. Introduction ....................................................2
   2. Terminology .....................................................2
   3. Fault Management ................................................2
      3.1. Fault Detection ............................................2
      3.2. Diagnosis ..................................................6
      3.3. Availability ...............................................7
   4. Configuration Management ........................................7
   5. Accounting ......................................................7
   6. Performance Management ..........................................7
   7. Security Management .............................................8
   8. Security Considerations .........................................9
   9. Acknowledgements ................................................9
   10. Normative References ...........................................9

1. 序論…2 2. 用語…2 3. 障害管理…2 3.1. 欠点検出…2 3.2. 診断…6 3.3. 有用性…7 4. 構成管理…7 5. 会計…7 6. パフォーマンス管理…7 7. セキュリティ管理…8 8. セキュリティ問題…9 9. 承認…9 10. 標準の参照…9

Allan & Nadeau               Informational                      [Page 1]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[1ページ]のRFC4378

1.  Introduction

1. 序論

   This memo outlines in broader terms how data plane protocols can
   assist in meeting the Operations and Management (OAM) requirements
   outlined in [RFC4377] and [Y1710] and can apply to the management
   functions of fault, configuration, accounting, performance, and
   security (commonly known as FCAPS) for MPLS networks, as defined in
   [RFC3031].  The approach of the document is to outline functionality,
   the potential mechanisms to provide the function, and the required
   applicability of data plane OAM functions.  Included in the
   discussion are security issues specific to use of tools within a
   provider domain and use for inter-provider Label Switched Paths
   (LSPs).

このメモは、より広い用語でどうデータ飛行機プロトコルを[RFC4377]と[Y1710]に概説されたOperationsとManagement(OAM)必要条件を満たすのを助けることができて、MPLSネットワークのために欠点、構成、会計、性能、およびセキュリティ(FCAPSとして一般的に知られている)の管理機能に適用できるかを概説します、[RFC3031]で定義されるように。 ドキュメントのアプローチはデータ飛行機OAM機能の機能性、機能を提供する潜在的メカニズム、および必要な適用性について概説することです。 議論に含まれているのは、相互プロバイダーLabel Switched Paths(LSPs)のプロバイダードメインの中でツールの使用に特定の安全保障問題と使用です。

2.  Terminology

2. 用語

   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 [RFC2119].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?

   OAM          Operations and Management

OAM操作と管理

   FCAPS        Fault management, Configuration management,
                Administration management, Performance
                management, and Security management

FCAPS Fault管理、Configuration管理、政権管理、パフォーマンス管理、およびSecurity管理

   FEC          Forwarding Equivalence Class

FEC推進同値類

   ILM          Incoming Label Map

ILMの入って来るラベル地図

   NHLFE        Next Hop Label Forwarding Entry

次のNHLFEはラベル推進エントリーを飛び越します。

   MIB          Management Information Base

MIB管理情報ベース

   LSR          Label Switching Router

LSRラベル切り換えルータ

   RTT          Round Trip Time

RTT周遊旅行時間

3.  Fault Management

3. 障害管理

3.1.  Fault Detection

3.1. 欠点検出

   Fault detection encompasses the identification of all data plane
   failures between the ingress and egress of an LSP.  This section will
   enumerate common failure scenarios and explain how one might (or
   might not) detect the situation.

欠点検出はLSPのイングレスと出口の間のすべてのデータ飛行機の故障の識別を成就します。 または、このセクションが一般的な失敗シナリオを列挙して、その方法を説明する、1がそうするかもしれない、()、状況を検出するかもしれなくなってください。

Allan & Nadeau               Informational                      [Page 2]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[2ページ]のRFC4378

3.1.1.  Enumeration and Detection of Types of Data Plane Faults

3.1.1. データ飛行機欠点のタイプの列挙と検出

   Lower-layer faults:

下層欠点:

      Lower-layer faults are those in the physical or virtual link that
      impact the transport of MPLS labeled packets between adjacent LSRs
      at the specific level of interest.  Some physical links (such as
      SONET/SDH) may have link-layer OAM functionality and detect and
      notify the LSR of link-layer faults directly.  Some physical links
      (such as Ethernet) may not have this capability and require MPLS
      or IP layer heartbeats to detect failures.  However, once
      detected, reaction to these fault notifications is often the same
      as those described in the first case.

下層欠点は物理的であるか仮想のリンクの興味がある特定のレベルでパケットとラベルされたMPLSの輸送に隣接しているLSRsの間に影響を与えるものです。 いくつかの物理的なリンク(Sonet/SDHなどの)が、リンクレイヤ欠点について直接LSRをリンクレイヤOAMの機能性を持って、検出して、通知するかもしれません。 いくつかの物理的なリンク(イーサネットなどの)は、失敗を検出するためにこの能力を持って、MPLSかIP層の鼓動を必要としないかもしれません。 しかしながら、いったん検出されると、これらの欠点通知への反応はものが前者の場合説明したのとしばしば同じです。

   Node failures:

ノード障害:

      Node failures are those that impact the forwarding capability of a
      node component, including its entire set of links.  This can be
      due to component failure, power outage, or reset of the control
      processor in an LSR employing a distributed architecture, etc.

ノード障害は全体のセットのリンクを含むノードコンポーネントの推進能力に影響を与えるものです。 これは分配された構造などを使うLSRでの制御プロセッサのコンポーネント故障、電力供給停止、またはリセットのためであることができます。

   MPLS LSP mis-forwarding:

MPLS LSP誤推進:

      Mis-forwarding occurs when there is a loss of synchronization
      between the data and the control planes in one or more nodes.
      This can occur due to hardware failure, software failure, or
      configuration problems.

データと制御飛行機の間に1つ以上のノードに同期の損失があるとき、誤推進は起こります。 これはハードウェアの故障、ソフトウェア障害、または設定問題のため起こることができます。

      It will manifest itself in one of two forms:

それは2つのフォームの1つに現れるでしょう:

      -  packets belonging to a particular LSP are cross-connected into
         an NHLFE for which there is no corresponding ILM at the next
         downstream LSR.  This can occur in cases where the NHLFE entry
         is corrupted.  Therefore, the packet arrives at the next LSR
         with a top label value for which the LSR has no corresponding
         forwarding information, and is typically dropped.  This is a No
         Incoming Label Map (No ILM) condition and can be detected
         directly by the downstream LSR that receives the incorrectly
         labeled packet.

- 特定のLSPに属すパケットはどんな対応するILMも次の川下にないNHLFEに十字で接続されたLSRです。 これはNHLFEエントリーが崩壊する場合で起こることができます。 したがって、パケットはLSRがどんな対応する推進情報も持たないで、通常落とされる最高ラベル値と共に次のLSRに到着します。 これを、いいえIncoming Label Map(ILMがない)状態であり、直接不当にラベルされたパケットを受ける川下のLSRは検出できます。

      -  packets belonging to a particular LSP are cross-connected into
         an incorrect NHLFE entry for which there is a corresponding ILM
         at the next downstream LSR, but is associated with a different
         LSP.  This may be detected by the following:

- 特定のLSPに属すパケットは、対応するILMが次の川下にある不正確なNHLFEエントリーに十字で接続されたLSRですが、異なったLSPに関連しています。 これは以下によって検出されるかもしれません:

         o  some or all of the misdirected traffic is not routable at
            the egress node, or

o または的外れの交通のいくつかかすべてが出口ノードで発送可能であるというわけではない。

Allan & Nadeau               Informational                      [Page 3]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[3ページ]のRFC4378

         o  OAM probing is able to detect the fault by detecting the
            inconsistency between the data path and the control plane
            state.

o OAMの調べは、データ経路とコントロール飛行機状態の間の矛盾を検出することによって、欠点を検出できます。

   Discontinuities in the MPLS Encapsulation

MPLSカプセル化における不連続

      The forwarding path of the FEC carried by an LSP may transit nodes
      or links for which MPLS is not configured.  This may result in a
      number of behaviors that are undesirable and not easily detected.

LSPによって運ばれたFECの推進経路はMPLSが構成されないトランジットノードかリンクがそうするかもしれません。 これは多くの望ましくなくて容易に検出されなかった振舞いをもたらすかもしれません。

      -  if exposed, payload is not routable at the LSR, resulting in
         silent discard, OR

- 露出されるなら、静かな破棄、ORをもたらして、ペイロードはLSRで発送可能ではありません。

      -  the exposed MPLS label was not offered by the LSR, which may
         result in either silent discard or mis-forwarding.

- 露出しているMPLSラベルはLSRによって提供されませんでした。(LSRは静かな破棄か誤推進のどちらかをもたらすかもしれません)。

      Alternately, the payload may be routable and packets successfully
      delivered but may bypass associated MPLS instrumentation and
      tools.

交互に、ペイロードは、首尾よく届けられた発送可能とパケットであるかもしれませんが、関連MPLS計装とツールを迂回させるかもしれません。

   MTU problems

MTU問題

      MTU problems occur when client traffic cannot be fragmented by
      intermediate LSRs and is dropped somewhere along the path of the
      LSP.  MTU problems should appear as a discrepancy in the traffic
      count between the set of ingress LSRs and the egress LSRs for an
      FEC and will appear in the corresponding MPLS MIB performance
      tables in the transit LSRs as discarded packets.

クライアント交通が中間的LSRsが断片化できないで、LSPの経路に沿ってどこかに落とされるとき、MTU問題は起こります。 MTU問題は、食い違いとしてFECに関してイングレスLSRsのセットと出口LSRsの間の交通カウントに現れるべきであり、捨てられたパケットとして対応するMPLS MIB性能テーブルにトランジットLSRsに現れるでしょう。

   TTL Mishandling

TTLの誤って扱うこと

      The implementation of TTL handling is inconsistent at penultimate
      hop LSRs.  Tools that rely on consistent TTL processing may
      produce inconsistent results in any given network.

TTL取り扱いの実現は終わりから二番目のホップLSRsで無節操です。 一貫したTTL処理に依存するツールはどんな与えられたネットワークにおいても結果に一貫性がないかもしれません。

   Congestion

混雑

      Congestion occurs when the offered load on any interface exceeds
      the link capacity for sufficient time that the interface buffering
      is exhausted.  Congestion problems will appear as a discrepancy in
      the traffic count between the set of ingress LSRs and the egress
      LSRs for an FEC and will appear in the MPLS MIB performance tables
      in the transit LSRs as discarded packets.

どんなインタフェースの提供された負荷もインタフェースがバッファリングして、疲れ果てている十分な時間のリンク容量を超えていると、混雑は起こります。 混雑問題は、食い違いとしてFECに関してイングレスLSRsのセットと出口LSRsの間の交通カウントに現れて、捨てられたパケットとしてMPLS MIB性能テーブルにトランジットLSRsに現れるでしょう。

Allan & Nadeau               Informational                      [Page 4]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[4ページ]のRFC4378

   Mis-ordering

誤注文

      Mis-ordering of LSP traffic occurs when incorrect or inappropriate
      load sharing is implemented within an MPLS network.  Load sharing
      typically takes place when multiple equal-cost paths exist between
      the ingress and egress of an LSP.  In these cases, traffic is
      split among these equal-cost paths using a variety of algorithms.
      One such algorithm relies on splitting traffic between each path
      on a per-packet basis.  When this is done, it is possible for some
      packets along the path to be delayed due to congestion or slower
      links, which may result in packets being received out of order at
      the egress.  Detection and remedy of this situation may be left up
      to client applications that use the LSPs.  For instance, TCP is
      capable of re-ordering packets belonging to a specific flow
      (although this may result in re-transmission of some of the mis-
      ordered packets).

不正確であるか不適当な負荷分割法がMPLSネットワークの中で実行されるとき、LSP交通の誤注文は起こります。 複数の等しい費用経路がLSPのイングレスと出口の間に存在していると、負荷分割法は通常行われます。 これらの場合では、交通は1パケットあたり1個のベースの各経路の間の交通を分ける. そのようなアルゴリズムのひとりが当てにするさまざまなアルゴリズムを使用するこれらの等しい費用経路の中で分けられます。 これが完了しているとき、経路に沿ったいくつかのパケットが混雑か、より遅いリンクのため遅れるのは、可能です。リンクは出口で故障していた状態で受け取られるパケットをもたらすかもしれません。 この状況の検出と療法はLSPsを使用するクライアントアプリケーションに任せられるかもしれません。 例えば、TCPは特定の流れに属す再注文パケットができます(これがいくつかの誤命令されたパケットの再トランスミッションをもたらすかもしれませんが)。

      Detection of mis-ordering can also be determined by sending probe
      traffic along the path and verifying that all probe traffic is
      indeed received in the order it was transmitted.  This will only
      detect truly pathological problems as mis-ordering typically is an
      insufficiently predictable and repeatable problem.

また、誤注文の検出は経路に沿って徹底的調査交通を送ることによって、決定できるでしょう、そして、本当に、すべての徹底的調査交通がオーダーで受けられることを確かめて、それは伝えられました。 これは、誤注文が通常、不十分に予測できて反復可能な問題であるので、本当に病理学的な問題を検出するだけでしょう。

      LSRs do not normally implement mechanisms to detect mis-ordering
      of flows.

通常、LSRsは、誤注文している流れを検出するためにメカニズムを実行しません。

   Payload Corruption

有効搭載量不正

      Payload corruption may occur and may be undetected by LSRs.  Such
      errors are typically detected by client payload integrity
      mechanisms.

有効搭載量不正は、起こって、LSRsによって非検出されるかもしれません。 そのような誤りはクライアントペイロード保全メカニズムによって通常検出されます。

3.1.2.  Timeliness

3.1.2. タイムリー

   The design of Service Level Agreements (SLAs) and management support
   systems requires that ample headroom be alloted in terms of their
   processing capabilities in order to process and handle all necessary
   fault conditions within the bounds stipulated in the SLA.  This
   includes planning for event handling using a time budget that takes
   into account the over-all SLA and the time required to address any
   defects that arise.  However, it is possible that some fault
   conditions may surpass this budget due to their catastrophic nature
   (e.g., fibre cut) or due to incorrect planning of the time processing
   budget.

サービス・レベル・アグリーメント(SLA)と管理サポート・システムの設計は、十分な空間がSLAで規定された領域の中のすべての必要な欠点状態を処理して、扱うために彼らの処理能力で割り当てられるのを必要とします。 これは、総合的なSLAを考慮に入れる時間予算を使用することでイベント取り扱いの計画を立てるのを含んでいます、そして、時間が起こるどんな欠陥も記述するのが必要です。 しかしながら、いくつかの欠点状態が彼らの壊滅的な本質(例えば、繊維カット)のためか時間処理予算の不正確な計画のためこの予算を凌ぐのは、可能です。

Allan & Nadeau               Informational                      [Page 5]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[5ページ]のRFC4378

         ^    --------------
         |    |           ^
         |    |           |----  Time to notify NOC + process/correct
   SLA   |    |           v      defect
   Max - |    -------------
   Time  |    |           ^
         |    |           |-----  Time to diagnose/isolate/correct
         |    |           v
         v    -------------

^ -------------- | | ^ | | |---- NOC+過程/正しいSLAに通知する時間| | v欠陥マックス、-| ------------- 時間| | ^ | | |----- 診断するか、隔離する、または修正する時間| | vに対して-------------

         Figure 1: Fault Correction Budget

図1: 欠点修正予算

   In figure 1, we represent the overall fault correction time budget by
   the maximum time as specified in an SLA for the service in question.
   This time is then divided into two subsections, the first
   encompassing the total time required to detect a fault and notify an
   operator (or optionally automatically correct the defect).  This
   section may have an explicit maximum time to detect defects arising
   from either the application or a need to do alarm management (i.e.,
   suppression), and this will be reflected in the frequency of OAM
   execution.  The second section indicates the time required to notify
   the operational systems used to diagnose, isolate, and correct the
   defect (if they cannot be corrected automatically).

1図では、私たちは最大の時間までにSLAで問題のサービスに指定されているとして総合的な欠点修正時間予算を表します。 次に、今回は2つの小区分に分割されます、1番目が欠点を検出して、オペレータに通知するのに必要である合計時を取り囲んで(任意に自動的に欠陥を修正してください)。 このセクションには、欠陥がアラーム管理(すなわち、抑圧)をするアプリケーションか必要性のどちらかから起こるのを検出する明白な最大の時間があるかもしれません、そして、これはOAM実行の頻度に反映されるでしょう。 第2セクションは、時間が欠陥を診断して、隔離して、修正するのに使用される基幹系システムに通知するのが必要であることを(自動的にそれらを修正できないなら)示します。

3.2.  Diagnosis

3.2. 診断

3.2.1.  Characterization

3.2.1. 特殊化

   Characterization is defined as determining the forwarding path of a
   packet (which may not be necessarily known).  Characterization may be
   performed on a working path through the network.  For example, this
   is done to determine equal-cost multi-paths (ECMP), the MTU of a
   path, or simply to know the path occupied by a specific FEC.
   Characterization will be able to leverage mechanisms used for
   isolation.

特殊化はパケット(必ず知られているかもしれないというわけではない)の推進経路を決定すると定義されます。 特殊化はネットワークを通して働く経路に実行されるかもしれません。 例えば、等しい費用マルチ経路(ECMP)、経路のMTUを決定するか、または単に特定のFECによって占領された経路を知るためにこれをします。 特殊化は孤立に使用されるメカニズムに投機できるでしょう。

3.2.2.  Isolation

3.2.2. 孤立

   Isolation of a fault can occur in two forms.  In the first case, the
   local failure is detected, and the node where the failure occurred is
   capable of issuing an alarm for such an event.  The node should
   attempt to withdraw the defective resources and/or rectify the
   situation prior to raising an alarm.  Active data plane OAM
   mechanisms may also detect the failure conditions remotely and issue
   their own alarms if the situation is not rectified quickly enough.

欠点の孤立は2つのフォームに起こることができます。前者の場合、局所制御不能は検出されます、そして、失敗が起こったノードはそのような出来事のためのアラームを発行できます。 ノードは、欠陥があるリソースを引き下がらせる、そして/または、警報を発する前に事態を正常化するのを試みるはずです。 事態が十分すぐに収拾されないなら、アクティブなデータ飛行機OAMメカニズムは、また、失敗状態を離れて検出して、それら自身のアラームを発行するかもしれません。

   In the second case, the fault has not been detected locally.  In this
   case, the local node cannot raise an alarm, nor can it be expected to

2番目の場合では、欠点は局所的に検出されていません。 この場合、ローカルのノードは警報を発することができません、そして、それは期待できません。

Allan & Nadeau               Informational                      [Page 6]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[6ページ]のRFC4378

   rectify the situation.  In this case, the failure may be detected
   remotely via data plane OAM.  This mechanism should also be able to
   determine the location of the fault, perhaps on the basis of limited
   information such as a customer complaint.  This mechanism may also be
   able to automatically remove the defective resources from the network
   and restore service, but should at least provide a network operator
   with enough information by which they can perform this operation.
   Given that detection of faults is desired to happen as quickly as
   possible, tools which possess the ability to incrementally test LSP
   health should be used to uncover faults.

事態を正常化してください。 この場合、失敗はデータ飛行機OAMを通して離れて検出されるかもしれません。 また、このメカニズムは欠点の位置を決定するはずであることができます、恐らく顧客の苦情の限られた情報に基づいて。 このメカニズムは、また、ネットワークから欠陥があるリソースを自動的に取り除いて、復旧できるかもしれませんが、それらがこの操作を実行できる十分な情報をネットワーク・オペレータに少なくとも提供するはずです。 欠点の検出ができるだけ急速に起こることが望まれているなら、LSP健康を増加してテストする能力を持っているツールは、欠点の覆いを取るのに使用されるべきです。

3.3.  Availability

3.3. 有用性

   Availability is the measure of the percentage of time that a service
   is operating within a specification, often specified by an SLA.

有用性はサービスがしばしばSLAによって指定された仕様の中で作動する時間の割合の基準です。

   MPLS has several forwarding modes (depending on the control plane
   used).  As such, more than one model may be defined and more than one
   measurement technique may be required.

MPLSには、いくつかの推進モードがあります(使用される制御飛行機によって)。 そういうものとして、1つ以上のモデルが定義されるかもしれません、そして、1つ以上の測定技術が必要であるかもしれません。

4.  Configuration Management

4. 構成管理

   Data plane OAM can assist in configuration management by providing
   the ability to verify the configuration of an LSP or of applications
   utilizing that LSP.  This would be an ad-hoc data plane probe that
   should verify path integrity (a complete path exists) and that the
   path function is synchronized with the control plane.  As part of the
   payload, the probe would carry relevant control plane information
   that the receiver would be able to compare with the local-control
   plane configuration.

データ飛行機OAMは、LSPかそのLSPを利用するアプリケーションの構成について確かめる能力を提供することによって、構成管理を助けることができます。 これは経路保全(完全な経路は存在している)と、経路機能が制御飛行機と同期することを確かめるべきである臨時のデータ飛行機徹底的調査でしょう。 ペイロードの一部として、探測装置は受信機が現場制御飛行機構成と比較できるだろうという関連コントロール飛行機情報を運ぶでしょう。

5.  Accounting

5. 会計

   The requirements for accounting in MPLS networks, as specified in
   [RFC4377], do not place any requirements on data plane OAM.

MPLSネットワークにおける会計のための[RFC4377]で指定される要件はデータ飛行機OAMにどんな要件も置きません。

6.  Performance Management

6. パフォーマンス管理

   Performance management permits the information transfer
   characteristics of LSPs to be measured, perhaps in order to be
   compared against an SLA.  This falls into two categories: latency
   (where jitter is considered a variation in latency) and information
   loss.

パフォーマンス管理は、SLAに対して比べるために恐らく測定されるべきLSPsの情報転送の特性を可能にします。 これは2つのカテゴリになります: 潜在(ジターが潜在の変化であると考えられるところ)と情報の損失。

   Latency can be measured in two ways: one is to have precisely
   synchronized clocks at the ingress and egress such that time-stamps
   in PDUs flowing from the ingress to the egress can be compared.  The
   other is to use an exchange of PING type PDUs that gives a round trip

2つの方法で潜在を測定できます: 1つは、時計を連動させにイングレスから出口まで流れるPDUsのタイムスタンプが比べることができるように、イングレスと出口に正確に行ったことがあります。 もう片方は周遊旅行を与えるPINGタイプPDUsの交換を使用することです。

Allan & Nadeau               Informational                      [Page 7]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[7ページ]のRFC4378

   time (RTT) measurement, and an estimate of the one-way latency that
   can be inferred with some loss of precision.  Use of load spreading
   techniques, such as ECMP, mean that any individual RTT measurement is
   only representative of the typical RTT for an FEC.

時間(RTT)測定、およびいくらかの精度の損失で推論できる片道潜在の見積り。 ECMPなどの負荷普及のテクニックの使用は、どんな個々のRTT測定も代表するだけであることをFECのための典型的なRTTを意味します。

   To measure information loss, a common practice is to periodically
   read ingress and egress counters (i.e., MIB module counters).  This
   information may also be used for offline correlation.  Another common
   practice is to send explicit probe traffic that traverses the data
   plane path in question.  This probe traffic can also be used to
   measure jitter and delay.

情報の損失を測定するために、定期的に読まれたイングレスと出口カウンタ(すなわち、MIBモジュールカウンタ)には一般的な習慣があります。 また、この情報はオフライン相関関係に使用されるかもしれません。 別の一般的な習慣は問題のデータ飛行機経路を横断する明白な徹底的調査交通を送ることになっています。 また、ジターと遅れを測定するのにこの徹底的調査交通を使用できます。

7.  Security Management

7. セキュリティ管理

   Providing a secure OAM environment is required if MPLS specific
   network mechanisms are to be used successfully.  To this end,
   operators have a number of options when deploying network mechanisms
   including simply filtering OAM messages at the edge of the MPLS
   network.  Malicious users should not be able to use non-MPLS
   interfaces to insert MPLS-specific OAM transactions.  Provider
   initiated OAM transactions should be able to be blocked from leaking
   outside the MPLS cloud.

安全なOAM環境を提供するのがMPLSの特定のネットワークメカニズムが首尾よく使用されることであるなら必要です。 このためにMPLSネットワークの縁で単にOAMメッセージをフィルターにかけるのを含むネットワークメカニズムを配備するとき、オペレータには、多くのオプションがあります。 悪意あるユーザーは、MPLS特有のOAM取引を挿入するのに非MPLSインタフェースを使用できないべきです。 プロバイダーの開始しているOAM取引は、MPLS雲の外で漏れるのを妨げることができるべきです。

   Finally, if a provider does wish to allow OAM messages to flow into
   (or through) their networks, for example, in a multi-provider
   deployment, authentication and authorization are required to prevent
   malicious and/or unauthorized access.  Also, given that MPLS networks
   often run IP simultaneously, similar requirements apply to any native
   IP OAM network mechanisms in use.  Therefore, authentication and
   authorization for OAM technologies is something that MUST be
   considered when designing network mechanisms that satisfy the
   framework presented in this document.

最終的に、プロバイダーが(or through)に流れるメッセージをOAMに許容したいなら、例えばマルチプロバイダー展開、認証、および認可におけるそれらのネットワークは悪意があるそして/または、権限のないアクセスを防がなければなりません。 また、MPLSネットワークが同時にしばしばIPを経営しているなら、同様の要件は使用中のどんな固有のIP OAMネットワークメカニズムにも適用されます。 したがって、OAM技術のための認証と認可は本書では提示された枠組みを満たすネットワークメカニズムを設計するとき考えなければならない何かです。

   OAM messaging can address some existing security concerns with the
   MPLS architecture.  That is, through rigorous defect handling,
   operator's can offer their customers a greater degree of integrity
   protection that their traffic will not be incorrectly delivered (for
   example, by being able to detect leaking LSP traffic from a VPN).

OAMメッセージングはMPLS構造で何らかの既存の安全上の配慮を記述できます。 すなわち、厳しい欠陥取り扱いで、オペレータのものは彼らの交通が不当に提供されないという(例えばVPNからの漏れているLSP交通を検出できることによって)保全保護の、より大きい度合いを彼らの顧客に提供できます。

   Support for inter-provider data plane OAM messaging introduces a
   number of security concerns as, by definition, portions of LSPs will
   not be within a single provider's network the provider has no control
   over who may inject traffic into the LSP, which can be exploited for
   denial of service attacks.  OAM PDUs are not explicitly identified in
   the MPLS header and therefore are not typically inspected by transit
   LSRs.  This creates opportunity for malicious or poorly behaved users
   to disrupt network operations.

サービス不能攻撃に利用できるLSPに交通を注ぐかもしれないプロバイダーが管理しないただ一つのプロバイダーのネットワークの中にLSPsの一部が定義上なくて、相互プロバイダーデータ飛行機OAMメッセージングのサポートは多くの安全上の配慮を導入します。 OAM PDUsはMPLSヘッダーで明らかに特定されないで、またしたがって、トランジットLSRsによって通常点検されません。 これは悪意があるか不十分に振る舞っているユーザがネットワーク操作を中断する機会を作成します。

Allan & Nadeau               Informational                      [Page 8]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[8ページ]のRFC4378

   Attempts to introduce filtering on target LSP OAM flows may be
   problematic if flows are not visible to intermediate LSRs.  However,
   it may be possible to interdict flows on the return path between
   providers (as faithfulness to the forwarding path is to a return path
   requirement) to mitigate aspects of this vulnerability.

流れが中間的LSRsに目に見えないなら、目標LSP OAMで流れをフィルターにかける導入する試みは問題が多いかもしれません。 しかしながら、この脆弱性の局面を緩和するのはプロバイダー(リターンパス要件には推進経路への忠実があるとき)の間のリターンパスで命令流れに可能であるかもしれません。

   OAM tools may permit unauthorized or malicious users to extract
   significant amounts of information about network configuration.  This
   would be especially true of IP based tools as, in many network
   configurations, MPLS does not typically extend to untrusted hosts,
   but IP does.  For example, TTL hiding at ingress and egress LSRs will
   prevent external users from using TTL-based mechanisms to probe an
   operator's network.  This suggests that tools used for problem
   diagnosis or which, by design, are capable of extracting significant
   amounts of information will require authentication and authorization
   of the originator.  This may impact the scalability of such tools
   when employed for monitoring instead of diagnosis.

OAMツールは、権限のないか悪意があるユーザがネットワーク・コンフィギュレーションのかなりの量の情報を抜粋するのを可能にするかもしれません。 これは多くのネットワーク・コンフィギュレーションでは、MPLSが信頼されていないホストに通常達しませんが、IPが本当であるようにIPのベースのツールに関して特に本当でしょう。 例えば、イングレスで隠れるTTLと出口LSRsは、社外利用者がオペレータのネットワークを調べるのにTTLベースのメカニズムを使用するのを防ぐでしょう。 これは、故意にかなりの量の情報を抜粋できる問題診断に使用されるツールが創始者の認証と認可を必要とするのを示します。 診断の代わりにモニターに使われると、これはそのようなツールのスケーラビリティに影響を与えるかもしれません。

8.  Security Considerations

8. セキュリティ問題

   This document describes a framework for MPLS Operations and
   Management.  Although this document discusses and addresses some
   security concerns in Section 7, it does not introduce any new
   security concerns.

このドキュメントはMPLS OperationsとManagementのために枠組みについて説明します。 このドキュメントは、セクション7における何らかの安全上の配慮について議論して、記述しますが、それはどんな新しい安全上の配慮も導入しません。

9.  Acknowledgements

9. 承認

   The editors would like to thank Monique Morrow from Cisco Systems and
   Harmen van Der Linde from AT&T for their valuable review comments on
   this document.

エディタはこのドキュメントの彼らの貴重なレビューコメントについてシスコシステムズとHarmenバンDerリンデからAT&Tからモニーク・モローに感謝したがっています。

10.  Normative References

10. 引用規格

   [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月。

   [RFC3031]  Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol
              Label Switching Architecture", RFC 3031, January 2001.

[RFC3031] ローゼンとE.とViswanathan、A.とR.Callon、「Multiprotocolラベル切り換え構造」、RFC3031、2001年1月。

   [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月。

   [Y1710]    ITU-T Recommendation Y.1710(2002), "Requirements for OAM
              Functionality for MPLS Networks".

[Y1710]ITU-T推薦Y.1710(2002)、「MPLSネットワークのためのOAMの機能性のための要件。」

Allan & Nadeau               Informational                      [Page 9]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[9ページ]のRFC4378

Authors' Addresses

作者のアドレス

   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

   Thomas D. Nadeau
   Cisco Systems
   300 Beaver Brook Drive
   Boxborough, MA 01824

トーマスD.ナドーシスコシステムズ300ビーバーブルックドライブBoxborough、MA 01824

   Phone: +1-978-936-1470
   EMail: tnadeau@cisco.com

以下に電話をしてください。 +1-978-936-1470 メールしてください: tnadeau@cisco.com

Allan & Nadeau               Informational                     [Page 10]

RFC 4378                A Framework for MPLS OAM           February 2006

MPLS OAM2006年2月のためのアランと1枠組みあたりナドーInformational[10ページ]のRFC4378

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)によって提供されます。

Allan & Nadeau               Informational                     [Page 11]

アランとナドーInformationalです。[11ページ]