RFC3564 日本語訳

3564 Requirements for Support of Differentiated Services-aware MPLSTraffic Engineering. F. Le Faucheur, W. Lai. July 2003. (Format: TXT=50808 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                     F. Le Faucheur
Request for Comments: 3564                           Cisco Systems, Inc.
Category: Informational                                           W. Lai
                                                                    AT&T
                                                               July 2003

Le Faucheurがコメントのために要求するワーキンググループF.をネットワークでつないでください: 3564年のシスコシステムズInc.カテゴリ: 情報のW.レイAT&T2003年7月

       Requirements for Support of Differentiated Services-aware
                     MPLS Traffic Engineering

微分されたサービス意識しているMPLS交通工学のサポートのための要件

Status of this Memo

この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 (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

Abstract

要約

   This document presents Service Provider requirements for support of
   Differentiated Services (Diff-Serv)-aware MPLS Traffic Engineering
   (DS-TE).

このドキュメントはDifferentiated Services(デフ-Serv)の意識しているMPLS Traffic Engineering(DS-TE)のサポートのための要件をService Providerに提示します。

   Its objective is to provide guidance for the definition, selection
   and specification of a technical solution addressing these
   requirements.  Specification for this solution itself is outside the
   scope of this document.

目的はこれらの要件を記述する技術的解決法の定義、選択、および仕様のための指導を提供することです。 このドキュメントの範囲の外にこの解決策自体のための仕様があります。

   A problem statement is first provided.  Then, the document describes
   example applications scenarios identified by Service Providers where
   existing MPLS Traffic Engineering mechanisms fall short and
   Diff-Serv-aware Traffic Engineering can address the needs.  The
   detailed requirements that need to be addressed by the technical
   solution are also reviewed.  Finally, the document identifies the
   evaluation criteria that should be considered for selection and
   definition of the technical solution.

最初に、問題声明を提供します。 そして、ドキュメントは既存のMPLS Traffic Engineeringメカニズムが不足して、Diff-Serv意識しているTraffic Engineeringが必要性を記述できるService Providersによって特定された例のアプリケーションシナリオについて説明します。 また、技術的解決法によって記述される必要がある詳細な要件は再検討されます。 最終的に、ドキュメントは技術的解決法の選択と定義のために考えられるべきである評価基準を特定します。

Le Faucheur & Lai            Informational                      [Page 1]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[1ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

Table of Contents

目次

   Specification Requirements .......................................  2
   1.  Introduction .................................................  3
       1.1.  Problem Statement ......................................  3
       1.2.  Definitions ............................................  3
       1.3.  Mapping of traffic to LSPs .............................  5
   2.  Application Scenarios ........................................  6
       2.1.  Scenario 1: Limiting Proportion of Classes on a Link ...  6
       2.2.  Scenario 2: Maintain relative proportion of traffic ....  6
       2.3.  Scenario 3: Guaranteed Bandwidth Services ..............  8
   3.  Detailed Requirements for DS-TE ..............................  9
       3.1.  DS-TE Compatibility ....................................  9
       3.2.  Class-Types ............................................  9
       3.3.  Bandwidth Constraints .................................. 11
       3.4.  Preemption and TE-Classes .............................. 12
       3.5.  Mapping of Traffic to LSPs ............................. 15
       3.6.  Dynamic Adjustment of Diff-Serv PHBs ................... 15
       3.7.  Overbooking ............................................ 16
       3.8.  Restoration ............................................ 16
   4.  Solution Evaluation Criteria ................................. 16
       4.1.  Satisfying detailed requirements ....................... 17
       4.2.  Flexibility ............................................ 17
       4.3.  Extendibility .......................................... 17
       4.4.  Scalability ............................................ 17
       4.5.  Backward compatibility/Migration ....................... 17
       4.6.  Bandwidth Constraints Model ............................ 18
   5.  Security Considerations ...................................... 18
   6.  Acknowledgment ............................................... 18
   7.  Normative References ......................................... 18
   8.  Informative References ....................................... 19
   9.  Contributing Authors ......................................... 20
   10. Editors' Addresses ........................................... 21
   11. Full Copyright Statement ..................................... 22

仕様要件… 2 1. 序論… 3 1.1. 問題声明… 3 1.2. 定義… 3 1.3. LSPsへの交通に関するマッピング… 5 2. アプリケーションシナリオ… 6 2.1. シナリオ1: リンクの上にクラスの割合を制限します… 6 2.2. シナリオ2: 交通の相対的比率を維持してください… 6 2.3. シナリオ3: 帯域幅サービスを保証します… 8 3. DS-Teのための要件を詳しく述べます… 9 3.1. DS-Teの互換性… 9 3.2. クラスタイプ… 9 3.3. 帯域幅規制… 11 3.4. 先取りとTeクラス… 12 3.5. LSPsへの交通に関するマッピング… 15 3.6. デフ-Serv PHBsの動態的調整… 15 3.7. オーバーブックします… 16 3.8. 王政復古… 16 4. ソリューション評価基準… 16 4.1. 詳細な要件を満たします… 17 4.2. 柔軟性… 17 4.3. 拡張性… 17 4.4. スケーラビリティ… 17 4.5. 後方の互換性/移動… 17 4.6. 帯域幅規制はモデル化されます… 18 5. セキュリティ問題… 18 6. 承認… 18 7. 標準の参照… 18 8. 有益な参照… 19 9. 作者を寄付します… 20 10. エディタのアドレス… 21 11. 完全な著作権宣言文… 22

Specification Requirements

仕様書要求事項

   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]で説明されるように本書では解釈されることであるべきですか?

Le Faucheur & Lai            Informational                      [Page 2]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[2ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

1.  Introduction

1. 序論

1.1.  Problem Statement

1.1. 問題声明

   Diff-Serv is used by some Service Providers to achieve scalable
   network designs supporting multiple classes of services.

デフ-Servは、複数のクラスのサービスを支持するスケーラブルなネットワークデザインを達成するのにいくつかのService Providersによって使用されます。

   In some such Diff-Serv networks, where optimization of transmission
   resources on a network-wide basis is not sought, MPLS Traffic
   Engineering (TE) mechanisms may not be used.

そのようないくつかのDiff-Servネットワークでは、MPLS Traffic Engineering(TE)メカニズムは使用されないかもしれません。そこでは、ネットワーク全体のベースにおけるトランスミッションリソースの最適化が求められません。

   In other networks, where optimization of transmission resources is
   sought, Diff-Serv mechanisms [DIFF-MPLS] may be complemented by
   MPLS Traffic Engineering mechanisms [TE-REQ] [ISIS-TE] [OSPF-TE]
   [RSVP-TE] which operate on an aggregate basis across all
   Diff-Serv classes of service.  In this case, Diff-Serv and MPLS TE
   both provide their respective benefits.

他のネットワークでは、すべてのDiff-Servのクラスのサービスの向こう側に集合ベースを作動させるMPLS Traffic Engineeringメカニズム[TE-REQ][イシス-TE][OSPF-TE][RSVP-TE]でDiff-Servメカニズム[DIFF-MPLS]は補足となるかもしれません。そこでは、トランスミッションリソースの最適化が求められます。 この場合、Diff-ServとMPLS TEはともにそれらのそれぞれの利益を提供します。

   To achieve fine-grained optimization of transmission resources and
   further enhanced network performance and efficiency, as discussed in
   [TEWG-FW], it may be desirable to perform traffic engineering at a
   per-class level instead of at an aggregate level.  By mapping the
   traffic from a given Diff-Serv class of service on a separate LSP, it
   allows this traffic to utilize resources available to the given class
   on both shortest paths and non-shortest paths, and follow paths that
   meet engineering constraints which are specific to the given class.
   This is what we refer to as "Diff-Serv-aware Traffic Engineering
   (DS-TE)".

[TEWG-FW]で議論するようにトランスミッションリソース、さらなる高められたネットワーク性能、および効率のきめ細かに粒状の最適化を達成するために、集合レベルの代わりに1クラスあたり1つのレベルで交通工学を実行するのは望ましいかもしれません。 別々のLSPにおける与えられたDiff-Servのクラスのサービスからの交通を写像することによって、この交通は、それで、最短パスと非最短パスの両方の与えられたクラスに利用可能なリソースを利用して、与えられたクラスに特定の工学規制を満たす経路に続いて起こります。 これが私たちが言及することである、「デフServ意識する、交通工学(DS-Te)、」

   This document focuses exclusively on the specific environments which
   would benefit from DS-TE.  Some examples include:

このドキュメントは排他的にDS-TEの利益を得る特定の環境に焦点を合わせます。 いくつかの例は:

     -    networks where bandwidth is scarce (e.g., transcontinental
          networks)
     -    networks with significant amounts of delay-sensitive traffic
     -    networks where the relative proportion of traffic across
          classes of service is not uniform

- 帯域幅が不十分であるネットワーク(例えば、大陸横断のネットワーク)--かなりの量の遅れ敏感な交通を伴うネットワーク--サービスのクラスの向こう側の交通の相対的比率が一定でないネットワーク

   This document focuses on intra-domain operation.  Inter-domain
   operation is not considered.

このドキュメントはイントラドメイン操作に焦点を合わせます。 相互ドメイン操作は考えられません。

1.2.  Definitions

1.2. 定義

   For the convenience of the reader, relevant Diff-Serv ([DIFF-ARCH],
   [DIFF-NEW] and [DIFF-PDB]) definitions are repeated herein.

読者の都合のために、関連Diff-Serv([DIFF-ARCH]、[DIFF-NEW]、および[DIFF-PDB])定義はここに繰り返されます。

      Behavior Aggregate (BA): a collection of packets with the same
      (Diff-Serv) codepoint crossing a link in a particular direction.

振舞い集合(Ba): 同じ(デフ-Serv)codepointが特定の方向にリンクを越えているパケットの収集。

Le Faucheur & Lai            Informational                      [Page 3]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[3ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

      Per-Hop-Behavior (PHB): the externally observable forwarding
      behavior applied at a DS-compliant node to a Diff-Serv behavior
      aggregate.

ホップの振舞い、(PHB): 外部的に観察可能な推進の振舞いはDS対応することのノードでDiff-Serv振舞い集合に適用されました。

      PHB Scheduling Class (PSC): A PHB group for which a common
      constraint is that ordering of at least those packets belonging to
      the same microflow must be preserved.

PHBスケジューリングのクラス(PSC): 一般的な規制が少なくとも同じmicroflowに属すそれらのパケットのその注文であるPHBグループを保存しなければなりません。

      Ordered Aggregate (OA): a set of BAs that share an ordering
      constraint.  The set of PHBs that are applied to this set of
      Behavior Aggregates constitutes a PHB scheduling class.

集合(OA)は命令しました: 注文規制を共有するBAsの1セット。 Behavior Aggregatesのこのセットに適用されるPHBsのセットはPHBスケジューリングのクラスを構成します。

      Traffic Aggregate (TA): a collection of packets with a codepoint
      that maps to the same PHB, usually in a DS domain or some subset
      of a DS domain.  A traffic aggregate marked for the foo PHB is
      referred to as the "foo traffic aggregate" or "foo aggregate"
      interchangeably.  This generalizes the concept of Behavior
      Aggregate from a link to a network.

交通集合(バイバイ): 通常DSドメインのPHBかDSドメインの何らかの部分集合を同じくらいに写像するcodepointとのパケットの収集。 foo PHBのためにマークされた交通集合は「foo交通集合」か「foo集合」と互換性を持って呼ばれます。 これはネットワークへのリンクからBehavior Aggregateの概念を広めます。

      Per-Domain Behavior (PDB): the expected treatment that an
      identifiable or target group of packets will receive from
      "edge-to-edge" of a DS domain.  A particular PHB (or, if
      applicable, list of PHBs) and traffic conditioning requirements
      are associated with each PDB.

1ドメインあたりの振舞い(PDB): パケットの身元保証可能であるか目標グループが「斜めに進ませる縁」から受けるDSドメインの予想された処理。 特定のPHB(適切でありPHBsのリスト)と交通調節要件は各PDBに関連しています。

   We also repeat the following definition from [TE-REQ]:

また、私たちは[TE-REQ]から以下の定義を繰り返します:

      Traffic Trunk: an aggregation of traffic flows of the same class
      which are placed inside a Label Switched Path.

交通トランク: Label Switched Pathの中に置かれる同じクラスの交通の流れの集合。

   In the context of the present document, "flows of the same class" is
   to be interpreted as "flows from the same Forwarding Equivalence
   Class which are to be treated equivalently from the DS-TE
   perspective".

現在のドキュメントの文脈では、「同じクラスの流れ」は「DS-TE見解から同等に扱われることになっている同じForwarding Equivalence Classからの流れ」として解釈されることです。

      We refer to the set of TAs corresponding to the set of PHBs of a
      given PSC, as a {TA}PSC.  A given {TA}PSC will receive the
      treatment of the PDB associated with the corresponding PSC.  In
      this document, we also loosely refer to a {TA}PSC as a "Diff-Serv
      class of service", or a "class of service".  As an example, the
      set of packets within a DS domain with a codepoint that maps to
      the EF PHB may form one {TA}PSC in that domain.  As another
      example, the set of packets within a DS domain with a codepoint
      that maps to the AF11 or AF12 or AF13 PHB may form another {TA}PSC
      in that domain.

私たちはTAとして与えられたPSCのPHBsのセットに対応するTAsのセットについて言及します。PSC。 PSCが望んでいるA当然のことのTAは対応するPSCに関連しているPDBの処理を受けます。 また、本書では、私たちは緩くTAへの「サービスのデフ-Servのクラス」としてのPSC、または「サービスのクラス」を参照します。 例として、それがEF PHBに写像するcodepointがあるDSドメインの中のパケットのセットはそのドメインで1TAのPSCを形成するかもしれません。 別の例として、それがAF11、AF12またはAF13 PHBに写像するcodepointがあるDSドメインの中のパケットのセットは別のTAを形成するかもしれません。そのドメインのPSC。

Le Faucheur & Lai            Informational                      [Page 4]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[4ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   We refer to the collection of packets which belong to a given Traffic
   Aggregate and are associated with a given MPLS Forwarding Equivalence
   Class (FEC) ([MPLS-ARCH]) as a <FEC/TA>.

私たちは与えられたTraffic Aggregateに属している、与えられたMPLS Forwarding Equivalence Class(FEC)に関連しているパケット([MPLS-ARCH])の収集を<FEC/TA>と呼びます。

   We refer to the set of <FEC/TA> whose TAs belong to a given {TA}PSC
   as a <FEC/{TA}PSC>.

私たちはTAsが与えられたTAに属す<FEC/TA>のセットについて言及します。<FEC/TA PSC>としてのPSC。

1.3.  Mapping of traffic to LSPs

1.3. LSPsへの交通に関するマッピング

   A network may have multiple Traffic Aggregates (TAs) it wishes to
   service.  Recalling from [DIFF-MPLS], there are several options on
   how the set of <FEC/{TA}PSC> of a given FEC can be split into Traffic
   Trunks for mapping onto LSPs when running MPLS Traffic Engineering.

ネットワークはそれが調整したがっている複数のTraffic Aggregates(TAs)を持っているかもしれません。 MPLS Traffic Engineeringを走らせるとき、[DIFF-MPLS]から思い出して、LSPsにはマッピングのためにどう与えられたFECの<FEC/TA PSC>のセットをTraffic Trunksに分割されることができるかに関するいくつかのオプションがあります。

   One option is to not split this set of <FEC/{TA}PSC> so that each
   Traffic Trunk comprises traffic from all the {TA}/PSC.  This option
   is typically used when aggregate traffic engineering is deployed
   using current MPLS TE mechanisms.  In that case, all the
   <FEC/{TA}PSC> of a given FEC are routed collectively according to a
   single shared set of constraints and will follow the same path.  Note
   that the LSP transporting such a Traffic Trunk is, by definition, an
   E-LSP as defined in [DIFF-MPLS].

1つのオプションが<FEC/TA PSC>のこのセットを分割しないことであるので、各Traffic TrunkはすべてのTA/PSCからの交通を包括します。 集合交通工学が現在のMPLS TEメカニズムを使用することで配備されるとき、このオプションは通常使用されます。与えられたFECの<FEC/TA PSC>はすべて、その場合、共有された1セットの規制に応じてまとめて発送されて、同じ経路に続くでしょう。 そのようなTraffic Trunkを輸送するLSPが定義上[DIFF-MPLS]で定義されるようにE-LSPであることに注意してください。

   Another option is to split the different <FEC/{TA}PSC> of a given FEC
   into multiple Traffic Trunks on the basis of the {TA}PSC.  In other
   words, traffic, from one given node to another, is split, based on
   the "classes of service", into multiple Traffic Trunks which are
   transported over separate LSP and can potentially follow different
   paths through the network.  DS-TE takes advantage of this and
   computes a separate path for each LSP.  In so doing, DS-TE can take
   into account the specific requirements of the Traffic Trunk
   transported on each LSP (e.g., bandwidth requirement, preemption
   priority).  Moreover DS-TE can take into account the specific
   engineering constraints to be enforced for these sets of Traffic
   Trunks (e.g., limit all Traffic Trunks transporting a particular
   {TA}PSC to x% of link capacity).  DS-TE achieves per LSP constraint
   based routing with paths that match specific objectives of the
   traffic while forming the corresponding Traffic Trunk.

別のオプションは、TAに基づいて与えられたFECの異なった<FEC/TA PSC>を複数のTraffic Trunksに分割するためにいます。PSC。 言い換えれば、交通は、1つの与えられたノードから別のノードまで分けられて、どれが別々のLSPの上で輸送されるかを複数のTraffic Trunksへの「サービスのクラス」に基礎づけて、ネットワークを通して潜在的に異なった経路に続いて起こることができます。 DS-TEはこれを利用して、各LSPのために別々の経路を計算します。 そうする際に、DS-TEは各LSP(例えば、帯域幅要件、先取り優先権)で輸送されたTraffic Trunkに関する決められた一定の要求を考慮に入れることができます。 そのうえ、DS-TEがTraffic Trunksのこれらのセットのために実施されるという特定の工学規制を考慮に入れることができる、(例えば、特定のTAを輸送するすべてのTraffic Trunksを制限してください、x%のリンク容量へのPSC) DS-TEは対応するTraffic Trunkを形成している間に交通の明確な目標に合っている経路でLSP規制単位でベースのルーティングを達成します。

   For simplicity, and because this is the specific topic of this
   document, the above paragraphs in this section only considered
   splitting traffic of a given FEC into multiple Traffic Aggregates on
   the basis of {TA}PSC.  However, it should be noted that, in addition
   to this, traffic from every {TA}PSC may also be split into multiple
   Traffic Trunks for load balancing purposes.

このセクションの上のパラグラフは、簡単さ、これがこのドキュメントの特定の話題であるのでTAに基づいて与えられたFECの交通を複数のTraffic Aggregatesに分けると考えるだけでした。PSC。 しかしながら、それがこれに加えてあらゆるTAから取引することに注意されるべきです。PSCは分かれるかもしれません、また、ロードバランシング目的のために複数のTraffic Trunksに分けられてください。

Le Faucheur & Lai            Informational                      [Page 5]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[5ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

2.  Application Scenarios

2. アプリケーションシナリオ

2.1.  Scenario 1: Limiting Proportion of Classes on a Link

2.1. シナリオ1: リンクの上にクラスの割合を制限します。

   An IP/MPLS network may need to carry a significant amount of VoIP
   traffic compared to its link capacity.  For example, 10,000
   uncompressed calls at 20ms packetization result in about 1Gbps of IP
   traffic, which is significant on an OC-48c based network.  In case of
   topology changes such as link/node failure, VoIP traffic levels can
   even approach the full bandwidth on certain links.

IP/MPLSネットワークは、リンク容量と比べて、かなりの量のVoIP交通を運ぶ必要があるかもしれません。 例えば、20ms packetizationでの解凍された呼び出しがOC-48cで重要なIP交通の1Gbpsに関してもたらす1万はネットワークを基礎づけました。 リンク/ノード障害などのトポロジー変化の場合には、VoIP交通レベルはあるリンクにおける完全な帯域幅にアプローチさえできます。

   For delay/jitter reasons, some network administrators see it as
   undesirable to carry more than a certain percentage of VoIP traffic
   on any link.  The rest of the available link bandwidth can be used to
   route other "classes of service" corresponding to delay/jitter
   insensitive traffic (e.g.,  Best Effort Internet traffic).  The exact
   determination of this "certain" percentage is outside the scope of
   this requirements document.

遅れ/ジター理由で、何人かのネットワーク管理者が、それがどんなリンクにおける1以上のある割合のVoIP交通を運ぶのにおいて望ましくないとみなします。 延着するように対応する他の「サービスのクラス」/ジターの神経の鈍い交通(例えば、Best Effortインターネットトラフィック)を発送するのに利用可能なリンク帯域幅の残りを使用できます。 この要件ドキュメントの範囲の外にこの「ある」割合の正確な決断があります。

   During normal operations, the VoIP traffic should be able to preempt
   other "classes of service" (if these other classes are designated as
   preemptable and they have lower preemption priority), so that it will
   be able to use the shortest available path, only constrained by the
   maximum defined link utilization ratio/percentage of the VoIP class.

通常操作の間、VoIP交通は他の「サービスのクラス」を先取りできるべきです(これらの他のクラスが先取り可能として指定されて、それらに下側の先取り優先度があるなら)、VoIPのクラスの最大の定義されたリンク利用率/百分率によって抑制されるだけである中で最も短い利用可能な経路を使用できるように。

   Existing TE mechanisms only allow constraint based routing of traffic
   based on a single bandwidth constraint common to all "classes of
   service", which does not satisfy the needs described here.  This
   leads to the requirement for DS-TE to be able to enforce a different
   bandwidth constraint for different "classes of service".  In the
   above example, the bandwidth constraint to be enforced for VoIP
   traffic may be the "certain" percentage of each link capacity, while
   the bandwidth constraint to be enforced for the rest of the "classes
   of service" might have their own constraints or have access to the
   rest of the link capacity.

既存のTEメカニズムはここで説明された需要を満たさないすべての「サービスのクラス」に共通のただ一つの帯域幅規制に基づく交通のベースのルーティングを規制に許すだけです。 これはDS-TEが異なった「サービスのクラス」の異なった帯域幅規制を実施できるという要件に通じます。 上記の例では、VoIP交通に実施されるという帯域幅規制はそれぞれのリンク容量の「ある」割合であるかもしれません、「サービスのクラス」の残りのために実施されるという帯域幅規制は、それら自身の規制を持っているか、またはリンク容量の残りに近づく手段を持っているかもしれませんが。

2.2.  Scenario 2: Maintain relative proportion of traffic

2.2. シナリオ2: 交通の相対的比率を維持してください。

   Suppose an IP/MPLS network supports 3 "classes of service".  The
   network administrator wants to perform Traffic Engineering to
   distribute the traffic load.  Also assume that proportion across
   "classes of service" varies significantly depending on the
   source/destination POPs.

IP/MPLSがサポートをネットワークでつなぐなら、3は「サービスを属します」。 ネットワーク管理者は、トラヒック負荷を分配するためにTraffic Engineeringを実行したがっています。 また、ソース/目的地POPにかなりよって、「サービスのクラス」の向こう側のその割合が変えると仮定してください。

Le Faucheur & Lai            Informational                      [Page 6]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[6ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   With existing TE mechanisms, the proportion of traffic from each
   "class of service" on a given link will vary depending on multiple
   factors including:

既存のTEメカニズムで、重複因子によって、異なることと、:与えられたリンクの各「サービスのクラス」からの交通の割合は異なるでしょう。

   - in which order the different TE-LSPs are established
   - the preemption priority associated with the different TE-LSPs
   - link/node failure situations

- どのオーダーで、異なったTE-LSPsは確立した(異なったTE-LSPsに関連している先取り優先権)リンク/ノード障害状況ですか。

   This may make it difficult or impossible for the network
   administrator to configure the Diff-Serv PHBs (e.g., queue bandwidth)
   to ensure that each "class of service" gets the appropriate
   treatment.  This leads again to the requirement for DS-TE to be able
   to enforce a different bandwidth constraint for different "classes of
   service".  This could be used to ensure that, regardless of the order
   in which tunnels are routed, regardless of their preemption priority
   and regardless of the failure situation, the amount of traffic of
   each "class of service" routed over a link matches the Diff-Serv
   scheduler configuration on that link to the corresponding class
   (e.g., queue bandwidth).

これで、ネットワーク管理者が各「サービスのクラス」が適切な処理を得るのを保証するために、Diff-Serv PHBs(例えば、待ち行列帯域幅)を構成するのが難しいか不可能になるかもしれません。 これは再びDS-TEが異なった「サービスのクラス」の異なった帯域幅規制を実施できるという要件に通じます。 リンクの上に発送されたそれぞれの「サービスのクラス」の交通の量がトンネルがそれらの先取り優先権にかかわらず失敗状況にかかわらず発送される注文にかかわらず対応するクラスへのそのリンクでのDiff-Servスケジューラ構成に合っているのを保証するのにこれを使用できました(例えば、帯域幅を列に並ばせてください)。

   As an illustration of how DS-TE would address this scenario, the
   network administrator may configure the service rate of Diff-Serv
   queues to (45%,35%,20%) for "classes of service" (1,2,3)
   respectively.  The administrator would then split the traffic into
   separate Traffic Trunks for each "class of service" and associate a
   bandwidth to each LSP transporting those Traffic Trunks.  The network
   administrator may also want to configure preemption priorities of
   each LSP in order to give highest restoration priority to the highest
   priority "class of service" and medium priority to the medium "class
   of service".  Then DS-TE could ensure that after a failure, "class of
   service" 1 traffic would be rerouted with first access at link
   capacity without exceeding its service rate of 45% of the link
   bandwidth.  "Class of service" 2 traffic would be rerouted with
   second access at the link capacity without exceeding its allotment.
   Note that where "class of service" 3 is the Best-Effort service, the
   requirement on DS-TE may be to ensure that the total amount of
   traffic routed across all "classes of service" does not exceed the
   total link capacity of 100% (as opposed to separately limiting the
   amount of Best Effort traffic to 20 even if there was little "class
   of service" 1 and "class of service" 2 traffic).

DS-TEがどうこのシナリオを記述するだろうかに関するイラストとして、ネットワーク管理者は「サービスのクラス」(1、2、3)のためにそれぞれDiff-Serv待ち行列対(45%、35%、20%)のサービス率を構成するかもしれません。 管理者は、それらのTraffic Trunksを輸送しながら、次に、各「サービスのクラス」のために交通を別々のTraffic Trunksに分けて、各LSPに帯域幅を関連づけるでしょう。 また、ネットワーク管理者は、最優先の最も高い回復優先度に「サービスのクラス」を最優先させて、中型の「サービスのクラス」を媒体に最優先させるためにそれぞれのLSPの先取りプライオリティを構成したがっているかもしれません。 そして、DS-TEは、失敗の後に「サービスのクラス」1回の交通がリンク容量で最初に、アクセスでリンク帯域幅の45%のサービス率を超えていなくて別ルートで送られるのを確実にすることができました。 割当てを超えていなくて、「サービスのクラス」2交通は2番目のリンク容量でのアクセスで別ルートで送られるでしょう。 DS-TEに関する要件が「サービスのクラス」3がBest-努力サービスであるところですべての「サービスのクラス」の向こう側に発送された交通の総量が100%(小さい「サービスのクラス」1と「サービスのクラス」2交通があったとしても別々にBest Effort交通の量を20に制限することと対照的に)の総リンク容量を超えていないのを保証することであるかもしれないことに注意してください。

   In this scenario, DS-TE would allow for the maintenance of a more
   steady distribution of "classes of service", even during rerouting.
   This would rely on the required capability of DS-TE to adjust the
   amount of traffic of each "class of service"  routed on a link based
   on the configuration of the scheduler and the amount of bandwidth
   available for each "class of service".

このシナリオでは、DS-TEは「サービスのクラス」の、より安定した分配の維持を考慮するでしょう、コースを変更する間さえ。 これはDS-TEがスケジューラの構成に基づくリンクの上に発送されたそれぞれの「サービスのクラス」の交通の量と各「サービスのクラス」に利用可能な帯域幅の量を調整する必要な能力を当てにするでしょう。

Le Faucheur & Lai            Informational                      [Page 7]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[7ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   Alternatively, some network administrators may want to solve the
   problem by having the scheduler dynamically adjusted based on the
   amount of bandwidth of the LSPs admitted for each "class of service".
   This is an optional additional requirement on the DS-TE solution.

あるいはまた、何人かのネットワーク管理者が、各「サービスのクラス」のために認められたLSPsの帯域幅の量に基づいてスケジューラをダイナミックに調整させることによって、問題を解決したがっているかもしれません。 これはDS-TE解決策に関する任意の追加要件です。

2.3.  Scenario 3: Guaranteed Bandwidth Services

2.3. シナリオ3: 保証された帯域幅サービス

   In addition to the Best effort service, an IP/MPLS network operator
   may desire to offer a point-to-point "guaranteed bandwidth" service
   whereby the provider pledges to provide a given level of performance
   (bandwidth/delay/loss...) end-to-end through its network from an
   ingress port to an egress port.  The goal is to ensure that all the
   "guaranteed" traffic under the scope of a subscribed service level
   specification, will be delivered within the tolerances of this
   service level specification.

Best努力サービスに加えて、IP/MPLSネットワーク・オペレータは、プロバイダーがネットワークを通してイングレスポートから出口港まで与えられた技量(帯域幅/遅れ/損失…)の終わりから終わりを提供すると誓約する二地点間「保証された帯域幅」サービスを提供することを望むかもしれません。 目標が申し込まれたサービスの範囲の下のすべての「保証された」交通が仕様を平らにするのを保証することであり、このサービスレベル仕様の寛容の中を果たされるでしょう。

   One approach for deploying such "guaranteed" service involves:

そのような「保証された」サービスを配備するための1つのアプローチが以下にかかわります。

   - dedicating a Diff-Serv PHB (or a Diff-Serv PSC as defined in
     [DIFF-NEW]) to the "guaranteed" traffic
   - policing guaranteed traffic on ingress against the traffic contract
     and marking the "guaranteed" packets with the corresponding
     DSCP/EXP value

- 保証された交通を取り締まって、交通契約と「保証された」パケットに対応するDSCP/EXP値を付けることに対するイングレスでDiff-Serv PHB(または、[DIFF-NEW]で定義されるDiff-Serv PSC)を「保証された」交通に捧げます。

   Where a very high level of performance is targeted for the
   "guaranteed" service, it may be necessary to ensure that the amount
   of "guaranteed" traffic remains below a given percentage of link
   capacity on every link.  Where the proportion of "guaranteed" traffic
   is high, constraint based routing can be used to enforce such a
   constraint.

非常に高いレベルの性能が「保証された」サービスのために狙うところでは、「保証された」交通の量があらゆるリンクの与えられた割合のリンク容量より下で残っているのを保証するのが必要であるかもしれません。 「保証された」交通の割合が高いところでは、そのような規制を実施するのに規制に基づいているルーティングを使用できます。

   However, the network operator may also want to simultaneously perform
   Traffic Engineering for the rest of the traffic (i.e.,
   non-guaranteed traffic) which would require that constraint based
   routing is also capable of enforcing a different bandwidth
   constraint, which would be less stringent than the one for guaranteed
   traffic.

しかしながら、また、ネットワーク・オペレータは同時に、また、ベースのルーティングが保証された交通には、ものほど厳しくないだろうという異なった帯域幅規制を実施できるというその規制を必要とする交通(すなわち、非保証された交通)の残りのためにTraffic Engineeringを実行したがっているかもしれません。

   Again, this combination of requirements can not be addressed with
   existing TE mechanisms.  DS-TE mechanisms allowing enforcement of a
   different bandwidth constraint for guaranteed traffic and for
   non-guaranteed traffic are required.

一方、既存のTEメカニズムで要件のこの組み合わせを記述できません。保証された交通と非保証された交通の異なった帯域幅規制の実施を許すDS-TEメカニズムが必要です。

Le Faucheur & Lai            Informational                      [Page 8]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[8ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

3.  Detailed Requirements for DS-TE

3. DS-Teのための詳細な要件

   This section specifies the functionality that the above scenarios
   require out of the DS-TE solution.  Actual technical protocol
   mechanisms and procedures to achieve such functionality are outside
   the scope of this document.

このセクションは上のシナリオがDS-TE解決策から必要とする機能性を指定します。 このドキュメントの範囲の外に実際の技術的なプロトコルメカニズムとそのような機能性を達成する手順があります。

3.1.  DS-TE Compatibility

3.1. DS-Teの互換性

   Since DS-TE may impact scalability (as discussed later in this
   document) and operational practices, DS-TE is expected to be used
   when existing TE mechanisms combined with Diff-Serv cannot address
   the network design requirements (i.e., where constraint based routing
   is required and where it needs to enforce different bandwidth
   constraints for different "classes of service", such as in the
   scenarios described above in section 2).  Where the benefits of DSTE
   are only required in a topological subset of their network, some
   network operators may wish to only deploy DS-TE in this topological
   subset.

DS-TEがスケーラビリティ(後で本書では議論するように)と操作上の習慣に影響を与えるかもしれないので、Diff-Servに結合された既存のTEメカニズムがネットワーク設計の品質を記述できないなら(すなわち、規制に基づいているルーティングがどこで必要であるか、そして、それは、どこで上でセクション2で説明されたシナリオなどの異なった「サービスのクラス」の異なった帯域幅規制を実施する必要がありますか)、DS-TEが使用されると予想されます。 DSTEの利益がそれらのネットワークの位相的な部分集合で必要であるだけであるところでは、何人かのネットワーク・オペレータがこの位相的な部分集合でDS-TEを配備するだけでありたいかもしれません。

   Thus, the DS-TE solution MUST be developed in such a way that:

したがって、以下のことのような方法でDS-TE解決策を見いださなければなりません。

   (i)    it raises no interoperability issues with existing deployed TE
          mechanisms.
   (ii)   it allows DS-TE deployment to the required level of
          granularity and scope (e.g., only in a subset of the topology,
          or only for the number of classes required in the considered
          network)

(i) それは既存の配備されたTEメカニズムの相互運用性問題を全く提起しません。(ii)それは必要なレベルの粒状と範囲への展開をDS-TEに許します。(例えば、トポロジーの部分集合だけ、または考えられたネットワークで必要であるクラスの数のためだけの)

3.2.  Class-Types

3.2. クラスタイプ

   The fundamental requirement for DS-TE is to be able to enforce
   different bandwidth constraints for different sets of Traffic Trunks.

DS-TEに、基本的な要件はTraffic Trunksの異なったセットの異なった帯域幅規制を実施することであることができます。

   [TEWG-FW] introduces the concept of Class-Types when discussing
   operations of MPLS Traffic Engineering in a Diff-Serv environment.

Diff-Serv環境における、MPLS Traffic Engineeringの操作について議論するとき、[TEWG-FW]はClass-タイプの概念を紹介します。

   We refine this definition into the following:

私たちはこの定義を以下に洗練します:

            Class-Type (CT): the set of Traffic Trunks crossing a link,
            that is governed by a specific set of Bandwidth constraints.
            CT is used for the purposes of link bandwidth allocation,
            constraint based routing and admission control.  A given
            Traffic Trunk belongs to the same CT on all links.

クラスタイプ(コネチカット): Traffic Trunksのセットがリンクを越えて、それは特定のBandwidth規制で治められます。 コネチカットはリンク帯域幅配分の目的に使用されて、規制はルーティングと入場コントロールを基礎づけました。 与えられたTraffic Trunkはすべてのリンクの上の同じコネチカットに属します。

   Note that different LSPs transporting Traffic Trunks from the same CT
   may be using the same or different preemption priorities as explained
   in more details in section 3.4 below.

Traffic Trunksを輸送する同じコネチカットと異なったLSPsがその他の詳細で下のセクション3.4で説明されるように同じであるか異なった先取りプライオリティを使用しているかもしれないことに注意してください。

Le Faucheur & Lai            Informational                      [Page 9]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[9ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   Mapping of {TA}PSC to Class-Types is flexible.  Different {TA}PSC can
   be mapped to different CTs, multiple {TA}PSC can be mapped to the
   same CT and one {TA}PSC can be mapped to multiple CTs.

写像して、TAでは、Class-タイプへのPSCはフレキシブルです。 異なったCTs、複数のTAにPSCを写像できます。異なったTA、同じコネチカットにPSCを写像できて、1TAのPSCを複数のCTsに写像できます。

   For illustration purposes, let's consider the case of a network
   running 4 Diff-Serv PDBs which are respectively based on the EF PHB
   [EF], the AF1x PSC [AF], the AF2x PSC and the Default (i.e.,
   Best-Effort) PHB [DIFF-FIELD].  The network administrator may decide
   to deploy DS-TE in the following way:

イラスト目的のために、ネットワーク走行に関するケースがそれぞれEF PHBに基づいている、4Diff-Serv PDBs[EF]と、AF1x PSC[AF]と、AF2x PSCとDefault(すなわち、Best-努力)PHB[DIFF-FIELD]であると考えましょう。 ネットワーク管理者は、以下の方法でDS-TEを配備すると決めるかもしれません:

         o  from every DS-TE Head-end to every DS-TE Tail-end, split the
            traffic into 4 Traffic Trunks: one for traffic of each
            {TA}PSC
         o  because the QoS objectives for the AF1x PDB and for the AF2x
            PDB may be of similar nature (e.g., both targeting low loss
            albeit at different levels perhaps), the same (set of)
            Bandwidth Constraint(s) may be applied collectively over the
            AF1x Traffic Trunks and the AF2x Traffic Trunks.  Thus, the
            network administrator may only define three CTs: one for the
            EF Traffic Trunks, one for the AF1x and AF2x Traffic Trunks
            and one for the Best Effort Traffic Trunks.

o いつもDS-TE Head-終わりからいつもDS-TE Tail-終わりまで、交通を4Traffic Trunksに分けてください: それぞれのTAの交通への1、PSC、○ AF1x PDBとAF2x PDBのためのQoS目的が同様に自然であるかもしれないので(例えば、ともに、それにしても、恐らく異なったレベルで低い損失を狙います)、同じ(セットされます)帯域幅Constraint(s)はAF1x Traffic TrunksとAF2x Traffic Trunksの上にまとめて適用されるかもしれません。 したがって、ネットワーク管理者は3CTsしか定義しないかもしれません: EF Traffic Trunksのためのもの、AF1xとAF2x Traffic Trunksのためのもの、およびBest Effort Traffic Trunksのためのもの。

   As another example of mapping of {TA}PSC to CTs, a network operator
   may split the traffic from the {TA}PSC associated with EF into two
   different sets of traffic trunks, so that each set of traffic trunks
   is subject to different constraints on the bandwidth it can access.
   In this case, two distinct CTs are defined for the EF {TA}PSC
   traffic:  one for the traffic subset subject to the first (set of)
   bandwidth constraint(s), the other for the traffic subset subject to
   the second (set of) bandwidth constraint(s).

TAに関するマッピングに関する別の例として、CTsへのPSC、ネットワーク・オペレータが交通を分けるかもしれないのでそれぞれのセットの交通トランクスはPSCが異なった2セットの交通トランクスへのEFに関連づけたTAそれがそうすることができる帯域幅で異なった規制を受けることがある、アクセサリー この場合、2異なったCTsがPSCが取引するEF TAのために定義されます: 最初(セットされる)の帯域幅規制(2(セットされる)番目の帯域幅規制を条件とした交通部分集合のためのもう片方)を条件とした交通部分集合のためのもの。

   The DS-TE solution MUST support up to 8 CTs.  Those are referred to
   as CTc, 0 <= c <= MaxCT-1 = 7.
   The DS-TE solution MUST be able to enforce a different set of
   Bandwidth Constraints for each CT.
   A DS-TE implementation MUST support at least 2 CTs, and MAY support
   up to 8 CTs.

DS-TE解決策は最大8CTsを支持しなければなりません。 ものはCTcと呼ばれて、c0<=<はMaxCT-1=7と等しいです。 DS-TE解決策はBandwidth Constraintsの異なったセットを各コネチカットに実施できなければなりません。 DS-TE実現は、少なくとも2CTsを支持しなければならなくて、最大8CTsを支持するかもしれません。

   In a given network, the DS-TE solution MUST NOT require the network
   administrator to always deploy the maximum number of CTs.  The DS-TE
   solution MUST allow the network administrator to deploy only the
   number of CTs actually utilized.

与えられたネットワークでは、DS-TE解決策は、ネットワーク管理者がいつもCTsの最大数を配備するのを必要としてはいけません。 ネットワーク管理者はDS-TE解決策で実際に利用されたCTsの数しか配備できなくなければなりません。

Le Faucheur & Lai            Informational                     [Page 10]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[10ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

3.3.  Bandwidth Constraints

3.3. 帯域幅規制

   We refer to a Bandwidth Constraint Model as the set of rules
   defining:

私たちは以下を定義する規則のセットとBandwidth Constraint Modelを呼びます。

   - the maximum number of Bandwidth Constraints; and
   - which CTs each Bandwidth Constraint applies to and how.

- Bandwidth Constraintsの最大数。 そして、--各Bandwidth Constraintは、どのCTsがそうするのに申し込みますか、そして、どのように。

   By definition of CT, each CT is assigned either a Bandwidth
   Constraint, or a set of Bandwidth Constraints.

定義上、コネチカットでは、各コネチカットがBandwidth ConstraintかBandwidth Constraintsの1セットのどちらかに配属されます。

   We refer to the Bandwidth Constraints as BCb, 0 <= b <= MaxBC-1

b BCb、0<=<がMaxBC-1と等しいときに、私たちはBandwidth Constraintsを参照します。

   For a given Class-Type CTc, 0 <= c <= MaxCT-1, let us define
   "Reserved(CTc)" as the sum of the bandwidth reserved by all
   established LSPs which belong to CTc.

与えられたClass-タイプのために、すべてによって控えられた帯域幅の合計がCTcに属すLSPsを設立したので、CTc(c0<=<=MaxCT-1)は私たちに「予約された(CTc)」を定義させることができます。

   Different models of Bandwidth Constraints are conceivable for control
   of the CTs.

Bandwidth Constraintsの異なったモデルはCTsのコントロールにおいて想像できます。

   For example, a model with one separate Bandwidth Constraint per CT
   could be defined.  This model is referred to as the "Maximum
   Allocation Model" and is defined by:

例えば、1コネチカットあたり1別々のBandwidth Constraintのモデルを定義できました。 このモデルは、「最大の配分モデル」と呼ばれて、以下によって定義されます。

        - MaxBC= MaxCT
        - for each value of b in the range 0 <= b <= (MaxCT - 1):
               Reserved (CTb) <= BCb

- MaxBC= MaxCT--範囲のbの各値のために、0<はb<=(MaxCT--1)と等しいです: 予約された(CTb)<はBCbと等しいです。

   For illustration purposes, on a link of 100 unit of bandwidth where
   three CTs are used, the network administrator might then configure
   BC0=20, BC1= 50, BC2=30 such that:

イラスト目的のために3CTsが使用されている100の帯域幅のリンクの上では次に、ネットワーク管理者がBC0=20、BC1=50を構成するかもしれなくて、BC2=30がそのようなものであるので:

   - All LSPs supporting Traffic Trunks from CT2 use no more than 30
     (e.g., Voice <= 30)
   - All LSPs supporting Traffic Trunks from CT1 use no more than 50
     (e.g., Premium Data <= 50)
   - All LSPs supporting Traffic Trunks from CT0 use no more than 20
     (e.g.,  Best Effort <= 20)

- CT2からTraffic Trunksを支持するすべてのLSPsが30(例えば、Voice<=30)未満を使用します--CT1からTraffic Trunksを支持するすべてのLSPsが50(例えば、Premium Data<=50)未満を使用します--CT0からTraffic Trunksを支持するすべてのLSPsが20未満を使用します。(例えば、ベストエフォート型<=20)

   As another example, a "Russian Doll" model of Bandwidth Constraints
   may be defined whereby:

別の例と、Bandwidth Constraintsの「ロシアの人形」モデルが定義されるかもしれない、どうして、:

        - MaxBC= MaxCT
        - for each value of b in the range 0 <= b <= (MaxCT - 1):
               SUM (Reserved (CTc)) <= BCb,
               for all "c" in the range  b <= c <= (MaxCT - 1)

- MaxBC= MaxCT--範囲のbの各値のために、0<はb<=(MaxCT--1)と等しいです: c範囲b<=<=のすべての「c」のためのSUM((CTc)を予約する)<=BCb(MaxCT--1)

Le Faucheur & Lai            Informational                     [Page 11]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[11ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   For illustration purposes, on a link of 100 units of bandwidth where
   three CTs are used, the network administrator might then configure
   BC0=100, BC1= 80, BC2=60 such that:

イラスト目的のために3CTsが使用されている100の帯域幅のリンクの上では次に、ネットワーク管理者がBC0=100、BC1=80を構成するかもしれなくて、BC2=60がそのようなものであるので:

   - All LSPs supporting Traffic Trunks from CT2 use no more than 60
     (e.g., Voice <= 60)
   - All LSPs supporting Traffic Trunks from CT1 or CT2 use no more than
     80 (e.g., Voice + Premium Data <= 80)
   - All LSPs supporting Traffic Trunks from CT0 or CT1 or CT2 use no
     more than 100 (e.g., Voice + Premium Data + Best Effort <= 100).

- CT2からTraffic Trunksを支持するすべてのLSPsが60(例えば、Voice<=60)未満を使用します--CT1かCT2からTraffic Trunksを支持するすべてのLSPsが80(例えば、Voice+プレミアムData<=80)未満を使用します--CT0、CT1またはCT2からTraffic Trunksを支持するすべてのLSPsが100(例えば、最もVoice+プレミアムData+良いEffort<=100)未満を使用します。

   Other Bandwidth Constraints model can also be conceived.  Those could
   involve arbitrary relationships between BCb and CTc.  Those could
   also involve additional concepts such as associating minimum
   reservable bandwidth to a CT.

また、他のBandwidth Constraintsモデルを発想できます。 ものはBCbとCTcとの任意の関係にかかわることができました。 また、ものは最小の予約可能帯域幅をコネチカットに関連づけなどなどの追加概念にかかわることができました。

   The DS-TE technical solution MUST have the capability to support
   multiple Bandwidth Constraints models.  The DS-TE technical solution
   MUST specify at least one bandwidth constraint model and MAY specify
   multiple Bandwidth Constraints models.  Additional Bandwidth
   Constraints models MAY also be specified at a later stage if deemed
   useful based on operational experience from DS-TE deployments.  The
   choice of which (or which set of) Bandwidth Constraints model(s) is
   to be supported by a given DS-TE implementation, is an implementation
   choice.  For simplicity, a network operator may elect to use the same
   Bandwidth Constraints Model on all the links of his/her network.
   However, if he/she wishes/needs to do so, the network operator may
   elect to use different Bandwidth Constraints models on different
   links in a given network.

DS-TE技術的解決法には、複数のBandwidth Constraintsモデルをサポートする能力がなければなりません。 DS-TE技術的解決法は、少なくとも1つの帯域幅規制モデルを指定しなければならなくて、複数のBandwidth Constraintsモデルを指定するかもしれません。 また、DS-TE展開からの運用経験に基づいて役に立つと考えられるなら、追加Bandwidth Constraintsモデルは後期段階に指定されるかもしれません。 どれで特選する、(どれがセットしたか、)、帯域幅Constraintsモデルは当然のことのDS-TE実現でサポートされることになっていて、実現選択はそうです。 簡単さのために、ネットワーク・オペレータは、その人のネットワークのすべてのリンクの上の同じBandwidth Constraints Modelを使用するのを選ぶかもしれません。 しかしながら、その人が、そうする願っているか、または必要があるなら、ネットワーク・オペレータは、異なったリンクの上に与えられたネットワークに異なったBandwidth Constraintsモデルを使用するのを選ぶかもしれません。

   Regardless of the Bandwidth Constraint Model, the DS-TE solution MUST
   allow support for up to 8 BCs.

Bandwidth Constraint Modelにかかわらず、DS-TE解決策は8BCsまでサポートを許さなければなりません。

3.4.  Preemption and TE-Classes

3.4. 先取りとTeクラス

   [TEWG-FW] defines the notion of preemption and preemption priority.
   The DS-TE solution MUST retain full support of such preemption.
   However, a network administrator preferring not to use preemption for
   user traffic MUST be able to disable the preemption mechanisms
   described below.

[TEWG-FW]は先取りと先取り優先権の概念を定義します。 DS-TE解決策はそのような先取りの全面的な支援を保有しなければなりません。 しかしながら、ユーザ交通に先取りを使用しないのを好むネットワーク管理者は以下で説明された先取りメカニズムを無効にすることができなければなりません。

   The preemption attributes defined in [TE-REQ] MUST be retained and
   applicable across all Class Types.  The preemption attributes of
   setup priority and holding priority MUST retain existing semantics,
   and in particular these semantics MUST not be affected by the Ordered
   Aggregate transported by the LSP or by the LSP's Class Type.  This
   means that if LSP1 contends with LSP2 for resources, LSP1 may preempt
   LSP2 if LSP1 has a higher set-up preemption priority (i.e., lower

[TE-REQ]で定義された先取り属性は、すべてのClass Typesの向こう側に保有されていて適切であるに違いありません。 セットアップ優先権と把持優先権の先取り属性は既存の意味論を保有しなければなりません、そして、特に、これらの意味論はLSPかLSPのClass Typeによって輸送されたOrdered Aggregateで影響を受けてはいけません。 これが、LSP1がリソースのためにLSP2を競争するなら、LSP1により高いセットアップ先取り優先度があるならLSP1がLSP2を先取りするかもしれないことを意味する、(すなわち、下ろしてください。

Le Faucheur & Lai            Informational                     [Page 12]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[12ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   numerical priority value) than LSP2's holding preemption priority
   regardless of LSP1's OA/CT and LSP2's OA/CT.

数字の優先順位の値) LSP2がLSP1のOA/コネチカットとLSP2のOA/コネチカットにかかわらず先取り優先権を保持するより。

   We introduce the following definition:

私たちは以下の定義を導入します:

       TE-Class: A pair of:
               (i)    a Class-Type
               (ii)   a preemption priority allowed for that
                      Class-Type.  This means that an LSP transporting a
                      Traffic Trunk from that Class-Type can use that
                      preemption priority as the set-up priority, as the
                      holding priority or both.

Teクラス: 以下の1組 (i) 先取り優先がそれのために許容したClass-タイプ(ii)はClassタイプします。 これは、そのClass-タイプからTraffic Trunkを輸送するLSPがセットアップ優先権としてその先取り優先権を使用できることを意味します、把持優先権か両方として。

   Note that by definition:

定義上それに注意してください:

   - for a given Class-Type, there may be one or multiple
     TE-classes using that Class-Type, each using a different preemption
     priority
   - for a given preemption priority, there may be one or multiple
     TE-Class(es) using that preemption priority, each using a different
     Class-Type.

- 与えられたClass-タイプのために、そのClass-タイプを使用するものか複数のTE-クラスがあるかもしれません、それぞれ異なった先取り優先を使用して--与えられた先取り優先のために、その先取り優先権を使用するものか複数のTE-クラス(es)があるかもしれません、それぞれ異なったClass-タイプを使用して。

   The DS-TE solution MUST allow all LSPs transporting Traffic Trunks of
   a given Class-Type to use the same preemption priority.  In other
   words, the DS-TE solution MUST allow a Class-Type to be used by
   single TE-Class.  This effectively allows the network administrator
   to ensure that no preemption happens within that Class-Type, when so
   desired.

DS-TE解決策で、与えられたClass-タイプのTraffic Trunksを輸送するすべてのLSPsが同じ先取り優先権を使用できなければなりません。 言い換えれば、DS-TE解決策は、Class-タイプがただ一つのTE-クラスによって使用されるのを許容しなければなりません。 これで、そう望まれていると、事実上、ネットワーク管理者は、先取りが全くそのClass-タイプの中で起こらないのを保証できます。

   As an example, the DS-TE solution MUST allow the network
   administrator to define a Class-Type comprising a single TE-class
   using preemption 0.

例として、DS-TE解決策で、先取り0を使用することで1つのTE-クラスを包括して、ネットワーク管理者はClass-タイプを定義できなければなりません。

   The DS-TE solution MUST allow two LSPs transporting Traffic Trunks of
   the same Class-Type to use different preemption priorities, and allow
   the LSP with higher (numerically lower) set-up priority to preempt
   the LSP with lower (numerically higher) holding priority when they
   contend for resources.  In other words, the DS-TE solution MUST allow
   multiple TE-Classes to be defined for a given Class-Type. This
   effectively allows the network administrator to enable preemption
   within a Class-Type, when so desired.

リソースを競争するとき、DS-TE解決策は、同じClass-タイプのTraffic Trunksを輸送する2LSPsが異なった先取りプライオリティを使用するのを許容して、より高い(数の上で下側の)セットアップ優先度があるLSPが下側(数の上でより高い)の把持優先度でLSPを先取りするのを許容しなければなりません。 言い換えれば、DS-TE解決策は、複数のTE-クラスが与えられたClass-タイプのために定義されるのを許容しなければなりません。 これで、そう望まれていると、事実上、ネットワーク管理者はClass-タイプの中で先取りを可能にすることができます。

   As an example, the DS-TE solution MUST allow the network
   administrator to define a Class-Type comprising three TE-Classes; one
   using preemption 0, one using preemption 1 and one using preemption
   4.

例として、DS-TE解決策で、3つのTE-クラスを包括して、ネットワーク管理者はClass-タイプを定義できなければなりません。 先取り4を使用する先取り1と1を使用する先取り0、1を使用する1つ。

Le Faucheur & Lai            Informational                     [Page 13]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[13ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   The DS-TE solution MUST allow two LSPs transporting Traffic Trunks
   from different Class-Types to use different preemption priorities,
   and allow the LSP with higher setup priority to preempt the one with
   lower holding priority when they contend for resources.

リソースを競争するとき、DS-TE解決策は、異なったClass-タイプからTraffic Trunksを輸送する2LSPsが異なった先取りプライオリティを使用するのを許容して、より高いセットアップ優先度があるLSPが下側の把持優先度でものを先取りするのを許容しなければなりません。

   As an example, the DS-TE solution MUST allow the network
   administrator to define two Class-Types (CT0 and CT1) each comprising
   two TE-Classes where say:

例、DS-TE解決策がネットワーク管理者を許容しなければならないとき、それぞれ2つのTE-クラスを包括しながら2つのClass-タイプ(CT0とCT1)を定義するために、どこかが言います:

      -one TE-Class groups CT0 and preemption 0
      -one TE-Class groups CT0 and preemption 2
      -one TE-Class groups CT1 and preemption 1
      -one TE-Class groups CT1 and preemption 3

-1TE-階級集団CT0、-1先取り0TE-階級集団CT0、-1先取り2TE-階級集団CT1、-1先取り1TE-階級集団CT1、および先取り3

   The network administrator would then, in particular, be able to:

ネットワーク管理者はその時、以下に特にできるでしょう。

   - transport a CT0 Traffic Trunk over an LSP with setup priority=0 and
     holding priority=0
   - transport a CT0 Traffic Trunk over an LSP with setup priority=2 and
     holding priority=0
   - transport a CT1 Traffic Trunk over an LSP with setup priority=1 and
     holding priority=1
   - transport a CT1 Traffic Trunk over an LSP with setup priority=3 and
     holding priority=1.

- セットアップ優先権=0と優先権=0を保持するのはLSPの上でCT0 Traffic Trunkを輸送してください--セットアップ優先権=2と優先権=0を保持するのはLSPの上でCT0 Traffic Trunkを輸送してください--セットアップ優先権=1と優先権=1を保持するのはLSPの上でCT1 Traffic Trunkを輸送してください--LSPの上でセットアップ優先権=3と優先権=1を保持するのにCT1 Traffic Trunkを輸送してください。

   The network administrator would then, in particular, NOT be able to:

ネットワーク管理者はその時、以下に特にできないでしょう。

   - transport a CT0 Traffic Trunk over an LSP with setup priority=1 and
     holding priority=1
   - transport a CT1 Traffic Trunk over an LSP with setup priority=0 and
     holding priority=0

- セットアップ優先権=1と優先権=1を保持するのはLSPの上でCT0 Traffic Trunkを輸送してください--LSPの上でセットアップ優先権=0と優先権=0を保持するのにCT1 Traffic Trunkを輸送してください。

   The DS-TE solution MUST allow two LSPs transporting Traffic Trunks
   from different Class-Types to use the same preemption priority.  In
   other words, the DS-TE solution MUST allow TE-classes using different
   CTs to use the same preemption priority.  This effectively allows the
   network administrator to ensure that no preemption happens across
   Class-Types, if so desired.

DS-TE解決策で、異なったClass-タイプからTraffic Trunksを輸送する2LSPsが同じ先取り優先権を使用できなければなりません。 言い換えれば、DS-TE解決策で、異なったCTsを使用するTE-クラスは同じ先取り優先権を使用できなければなりません。 これで、そう望まれているなら、事実上、ネットワーク管理者は、先取りが全くClass-タイプの向こう側に起こらないのを保証できます。

   As an example, the DS-TE solution MUST allow the network
   administrator to define three Class-Types (CT0, CT1 and CT2) each
   comprising one TE-Class which uses preemption 0.  In that case, no
   preemption will ever occur.

例として、DS-TE解決策で、それぞれ先取り0を使用する1つのTE-クラスを包括して、ネットワーク管理者は3つのClass-タイプ(CT0、CT1、およびCT2)を定義できなければなりません。 その場合、先取りは全く起こらないでしょう。

   Since there are 8 preemption priorities and up to 8 Class-Types,
   there could theoretically be up to 64 TE-Classes in a network.  This
   is felt to be beyond current practical requirements.  The current
   practical requirement is that the DS-TE solution MUST allow support

8つの先取りプライオリティと最大8つのClass-タイプがあるので、ネットワークには最大64のTE-クラスが理論的にあるかもしれません。 これは現在の実際的な要件を超えていると感じられます。 現在の実際的な要件はDS-TE解決策がサポートを許さなければならないということです。

Le Faucheur & Lai            Informational                     [Page 14]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[14ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   for up to 8 TE-classes.  The DS-TE solution MUST allow these
   TE-classes to comprise any arbitrary subset of 8 (or less) from the
   (64) possible combinations of (8) Class-Types and (8) preemption
   priorities.

8つのTeクラスまで。 DS-TE解決策で、これらのTE-クラスは(8) クラスタイプと(8) 先取りプライオリティの(64)の可能な組み合わせから8(それほど)のどんな任意の部分集合も包括できなければなりません。

   As with existing TE, an LSP which gets preempted is torn down at
   preemption time.  The Head-end of the preempted LSP may then attempt
   to reestablish that LSP, which involves re-computing a path by
   Constraint Based Routing based on updated available bandwidth
   information and then signaling for LSP establishment along the new
   path.  It is to be noted that there may be cases where the preempted
   LSP cannot be reestablished (e.g., no possible path satisfying LSP
   bandwidth constraints as well as other constraints).  In such cases,
   the Head-end behavior is left to implementation.  It may involve
   periodic attempts at reestablishing the LSP, relaxing of the LSP
   constraints, or other behaviors.

既存のTEのように、先取り時に先取りされるLSPを取りこわします。 そして、先取りされたLSPのHead-端は、そのLSPを復職させるのを試みるかもしれません。(LSPはアップデートされた利用可能な帯域幅情報に基づくConstraint Basedルート設定で経路を再計算して、次に、新しい経路に沿ったLSP設立のために合図することを伴います)。 ケースが先取りされたLSPが復職できない(例えば、他の規制と同様に経路の可能な満足させるLSP帯域幅規制がありません)ところにあるかもしれないことに注意されることになっています。 そのような場合、Head-終わりの振舞いは実現に残されます。 それはLSP規制、または他の振舞いを弛緩して、LSPを復職させることへの周期的な試みにかかわるかもしれません。

3.5.  Mapping of Traffic to LSPs

3.5. LSPsへの交通に関するマッピング

   The DS-TE solution MUST allow operation over E-LSPs onto which a
   single <FEC/{TA}PSC> is transported.

DS-TE解決策はE-LSPsの上で独身の<FEC/TA PSC>がどれであるかに輸送された操作を許さなければなりません。

   The DS-TE solution MUST allow operation over L-LSPs.

DS-TE解決策はL-LSPsの上の操作を許さなければなりません。

   The DS-TE solution MAY allow operation over E-LSPs onto which
   multiple <FEC/{TA}PSC> of a given FEC are transported, under the
   condition that those multiple <FEC/{TA}PSC> can effectively be
   treated by DS-TE as a single atomic traffic trunk (in particular this
   means that those multiple <FEC/{TA}PSC> are routed as a whole based
   on a single collective bandwidth requirement, a single affinity
   attribute, a single preemption level, a single Class-Type, etc.).  In
   that case, it is also assumed that the multiple {TA}PSCs are grouped
   together in a consistent manner throughout the DS-TE domain (e.g., if
   <FECx/{TA}PSC1> and <FECx/{TA}PSC2> are transported together on an
   E-LSP, then there will not be any L-LSP transporting <FECy/{TA}PSC1>
   or <FECy/{TA}PSC2> on its own, and there will not be any E-LSP
   transporting <FECz/{TA}PSC1> and/or <FECz/{TA}PSC2> with
   <FECz/{TA}PSC3>).

DS-TE解決策は事実上、DS-TEがただ一つの原子交通としてそれらの複数の<FEC/TA PSC>を扱うことができるという条件のもとで与えられたFECの複数の<FEC/TA PSC>がどれであるかに輸送されたE-LSPsの上の操作トランクを許容するかもしれません(特に、これは、それらの複数の<FEC/TA PSC>がただ一つの集合的な帯域幅要件、ただ一つの親近感属性、ただ一つの先取りレベル、単独のClass-タイプなどに基づいて全体で発送されることを意味します)。 その場合; また、それが想定される、それ、複数のTA、PSCsはDS-TEドメイン中の一貫した方法で一緒に分類されます(例えば、<FECx/TA PSC1>と<FECx/TA PSC2>がE-LSPで一緒に輸送されると、それ自身のところで<FECy/TA PSC1>か<FECy/TA PSC2>を輸送する少しのL-LSPもないでしょう、そして、<FECz/TA PSC3>で<FECz/TA PSC1>、そして/または、<FECz/TA PSC2>を輸送する少しのE-LSPもないでしょう)。

3.6.  Dynamic Adjustment of Diff-Serv PHBs

3.6. デフ-Serv PHBsの動態的調整

   As discussed in section 2.2, the DS-TE solution MAY support
   adjustment of Diff-Serv PHBs parameters (e.g., queue bandwidth) based
   on the amount of TE-LSPs established for each OA/Class-Type.  Such
   dynamic adjustment is optional for DS-TE implementations.

セクション2.2で議論するように、DS-TE解決策はそれぞれのクラスOA/タイプのために設立されたTE-LSPsの量に基づくDiff-Serv PHBsパラメタ(例えば、待ち行列帯域幅)の調整を支持するかもしれません。 DS-TE実現に、そのような動態的調整は任意です。

Le Faucheur & Lai            Informational                     [Page 15]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[15ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   Where this dynamic adjustment is supported, it MUST allow for
   disabling via configuration (thus reverting to PHB treatment with
   static scheduler configuration independent of DS-TE operations).  It
   MAY involve a number of configurable parameters which are outside the
   scope of this specification.  Those MAY include configurable
   parameters controlling how scheduling resources (e.g., service rates)
   need to be apportioned across multiple OAs when those belong to the
   same Class-Type and are transported together on the same E-LSP.

この動態的調整が支持されるところでは、それは、構成で無能にすると考慮しなければなりません(その結果、DS-TE操作の如何にかかわらず静的なスケジューラ構成と共にPHB処理に戻ります)。 それはこの仕様の範囲の外にある多くの構成可能なパラメタにかかわるかもしれません。 それらの5月はスケジューリングリソース(例えば、サービス率)がどうものが同じClass-タイプのものであるなら複数のOAsの向こう側に分配されるのが必要であり、同じE-LSPで一緒に輸送されるかを制御する構成可能なパラメタを含んでいます。

   Where supported, the dynamic adjustment MUST take account of the
   performance requirements of each PDB when computing required
   adjustments.

コンピューティングが調整を必要としたとき、支持されるところでは、動態的調整はそれぞれのPDBの性能要件を考慮に入れなければなりません。

3.7.  Overbooking

3.7. オーバーブッキング

   Existing TE mechanisms allow overbooking to be applied on LSPs for
   Constraint Based Routing and admission control.  Historically, this
   has been achieved in TE deployment through factoring overbooking
   ratios at the time of sizing the LSP bandwidth and/or at the time of
   configuring the Maximum Reservable Bandwidth on links.

既存のTEメカニズムは、Constraint Basedルート設定と入場コントロールのためにLSPsに適用されるためにオーバーブックするのを許容します。 LSP帯域幅を大きさで分ける時点でオーバーブッキング比を因数分解するリンクの上にMaximum Reservable Bandwidthを構成する時点で、歴史的に、これはTE展開で達成されました。

   The DS-TE solution MUST also allow overbooking and MUST effectively
   allow different overbooking ratios to be enforced for different CTs.

DS-TE解決策は、また、オーバーブックするのを許容しなければならなくて、事実上、異なったオーバーブッキング比が異なったCTsのために励行されるのを許容しなければなりません。

   The DS-TE solution SHOULD optionally allow the effective overbooking
   ratio of a given CT to be tweaked differently in different parts of
   the network.

DS-TE解決策SHOULDは、与えられたコネチカットの有効なオーバーブッキング比がネットワークの異なった部分で異なってひねられるのを任意に許容します。

3.8.  Restoration

3.8. 王政復古

   With existing TE, restoration policies use standard priority
   mechanisms such as, for example, the preemption priority to
   effectively control the order/importance of LSPs for restoration
   purposes.

既存のTEと共に、回復方針は、事実上、回復目的のためにLSPsのオーダー/重要性を制御するのに例えば、先取り優先権などの標準の優先権メカニズムを使用します。

   The DS-TE solution MUST ensure that similar application of the use of
   standard priority mechanisms for implementation of restoration policy
   are not prevented since those are expected to be required for
   achieving the survivability requirements of DS-TE networks.

DS-TE解決策は、ものがDS-TEネットワークの生存性要件を達成するのに必要であると予想されて、標準の優先権メカニズムの回復方針の実現の使用の同様の応用が防がれないのを確実にしなければなりません。

   Further discussion of restoration requirements are presented in the
   output document of the TEWG Requirements Design Team [SURVIV-REQ].

要件がTEWG Requirements Design Team[SURVIV-REQ]の出力ドキュメントに示される回復のさらなる議論。

4.  Solution Evaluation Criteria

4. ソリューション評価基準

   A range of solutions is possible for the support of the DS-TE
   requirements discussed above.  For example, some solutions may
   require that all current TE protocols syntax (IGP, RSVP-TE,) be

上で議論したDS-TE要件のサポートに、さまざまな解決策が可能です。 例えば、何らかの解決法は、すべての現在のTEプロトコル構文(IGP、RSVP-TE)があるのを必要とするかもしれません。

Le Faucheur & Lai            Informational                     [Page 16]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[16ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   extended in various ways.  For instance, current TE protocols could
   be modified to support multiple bandwidth constraints rather than the
   existing single aggregate bandwidth constraint.  Alternatively, other
   solutions may keep the existing TE protocols syntax unchanged but
   modify their semantics to allow for the multiple bandwidth
   constraints.

様々な方法で広げられます。 例えば、既存のただ一つの集合帯域幅規制よりむしろ複数の帯域幅規制を支持するように現在のTEプロトコルを変更できました。 あるいはまた、他の解決策は、既存のTEプロトコル構文を変わりがなく保ちますが、複数の帯域幅規制を考慮するようにそれらの意味論を変更するかもしれません。

   This section identifies the evaluation criteria that MUST be used to
   assess potential DS-TE solutions for selection.

このセクションは選択の潜在的DS-TE解決策を評価するのに使用しなければならない評価基準を特定します。

4.1.  Satisfying detailed requirements

4.1. 詳細な要件を満たします。

   The solution MUST address all the scenarios described in section 2
   and satisfy all the requirements listed in section 3.

解決策は、セクション2で説明されたすべてのシナリオを記述して、セクション3でリストアップされたすべての要件を満たさなければなりません。

4.2.  Flexibility

4.2. 柔軟性

   -  number of Class-Types that can be supported, compared to number
      identified in Requirements section
   -  number of PDBs within a Class-Type

- 支持できるClass-タイプの数、比べて、数はClass-タイプの中でRequirementsでセクション--数のPDBsを特定しました。

4.3.  Extendibility

4.3. 拡張性

   -  how far can the solution be extended in the future if requirements
      for more Class-Types are identified in the future.

- どれくらい遠くに、より多くのClass-タイプのための要件が将来特定されるなら、将来、解決策を広げることができますか?

4.4.  Scalability

4.4. スケーラビリティ

   -  impact on network scalability in what is propagated, processed,
      stored and computed (IGP signaling, IGP processing, IGP database,
      TE-Tunnel signaling ,...).
   -  how does scalability impact evolve with number of
      Class-Types/PDBs actually deployed in a network.  In particular,
      is it possible to keep overhead small for a large networks which
      only use a small number of
      Class-Types/PDBs, while allowing higher number of
      Class-Types/PDBs in smaller networks which can bear higher
      overhead)

- 伝播されて、処理されて、格納されて、計算されるものにおけるネットワークスケーラビリティで影響を与えてください(IGPシグナリング(IGP処理、IGPデータベース)はシグナリングにTEトンネルを堀ります…)。 - Class-タイプ/PDBsの数が実際にネットワークで配備されている状態で、スケーラビリティ衝撃はどのように発展しますか? より高いオーバーヘッドを負担できるより小さいネットワークにおける、Class-タイプ/PDBsの、より大きい数を許容している間にClass-タイプ/PDBsの少ない数を使用するだけである大きいネットワークに小さくオーバーヘッドを保つのが特に、可能である、)

4.5.  Backward compatibility/Migration

4.5. 後方の互換性/移動

   -  backward compatibility/migration with/from existing TE mechanisms
   -  backward compatibility/migration when increasing/decreasing the
      number of Class-Types actually deployed in a given network.

- 既存のTEメカニズムからの/がある後方の互換性/移動--Class-タイプの数を増加するか、または減少させるとき、後方の互換性/移動は実際に与えられたネットワークで展開しました。

Le Faucheur & Lai            Informational                     [Page 17]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[17ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

4.6.  Bandwidth Constraints Model

4.6. 帯域幅規制モデル

   Work is currently in progress to investigate the performance and
   trade-offs of different operational aspects of Bandwidth Constraints
   models (for example see [BC-MODEL], [BC-CONS] and [MAR]).  In this
   investigation, at least the following criteria are expected to be
   considered:

仕事は、現在、Bandwidth Constraintsモデル(例えば、[紀元前-MODEL]、[BCコンズ]、および[3月]を見る)の異なった操作上の局面の性能とトレードオフを調査するために進行しています。 この調査では、少なくとも以下の評価基準が考えられると予想されます:

       (1) addresses the scenarios in Section 2
       (2) works well under both normal and overload conditions
       (3) applies equally when preemption is either enabled or disabled
       (4) minimizes signaling load processing requirements
       (5) maximizes efficient use of the network
       (6) Minimizes implementation and deployment complexity.

(1)は正常な状態で(2)が両方の下でよく扱うセクション2のシナリオを記述します、そして、先取りが可能にされるか、または無能にされて、(4)が(5)がネットワーク(6)の効率的な使用を最大にするというシグナリング負荷処理要件を最小にすると、状態(3)が等しく適用するオーバーロードは実現と展開の複雑さを最小にします。

   In selection criteria (2), "normal condition" means that the network
   is attempting to establish a volume of DS-TE LSPs for which it is
   designed; "overload condition" means that the network is attempting
   to establish a volume of DS-TE LSPs beyond the one it is designed
   for; "works well" means that under these conditions, the network
   should be able to sustain the expected performance, e.g., under
   overload it is x times worse than its normal performance.

選択評価基準(2)では、「正常な状態」は、ネットワークが、それが設計されているDS-TE LSPsのボリュームを確立するのを試みていることを意味します。 「過負荷条件」は、ネットワークが、それが設計されているものを超えてDS-TE LSPsのボリュームを確立するのを試みていることを意味します。 これらの状態、ネットワークの下で予想された性能に耐えることができます、例えば、オーバーロードの下では、それが正常動作より何倍も悪いxであることであるべきである手段を「よく扱います」。

5.  Security Considerations

5. セキュリティ問題

   The solution developed to address the DS-TE requirements defined in
   this document MUST address security aspects.  DS-TE does not raise
   any specific additional security requirements beyond the existing
   security requirements of MPLS TE and Diff-Serv.  The solution MUST
   ensure that the existing security mechanisms (including those
   protecting against DOS attacks) of MPLS TE and Diff-Serv are not
   compromised by the protocol/procedure extensions of the DS-TE
   solution or otherwise MUST provide security mechanisms to address
   this.

本書では定義されたDS-TE要件を記述するために見いだされた解決策はセキュリティ局面を記述しなければなりません。 DS-TEはMPLS TEとDiff-Servの既存のセキュリティ要件を超えたどんな特定の追加担保要件も上げません。 解決策は、MPLS TEとDiff-Servの既存のセキュリティー対策(DOS攻撃から守るものを含んでいる)がDS-TE解決策のプロトコル/手順拡大で妥協してはいけませんし、またこれを記述するために別の方法でセキュリティー対策を提供しなければならないのを確実にしなければなりません。

6.  Acknowledgment

6. 承認

   We thank David Allen for his help in aligning with up-to-date
   Diff-Serv terminology.

私たちは彼の助けについて最新のDiff-Serv用語に並ぶ際にデビッド・アレンに感謝します。

7.  Normative References

7. 引用規格

   [AF]         Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
                "Assured Forwarding PHB Group", RFC 2597, June 1999.

[AF] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。

   [DIFF-ARCH]  Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                and W. Weiss,  "An Architecture for Differentiated
                Services", RFC 2475, December 1998.

[デフアーチ] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。

Le Faucheur & Lai            Informational                     [Page 18]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[18ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   [DIFF-FIELD] Nichols, K., Blake, S., Baker, F. and D. Black,
                "Definition of the Differentiated Services Field (DS
                Field) in the IPv4 and IPv6 Headers", RFC 2474, December
                1998.

[デフ分野] ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。

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

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

   [DIFF-MPLS]  Le Faucheur, F., Wu, L., Davie, B., Davari, S.,
                Vaananen, P., Krishnan, R., Cheval, P. and J. Heinanen,
                "Multi-Protocol Label Switching (MPLS) Support of
                Differentiated Services", RFC 3270, May 2002.

[デフ-MPLS]Le Faucheur、F.、ウー、L.、デイビー、B.、Davari、S.、バーナネン、P.、クリシュナン、R.、シェヴァル、P.、およびJ.Heinanen、「微分されたサービスのマルチプロトコルラベルスイッチング(MPLS)サポート」(RFC3270)は2002がそうするかもしれません。

   [DIFF-NEW]   Grossman, D., "New Terminology and Clarifications for
                Diffserv", RFC 3260, April 2002.

[デフ新しい] グロースマンと、D.と、「Diffservのための新しい用語と明確化」、RFC3260、4月2002日

   [EF]         Davie, B., Charny, A., Bennet, J.C.R., Benson, K., Le
                Boudec, J.Y., Davari, S., Courtney, W., Firioiu, V. and
                D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
                Behavior)", RFC 3246, March 2002.

[EF] デイビーとB.とシャルニーとA.とアメリカダイコンソウとJ.C.R.とベンソンとK.とLe BoudecとJ.Y.とDavariとS.とコートニーとW.とFirioiuとV.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。

   [TEWG-FW]    Awduche, D., Chiu, A., Elwalid, A., Widjaja, I. and X.
                Xiao, "Overview and Principles of Internet Traffic
                Engineering", RFC 3272, May 2002.

[TEWG-FW] Awduche、D.、チウ、A.、Elwalid、A.、ウィジャヤ、I.、X.Xiao、および「概観とインターネットプリンシプルズ交通工学」(RFC3272)は2002がそうするかもしれません。

   [TE-REQ]     Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
                McManus, "Requirements for Traffic Engineering over
                MPLS", RFC 2702, September 1999.

[Te-REQ] AwducheとD.とマルコムとJ.とAgogbuaとJ.、オデルとM.とJ.マクマナス、「MPLSの上の交通工学のための要件」RFC2702(1999年9月)。

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

8.  Informative References

8. 有益な参照

   [DIFF-PDB]   Nichols, K. and B. Carpenter, "Definition of
                Differentiated Services Per Domain Behaviors and Rules
                for their Specification", RFC 3086, April 2001.

[DIFF-PDB]ニコルズ、K.とB.Carpenter、「彼らのSpecificationのためのDifferentiated Services Per Domain BehaviorsとRulesの定義」RFC3086(2001年4月)。

   [ISIS-TE]    Smit, Li, "IS-IS extensions for Traffic Engineering",
                Work in Progress, December 2002.

スミット、[イシス-TE]李、「-、Traffic Engineeringのための拡大、」、Progress、12月2002日のWork

   [OSPF-TE]    Katz, et al., "Traffic Engineering Extensions to OSPF",
                Work in Progress, October 2002.

[OSPF-TE] キャッツ、他、「OSPFへの交通工学拡大」、Progress、2002年10月のWork。

   [RSVP-TE]    Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V.
                and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
                Tunnels", RFC 3209, December 2001.

[RSVP-Te] Awduche、D.、バーガー、L.、ガン、D.、李、T.、Srinivasan、V.、およびG.が飲み込まれる、「RSVP-Te:」 「LSP TunnelsのためのRSVPへの拡大」、RFC3209、2001年12月。

Le Faucheur & Lai            Informational                     [Page 19]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[19ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   [SURVIV-REQ] Lai, W. and D. McDysan, "Network Hierarchy and
                Multilayer Survivability", RFC 3386, November 2002.

[SURVIV-REQ] レイ、W.、およびD.McDysanが「階層構造と多層の生存性をネットワークでつなぐ」、RFC3386、11月2002日

   [BC-MODEL]   Lai, W., "Bandwidth Constraints Models for
                Diffserv-aware MPLS Traffic Engineering: Performance
                Evaluation", Work in Progress, June 2002.

[紀元前モデル]レイ、W.、「Diffserv意識しているMPLS交通への以下を設計する帯域幅規制モデル」 「業績評価」、処理中の作業、2002年6月。

   [BC-CONS]    F. Le Faucheur, "Considerations on Bandwidth Constraints
                Models for DS-TE", Work in Progress, June 2002.

「DS-Teのための帯域幅規制モデルの上の問題」という[BCコンズ]F.Le Faucheurは進歩、2002年6月に働いています。

   [MAR]        Ash, J., "Max Allocation with Reservation Bandwidth
                Constraint Model for MPLS/DiffServ TE & Performance
                Comparisons", Work in Progress, May 2003.

[3月]灰、J.、「MPLS/DiffServ Teとパフォーマンス比較のための予約帯域幅規制モデルとのマックスAllocation」が進行中(2003年5月)で働いています。

9.  Contributing Authors

9. 作者を寄付します。

   This document was the collective work of several people.  The text
   and content of this document was contributed by the editors and the
   co-authors listed below.  (The contact information for the editors
   appears below.)

このドキュメントは数人の集合著作物でした。 このドキュメントのテキストと中身はエディタと以下に記載された共著者によって寄付されました。 (エディタへの問い合わせ先は以下に現れます。)

   Martin Tatham                        Thomas Telkamp
   BT                                   Global Crossing
   Adastral Park, Martlesham Heath,     Oudkerkhof 51,  3512 GJ Utrecht
   Ipswich IP5 3RE, UK                  The Netherlands
   Phone: +44-1473-606349               Phone: +31 30 238 1250
   EMail: martin.tatham@bt.com          EMail: telkamp@gblx.net

マーチンTathamトーマスTelkamp BTグローバルクロッシングAdastralは駐車します、Martleshamヒース、Oudkerkhof51、3512GJユトレヒトイプスウィッチIP5 3RE、イギリスのオランダ電話: +44-1473-606349は電話をします: +31 30 238 1250はメールされます: martin.tatham@bt.com メール: telkamp@gblx.net

   David Cooper                         Jim Boyle
   Global Crossing                      Protocol Driven Networks, Inc.
   960 Hamlin Court                     1381 Kildaire Farm Road #288
   Sunnyvale, CA 94089, USA             Cary, NC 27511, USA
   Phone: (916) 415-0437                Phone: (919) 852-5160
   EMail: dcooper@gblx.net              EMail: jboyle@pdnets.com

デヴィッド桶屋ジムボイルグローバルクロッシングのプロトコルの駆動ネットワークサニーベル、Inc.960ハムリン法廷1381Kildaire農道#288カリフォルニア 94089、米国のケーリー、NC 27511、米国は以下に電話をします。 (916) 415-0437 以下に電話をしてください。 (919) 852-5160 メールしてください: dcooper@gblx.net メール: jboyle@pdnets.com

   Luyuan Fang                          Gerald R. Ash
   AT&T Labs                            AT&T Labs
   200 Laurel Avenue                    200 Laurel Avenue
   Middletown, New Jersey 07748, USA    Middletown, New Jersey 07748,USA
   Phone: (732) 420-1921                Phone: (732) 420-4578
   EMail: luyuanfang@att.com            EMail: gash@att.com

AT&T研究室200ローレルアベニュー200ローレルアベニューミドルタウン、ニュージャージー 07748、米国ミドルタウン、ニュージャージー 07748、米国が電話をするLuyuan牙のジェラードR.灰のAT&T研究室: (732) 420-1921 以下に電話をしてください。 (732) 420-4578 メールしてください: luyuanfang@att.com メール: gash@att.com

Le Faucheur & Lai            Informational                     [Page 20]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[20ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

   Pete Hicks                           Angela Chiu
   CoreExpress, Inc                     AT&T Labs-Research
   12655 Olive Blvd, Suite 500          200 Laurel Ave.  Rm A5-1F13
   St. Louis, MO 63141, USA             Middletown, NJ 07748, USA
   Phone: (314) 317-7504                Phone: (732) 420-9061
   EMail: pete.hicks@coreexpress.net    EMail: chiu@research.att.com

ピート田舎者アンジェラチウCoreExpress、Inc AT&T研究室研究12655オリーブBlvd、スイート500 200ローレルAve。 セントルイス、Rm A5-1F13MO 63141、米国ミドルタウン、ニュージャージー 07748、米国は以下に電話をします。 (314) 317-7504 以下に電話をしてください。 (732) 420-9061 メールしてください: pete.hicks@coreexpress.net メール: chiu@research.att.com

   William Townsend                     Thomas D. Nadeau
   Tenor Networks                       Cisco Systems, Inc.
   100 Nagog Park                       300 Beaver Brook Road
   Acton, MA 01720, USA                 Boxborough, MA  01719
   Phone: +1 978-264-4900               Phone: +1-978-936-1470
   EMail:btownsend@tenornetworks.com    EMail: tnadeau@cisco.com

ウィリアムタウンゼンドトーマスD.ナドーテノールはMA 01720、米国Boxborough、MA Nagog公園300ビーバーブルック道路鎧下、01719が電話をするシスコシステムズInc.100をネットワークでつなぎます: +1 978-264-4900 以下に電話をしてください。 +1-978-936-1470 メール: btownsend@tenornetworks.com メール: tnadeau@cisco.com

   Darek Skalecki
   Nortel Networks
   3500 Carling Ave,
   Nepean K2H 8E9,
   Phone: (613) 765-2252
   EMail: dareks@nortelnetworks.com

Darek SkaleckiノーテルはAve(ネピアンK2H8E9)が電話をする3500年の縦梁をネットワークでつなぎます: (613) 765-2252 メールしてください: dareks@nortelnetworks.com

10.  Editors' Addresses

10. エディタのアドレス

   Francois Le Faucheur
   Cisco Systems, Inc.
   Village d'Entreprise Green Side - Batiment T3
   400, Avenue de Roumanille
   06410 Biot-Sophia Antipolis, France

フランソアLe FaucheurシスコシステムズInc.Village d'EntrepriseグリーンSide--Batiment T3 400、Antipolis、アベニューdeルーマニーユ06410Biot-ソフィア・フランス

   Phone: +33 4 97 23 26 19
   EMail: flefauch@cisco.com

以下に電話をしてください。 +33 4 97 23 26 19はメールされます: flefauch@cisco.com

   Wai Sum Lai
   AT&T Labs
   200 Laurel Avenue
   Middletown, New Jersey 07748, USA

Wai合計レイAT&T研究室200ローレルアベニューミドルタウン、ニュージャージー 07748、米国

   Phone: (732) 420-3712
   EMail: wlai@att.com

以下に電話をしてください。 (732) 420-3712 メールしてください: wlai@att.com

Le Faucheur & Lai            Informational                     [Page 21]

RFC 3564          Requirements for Diff-Serv-aware TE          July 2003

Le Faucheurとレイ情報[21ページ]のRFC3564Requirements、デフServ意識する、Te2003年7月

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2003).  All Rights Reserved.

Copyright(C)インターネット協会(2003)。 All rights reserved。

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部広げられた実現を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsの過程で定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

上に承諾された限られた許容は、永久であり、インターネット協会、後継者または案配によって取り消されないでしょう。

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントとそして、「そのままで」という基礎とインターネットの振興発展を目的とする組織に、インターネット・エンジニアリング・タスク・フォースが速達の、または、暗示しているすべての保証を放棄するかどうかというここにことであり、他を含んでいて、含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Le Faucheur & Lai            Informational                     [Page 22]

Le FaucheurとレイInformationalです。[22ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

SUBSTRING関数 文字列を部分的に抽出する

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る