RFC3260 日本語訳

Network Working Group                                        D. Grossman
Request for Comments: 3260                                Motorola, Inc.
Updates: 2474, 2475, 2597                                     April 2002
Category: Informational

コメントを求めるワーキンググループD.グロースマン要求をネットワークでつないでください: 3260のモトローラアップデート: 2475、2597 2474、年2002年4月のカテゴリ: 情報

            New Terminology and Clarifications for Diffserv

Diffservのための新しい用語と明確化

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 (2002).  All Rights Reserved.

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

Abstract

要約

   This memo captures Diffserv working group agreements concerning new
   and improved terminology, and provides minor technical
   clarifications.  It is intended to update RFC 2474, RFC 2475 and RFC
   2597.  When RFCs 2474 and 2597 advance on the standards track, and
   RFC 2475 is updated, it is intended that the revisions in this memo
   will be incorporated, and that this memo will be obsoleted by the new
   RFCs.

このメモは、新しくて改良された用語に関してDiffservワーキンググループ協定を得て、小さい方の技術的な明確化を提供します。 RFC2474、RFC2475、およびRFC2597をアップデートするのは意図しています。 RFCs2474と2597が標準化過程の上を進んで、RFC2475をアップデートするとき、このメモにおける改正が法人組織になって、このメモが新しいRFCsによって時代遅れにされることを意図します。

1.  Introduction

1. 序論

   As the Diffserv work has evolved, there have been several cases where
   terminology has needed to be created or the definitions in Diffserv
   standards track RFCs have needed to be refined.  Some minor technical
   clarifications were also found to be needed.  This memo was created
   to capture group agreements, rather than attempting to revise the
   base RFCs and recycle them at proposed standard.  It updates in part
   RFC 2474, RFC 2475 and RFC 2597.  RFC 2598 has been obsoleted by RFC
   3246, and clarifications agreed by the group were incorporated in
   that revision.

Diffserv仕事が発展したとき、数個のケースが用語が、作成される必要があったか、またはDiffserv標準化過程RFCsとの定義が精製される必要があったところにありました。 また、いくつかの小さい方の技術的な明確化が必要であることがわかりました。 このメモは、ベースRFCsを改訂して、提案された標準で彼らを再生するのを試みるよりむしろグループ協定を得るために作成されました。 それはRFC2474、RFC2475、およびRFC2597を一部アップデートします。 RFC2598はRFC3246によって時代遅れにされました、そして、グループによって同意された明確化はその改正で組み込んでいました。

2. Terminology Related to Service Level Agreements (SLAs)

2. サービス・レベル・アグリーメントに関連する用語(SLA)

   The Diffserv Architecture [2] uses the term "Service Level Agreement"
   (SLA) to describe the "service contract... that specifies the
   forwarding service a customer should receive".  The SLA may include
   traffic conditioning rules which (at least in part) constitute a
   Traffic Conditioning Agreement (TCA).  A TCA is "an agreement

Diffserv Architecture[2]は「顧客が受けるべきである推進サービスを指定する役務契約…」について説明する「サービスレベル協定」(SLA)という用語を使用します。 SLAはTraffic Conditioning Agreement(TCA)を構成する(少なくとも一部)交通調節規則を含めるかもしれません。 TCAは「協定」です。

Grossman                     Informational                      [Page 1]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[1ページ]のRFC3260の新しいTerminologyと明確化

   specifying classifier rules and any corresponding traffic profiles
   and metering, marking, discarding and/or shaping rules which are to
   apply...."

「適用することである規則を、クラシファイア規則とどんな対応する交通プロフィールも指定して、計量して、マークして、捨てる、そして/または、形成します」…

   As work progressed in Diffserv (as well as in the Policy WG [6]), it
   came to be believed that the notion of an "agreement" implied
   considerations that were of a pricing, contractual or other business
   nature, as well as those that were strictly technical.  There also
   could be other technical considerations in such an agreement (e.g.,
   service availability) which are not addressed by Diffserv.  It was
   therefore agreed that the notions of SLAs and TCAs would be taken to
   represent the broader context, and that new terminology would be used
   to describe those elements of service and traffic conditioning that
   are addressed by Diffserv.

仕事はDiffservに進歩しました。(また、「協定」の概念が価格設定のものであった問題を含意したのはPolicy WG[6])のように信じられるようになりました、契約的であるか他のビジネス自然、厳密に技術的であったものと同様に。 また、そのような合意(例えば、サービスの有用性)におけるDiffservによって記述されない他の技術的な問題があるかもしれません。 したがって、より広い文脈を表すためにSLAとTCAsの概念を取って、Diffservによって記述されるサービスと交通調節のそれらの要素について説明するのに新しい用語を使用するのに同意されました。

      -  A Service Level Specification (SLS) is a set of parameters and
         their values which together define the service offered to a
         traffic stream by a DS domain.

- Service Level Specification(SLS)がaである、設定されて、パラメタとそれらの値について、どれがDSドメインによって交通の流れに提供されたサービスを一緒に定義しますか?

      -  A Traffic Conditioning Specification (TCS) is a set of
         parameters and their values which together specify a set of
         classifier rules and a traffic profile.  A TCS is an integral
         element of an SLS.

- Traffic Conditioning Specification(TCS)がaである、設定されて、パラメタとそれらの値について、どれが1セットのクラシファイア規則と交通プロフィールを一緒に指定しますか? TCSはSLSの不可欠の要素です。

   Note that the definition of "Traffic stream" is unchanged from RFC
   2475.  A traffic stream can be an individual microflow or a group of
   microflows (i.e., in a source or destination DS domain) or it can be
   a BA.  Thus, an SLS may apply in the source or destination DS domain
   to a single microflow or group of microflows, as well as to a BA in
   any DS domain.

「交通の流れ」の定義がRFC2475から変わりがないことに注意してください。 交通の流れは、microflows(すなわち、ソースか目的地DSドメインの)の個々のmicroflowかグループであるかもしれませんかそれがBAであるかもしれません。 したがって、SLSはソースか目的地DSドメインでmicroflowsの単一のmicroflowかグループに適用するかもしれません、よくどんなDSドメインのBAのようにも。

   Also note that the definition of a "Service Provisioning Policy" is
   unchanged from RFC 2475.  RFC 2475 defines a "Service Provisioning
   Policy as "a policy which defines how traffic conditioners are
   configured on DS boundary nodes and how traffic streams are mapped to
   DS behavior aggregates to achieve a range of services."  According to
   one definition given in RFC 3198 [6], a policy is "...a set of rules
   to administer, manage, and control access to network resources".
   Therefore, the relationship between an SLS and a service provisioning
   policy is that the latter is, in part, the set of rules that express
   the parameters and range of values that may be in the former.

また、「サービス食糧を供給する方針」の定義がRFC2475から変わりがないことに注意してください。 RFC2475は「「交通コンディショナーがDS境界ノードの上でどのように構成されるか、そして、交通の流れがどのようにDSの振舞いに写像されるかを定義する方針はさまざまなサービスを達成するために集める」としてのサービスProvisioning Policy」を定義します。 「RFC3198[6]で与えられた1つの定義に従って、方針はそうです」…「ネットワーク資源へのアクセスを管理して、管理して、制御する規則のセット。」 したがって、SLSと方針に食糧を供給するサービスとの関係は後者が一部、前者にはあるかもしれない値のパラメタと範囲を言い表す規則のセットであるということです。

   Further note that this definition is more restrictive than that in
   RFC 3198.

この定義がRFC3198のそれより制限していることにさらに注意してください。

Grossman                     Informational                      [Page 2]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[2ページ]のRFC3260の新しいTerminologyと明確化

3. Usage of PHB Group

3. PHBグループの用法

   RFC 2475 defines a Per-hop behavior (PHB) group to be:

RFC2475は、である:なるようにPer-ホップの振舞い(PHB)グループを定義します。

      "a set of one or more PHBs that can only be meaningfully specified
      and implemented simultaneously, due to a common constraint
      applying to all PHBs in the set such as a queue servicing or queue
      management policy.  A PHB group provides a service building block
      that allows a set of related forwarding behaviors to be specified
      together (e.g., four dropping priorities).  A single PHB is a
      special case of a PHB group."

「同時にセットにおける、待ち行列整備点検か待ち行列経営政策などのすべてのPHBsに適用される一般的な規制のため意味深長に指定して、実行できない1PHBsのしか1セット。」 PHBグループは1セットの関連する推進の振舞いが一緒に指定されるのを許容するサービスブロック(例えば、4つの低下プライオリティ)を提供します。 「独身のPHBはPHBグループの特別なケースです。」

   One standards track PHB Group is defined in RFC 2597 [3], "Assured
   Forwarding PHB Group".  Assured Forwarding (AF) is a type of
   forwarding behavior with some assigned level of queuing resources and
   three drop precedences.  An AF PHB Group consists of three PHBs, and
   uses three Diffserv Codepoints (DSCPs).

1台の標準化過程のPHB GroupはRFC2597[3]、「相対的優先転送PHBは分類すること」において定義されます。 Forwarding(AF)が保証されているのは、列を作りのレベルが割り当てられるいくつかでの振舞いにリソースを送って、3低下に先行を送るタイプです。 AF PHB Groupは3PHBsから成って、3Diffserv Codepoints(DSCPs)を使用します。

   RFC 2597 defines twelve DSCPs, corresponding to four independent AF
   classes.  The AF classes are referred to as AF1x, AF2x, AF3x, and
   AF4x (where 'x' is 1, 2, or 3 to represent drop precedence).  Each AF
   class is one instance of an AF PHB Group.

4つの独立しているAFのクラスに対応している、RFC2597は12DSCPsを定義します。 AFのクラスはAF1x、AF2x、AF3x、およびAF4x('x'が低下先行を表す1、2、または3であるところ)と呼ばれます。 それぞれのAFのクラスはAF PHB Groupの1つの例です。

   There has been confusion expressed that RFC 2597 refers to all four
   AF classes with their three drop precedences as being part of a
   single PHB Group.  However, since each AF class operates entirely
   independently of the others, (and thus there is no common constraint
   among AF classes as there is among drop precedences within an AF
   class) this usage is inconsistent with RFC 2475.  The inconsistency
   exists for historical reasons and will be removed in future revisions
   of the AF specification.  It should now be understood that AF is a
   _type_ of PHB group, and each AF class is an _instance_ of the AF
   type.

存在としての先行が分けるそれらの独身のPHB Groupの3低下に伴うすべての4つのAFのクラスにはRFC2597が参照する言い表された混乱がありました。 しかしながら、それぞれのAFのクラスが完全に他のものの如何にかかわらず作動するので、この(その結果、AFのクラスが中に低下先行の中にあるとき、どんな一般的な規制もAFのクラスにありません)用法はRFC2475に矛盾しています。 矛盾は歴史的な理由で存在していて、AF仕様の今後の改正で取り除くでしょう。 現在、AFがPHBグループの_タイプ_であることが理解されるべきであり、それぞれのAFのクラスはAFタイプの_例の_です。

   Authors of new PHB specifications should be careful to adhere to the
   RFC 2475 definition of PHB Group.  RFC 2475 does not prohibit new PHB
   specifications from assigning enough DSCPs to represent multiple
   independent instances of their PHB Group.  However, such a set of
   DSCPs must not be referred to as a single PHB Group.

新しいPHB仕様の作者はPHB GroupのRFC2475定義を固く守るのに慎重であるはずです。 RFC2475は、新しいPHB仕様がそれらのPHB Groupの複数の独立している例を表すことができるくらいのDSCPsを割り当てるのを禁止しません。 しかしながら、DSCPsのそのような1セットを独身のPHB Groupと呼んではいけません。

4. Definition of the DS Field

4. DS分野の定義

   Diffserv uses six bits of the IPV4 or IPV6 header to convey the
   Diffserv Codepoint (DSCP), which selects a PHB.  RFC 2474 attempts to
   rename the TOS octet of the IPV4 header, and Traffic Class octet of
   the IPV6 header, respectively, to the DS field.  The DS Field has a
   six bit Diffserv Codepoint and two "currently unused" bits.

Diffservは、Diffserv Codepoint(DSCP)を運ぶのにIPV4かIPV6ヘッダーの6ビットを使用します。(Diffserv CodepointはPHBを選択します)。 RFC2474は、それぞれIPV4ヘッダーのTOS八重奏、およびIPV6ヘッダーのTraffic Class八重奏をDS分野に改名するのを試みます。 DS Fieldには、6ビットのDiffserv Codepointと「現在未使用」の2ビットがあります。

Grossman                     Informational                      [Page 3]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[3ページ]のRFC3260の新しいTerminologyと明確化

   It has been pointed out that this leads to inconsistencies and
   ambiguities.  In particular, the "Currently Unused" (CU) bits of the
   DS Field have not been assigned to Diffserv, and subsequent to the
   publication of RFC 2474, they were assigned for explicit congestion
   notification, as defined in RFC 3168 [4].  In the current text, a
   DSCP is, depending on context, either an encoding which selects a PHB
   or a sub-field in the DS field which contains that encoding.

これが矛盾とあいまいさに通じると指摘されました。 DS Fieldの「現在未使用」の(CU)ビットが特に、Diffservに割り当てられて、RFC2474の公表にその後でなかった、それらは明白な混雑通知のために割り当てられました、RFC3168[4]で定義されるように。 現在のテキストでは、文脈によって、DSCPはそのコード化を含むPHBを選択するコード化かDSのサブ分野分野です。

   The present text is also inconsistent with BCP 37, IANA Allocation
   Guidelines for Values in the Internet Protocol and Related Headers
   [5].  The IPV4 Type-of-Service (TOS) field and the IPV6 traffic class
   field are superseded by the 6 bit DS field and a 2 bit CU field.  The
   IANA allocates values in the DS field following the IANA
   considerations section in RFC 2474, as clarified in section 8 of this
   memo.

また、現在のテキストもBCP37、インターネットプロトコルと関連Headers[5]のValuesのためのIANA Allocation Guidelinesに矛盾しています。 サービスのIPV4 Type(TOS)分野とIPV6交通類体は6ビットのDS分野と2ビットのCU分野によって取って代わられます。 RFC2474のIANA問題部に続いて、IANAはDS分野に値を割り当てます、このメモのセクション8ではっきりさせられるように。

   The consensus of the DiffServ working group is that BCP 37 correctly
   restates the structure of the former TOS and traffic class fields.

DiffServワーキンググループのコンセンサスはBCP37が正しく元TOSと交通類体の構造を言い直すということです。

   Therefore, for use in future documents, including the next update to
   RFC 2474, the following definitions should apply:

したがって、将来のドキュメントにおける使用のためにRFC2474に次のアップデートを含めて、以下の定義は適用されるべきです:

      -  the Differentiated Services Field (DSField) is the six most
         significant bits of the (former) IPV4 TOS octet or the (former)
         IPV6 Traffic Class octet.

- Differentiated Services Field(DSField)は(旧)IPV4 TOS八重奏か(旧)IPV6 Traffic Class八重奏の6つの最上位ビットです。

      -  the Differentiated Services Codepoint (DSCP) is a value which
         is encoded in the DS field, and which each DS Node MUST use to
         select the PHB which is to be experienced by each packet it
         forwards.

- Differentiated Services Codepoint(DSCP)はDS分野でコード化されて、各DS Nodeがそれが進める各パケットによって経験されることになっているPHBを選択するのに使用しなければならない値です。

   The two least significant bits of the IPV4 TOS octet and the IPV6
   Traffic Class octet are not used by Diffserv.

IPV4 TOS八重奏とIPV6 Traffic Class八重奏の2つの最下位ビットはDiffservによって使用されません。

   When RFC 2474 is updated, consideration should be given to changing
   the designation "currently unused (CU)" to "explicit congestion
   notification (ECN)" and referencing RFC 3168 (or its successor).

RFC2474をアップデートするとき、名称を「明白な混雑通知(電子証券取引ネットワーク)」に「現在、未使用(CU)」で変えて、RFC3168(または、後継者)に参照をつけることに対して考慮を払うべきです。

   The update should also reference BCP 37.

アップデートは参照BCP37もそうするべきです。

5. Ordered Aggregates and PHB Scheduling Classes

5. 規則正しい集合とPHBスケジューリングのクラス

   Work on Diffserv support by MPLS Label Switched Routers (LSRs) led to
   the realization that a concept was needed in Diffserv to capture the
   notion of a set of BAs with a common ordering constraint.  This
   presently applies to AF behavior aggregates, since a DS node may not
   reorder packets of the same microflow if they belong to the same AF
   class.  This would, for example, prevent an MPLS LSR, which was also

MPLS Label Switched Routers(LSRs)によるDiffservサポートに対する仕事は概念が一般的な注文規制でBAsの1セットの概念を得るのにDiffservで必要であったという認識につながりました。 同じAFのクラスのものなら、これは現在、同じmicroflowの追加注文パケットではなく、DSノード以来の集合がそうするAFの振舞いに適用されます。 例えば、これはMPLS LSRを防ぐでしょう。

Grossman                     Informational                      [Page 4]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[4ページ]のRFC3260の新しいTerminologyと明確化

   a DS node, from discriminating between packets of an AF Behavior
   Aggregate (BA) based on drop precedence and forwarding packets of the
   same AF class but different drop precedence over different LSPs.  The
   following new terms are defined.

低下先行に基づいていて、同じAFのクラスにもかかわらず、異なった低下先行のパケットを異なったLSPsの上に送りながらAF Behavior Aggregate(BA)のパケットを区別するのからのDSノード。 次の新学期は定義されます。

      PHB Scheduling Class: 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スケジューリングのクラス: 一般的な規制がそれであるPHBグループ、少なくとも同じmicroflowに属すそれらのパケットの注文を保存しなければなりません。

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

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

6. Unknown/Improperly Mapped DSCPs

6. 未知/は不適切にDSCPsを写像しました。

   Several implementors have pointed out ambiguities or conflicts in the
   Diffserv RFCs concerning behavior when a DS-node receives a packet
   with a DSCP which it does not understand.

数人の作成者が、DS-ノードがそれがするDSCPと共にパケットを受けるときの振舞いに関するDiffserv RFCsでのあいまいさか闘争が分からないと指摘しました。

   RFC 2475 states:
      "Ingress nodes must condition all other inbound traffic to ensure
      that the DS codepoints are acceptable; packets found to have
      unacceptable codepoints must either be discarded or must have
      their DS codepoints modified to acceptable values before being
      forwarded.  For example, an ingress node receiving traffic from a
      domain with which no enhanced service agreement exists may reset
      the DS codepoint to the Default PHB codepoint [DSFIELD]."

RFC2475州: 「イングレスノードは、DS codepointsが許容できるのを保証するように他のすべてのインバウンドトラフィックを条件としなければなりません」。 容認できないcodepointsを持つために見つけられたパケットで、進める前に、捨てなければならないか、またはそれらのDS codepointsを許容値に変更しなければなりません。 「例えば、高度サービス協定が全く存在しないドメインからの交通を受けるイングレスノードはDefault PHB codepoint[DSFIELD]にDS codepointをリセットするかもしれません。」

   On the other hand, RFC 2474 states:
      "Packets received with an unrecognized codepoint SHOULD be
      forwarded as if they were marked for the Default behavior (see
      Sec. 4), and their codepoints should not be changed."

他方では、RFC2474は以下を述べます。 「まるでそれらがDefaultの振舞いのためにマークされるかのように認識されていないcodepoint SHOULDを進めていて受け取られたパケット」(Secを見てください。 4), 「そして、それらのcodepointsを変えるべきではありません。」

   RFC 2474 is principally concerned with DS-interior nodes.  However,
   this behavior could also be performed in DS-ingress nodes AFTER the
   traffic conditioning required by RFC 2475 (in which case, an
   unrecognized DSCP would occur only in the case of misconfiguration).
   If a packet arrives with a DSCP that hadn't been explicitly mapped to
   a particular PHB, it should be treated the same way as a packet
   marked for Default.  The alternatives were to assign it another PHB,
   which could result in misallocation of provisioned resources, or to
   drop it.  Those are the only alternatives within the framework of RFC
   2474.  Neither alternative was considered desirable.  There has been
   discussion of a PHB which receives worse service than the default;
   this might be a better alternative.  Hence the imperative was
   "SHOULD" rather than "SHALL".

RFC2474は主にDS内部のノードに関係があります。 しかしながら、また、この振舞いはDS-イングレスノードAFTERで実行されて、交通調節がRFC2475が必要であるという(その場合、認識されていないDSCPはmisconfigurationの場合だけで起こるでしょう)ことであるかもしれません。 パケットが明らかに特定のPHBに写像されていなかったDSCPと共に到着するなら、それは同じようにDefaultのためにマークされたパケットとして扱われるべきです。 選択肢は、別のPHBをそれに割り当てるか、またはそれを落とすことでした。(PHBは食糧を供給されたリソースの不適正配分をもたらすことができました)。 それらはRFC2474の枠組みの中の唯一の選択肢です。 どちらの選択肢も望ましいのは考えられませんでした。 デフォルトより悪いサービスを受けるPHBの議論がありました。 これは、より良い代替手段であるかもしれません。 したがって、命令は“SHALL"よりむしろ“SHOULD"でした。

Grossman                     Informational                      [Page 5]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[5ページ]のRFC3260の新しいTerminologyと明確化

   The intent of RFC 2475 clearly concerns DS-ingress nodes, or more
   precisely, the ingress traffic conditioning function.  This is
   another context where the "SHOULD" in RFC 2474 provides the
   flexibility to do what the group intended.  Such tortured readings
   are not desirable.

イングレス交通が機能を条件とさせて、RFC2475の意図は明確により正確にDS-イングレスノードに関係があります。 これはRFC2474の“SHOULD"がグループが意図したことをするために柔軟性を提供する別の文脈です。 そのような拷問された読書は望ましくはありません。

   Therefore, the statement in RFC 2474 will be clarified to indicate
   that it is not intended to apply at the ingress traffic conditioning
   function at a DS-ingress node, and cross reference RFC 2475 for that
   case.

したがって、RFC2474での声明は、そのような場合DS-イングレスノード、および相互参照RFC2475でイングレス交通調節機能で適用することを意図しないのを示すためにはっきりさせられるでしょう。

   There was a similar issue, which manifested itself with the first
   incarnation of Expedited Forwarding (EF).  RFC 2598 states:

同様の問題がありました。(それは、Expedited Forwarding(EF)の最初の肉体化と共に現れました)。 RFC2598州:

      To protect itself against denial of service attacks, the edge of a
      DS domain MUST strictly police all EF marked packets to a rate
      negotiated with the adjacent upstream domain.  (This rate must be
      <= the EF PHB configured rate.)  Packets in excess of the
      negotiated rate MUST be dropped.  If two adjacent domains have not
      negotiated an EF rate, the downstream domain MUST use 0 as the
      rate (i.e., drop all EF marked packets).

サービス不能攻撃に対して我が身をかばうために、DSドメインの縁は厳密に隣接している上流のドメインと交渉されたレートまでパケットであるとマークされたすべてのEFを取り締まらなければなりません。 (このレートは<=EF PHBがレートを構成したということであるに違いありません。) 交渉されたレートを超えたパケットを落とさなければなりません。 2つの隣接しているドメインがEFレートを交渉していないなら、川下のドメインはレートとして0を使用しなければなりません(すなわち、パケットであるとマークされたすべてのEFを落としてください)。

   The problem arose in the case of misconfiguration or routing
   problems.  An egress DS-node at the edge of one DS-domain forwards
   packets to an ingress DS-node at the edge of another DS domain.
   These packets are marked with a DSCP that the egress node understands
   to map to EF, but which the ingress node does not recognize.  The
   statement in RFC 2475 would appear to apply to this case.  RFC 3246
   [7] clarifies this point.

問題はmisconfigurationかルーティング問題の場合で起こりました。1つのDS-ドメインの縁の出口DS-ノードは別のDSドメインの縁のイングレスDS-ノードにパケットを送ります。 これらのパケットはEFに写像するために出口ノードが理解しているDSCPと共にマークされますが、イングレスノードは認識しません。 RFC2475での声明は本件に適用するように見えるでしょう。 RFC3246[7]はこのポイントをはっきりさせます。

7. No Backward Compatibility With RFC 1349

7. RFC1349との後方の互換性がありません。

   At least one implementor has expressed confusion about the
   relationship of the DSField, as defined in RFC 2474, to the use of
   the TOS bits, as described in RFC 1349.  The RFC 1349 usage was
   intended to interact with OSPF extensions in RFC 1247.  These were
   never widely deployed and thus removed by standards action when STD
   54, RFC 2328, was published.  The processing of the TOS bits is
   described as a requirement in RFC 1812 [8], RFC 1122 [9] and RFC 1123
   [10].  RFC 2474 states:

少なくとも1人の作成者がDSFieldの関係に関して混乱を言い表しました、RFC2474で定義されるように、TOSビットの使用に、RFC1349で説明されるように。 RFC1349用法がRFC1247でOSPF拡張子と対話することを意図しました。 STD54(RFC2328)が発行されたとき、これらは、広く決して配備されないで、その結果、規格動作で取り外されました。 TOSビットの処理はRFC1812[8]、RFC1122[9]、およびRFC1123[10]で要件として記述されています。 RFC2474州:

      "No attempt is made to maintain backwards compatibility with the
      "DTR" or TOS bits of the IPv4 TOS octet, as defined in [RFC791].",

「後方にIPv4 TOS八重奏の"DTR"かTOSビットとの互換性を維持するのを試みを全くしません、[RFC791]で定義されるように。」

Grossman                     Informational                      [Page 6]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[6ページ]のRFC3260の新しいTerminologyと明確化

   In addition, RFC 2474 obsoletes RFC 1349 by IESG action.  For
   completeness, when RFC 2474 is updated, the sentence should read:

さらに、RFC2474はIESG動作でRFC1349を時代遅れにします。 RFC2474をアップデートするとき、完全性のために、文は読むべきです:

      "No attempt is made to maintain backwards compatibility with the
      "DTR/MBZ" or TOS bits of the IPv4 TOS octet, as defined in
      [RFC791] and [RFC1349].  This implies that TOS bit processing as
      described in [RFC1812], [RFC1122] and [RFC1123] is also obsoleted
      by this memo.  Also see [RFC2780]."

「後方にIPv4 TOS八重奏の"DTR/MBZ"かTOSビットとの互換性を維持するのを試みを全くしません、[RFC791]と[RFC1349]で定義されるように。」 これは、また、[RFC1812]、[RFC1122]、および[RFC1123]で説明されるように処理されるTOSビットがこのメモで時代遅れにされるのを含意します。 「また、[RFC2780]を見てください。」

8. IANA Considerations

8. IANA問題

   IANA has requested clarification of a point in RFC 2474, concerning
   registration of experimental/local use DSCPs.  When RFC 2474 is
   revised, the following should be added to Section 6:

IANAはRFC2474でのポイントの明確化を要求して、実験的であるか地方の登録に関して、DSCPsを使用してください。 RFC2474が改訂されているとき、以下はセクション6に追加されるべきです:

      IANA is requested to maintain a registry of RECOMMENDED DSCP
      values assigned by standards action.  EXP/LU values are not to be
      registered.

IANAが規格動作で割り当てられたRECOMMENDED DSCP値の登録を維持するよう要求されています。 EXP/LU値は登録されていないことです。

9. Summary of Pending Changes

9. 未定の変化の概要

   The following standards track and informational RFCs are expected to
   be updated to reflect the agreements captured in this memo.  It is
   intended that these updates occur when each standards track RFC
   progresses to Draft Standard (or if some issue arises that forces
   recycling at Proposed).  RFC 2475 is expected to be updated at about
   the same time as RFC 2474.  Those updates will also obsolete this
   memo.

以下の標準化過程と情報のRFCsがこのメモで得られた協定を反映するためにアップデートすると予想されます。 各標準化過程RFCがDraft Standardに進んでいると(何らかの問題が起こるなら、それはProposedで再生を強制します)これらのアップデートが起こることを意図します。 RFC2475がRFC2474とほぼ同じくらいの時にアップデートすると予想されます。 また、それらのアップデートはこのメモを時代遅れにするでしょう。

      RFC 2474: revise definition of DS field.  Clarify that the
      suggested default forwarding in the event of an unrecognized DSCP
      is not intended to apply to ingress conditioning in DS-ingress
      nodes.  Clarify effects on RFC 1349 and RFC 1812.  Clarify that
      only RECOMMENDED DSCPs assigned by standards action are to be
      registered by IANA.

RFC2474: DS分野の定義を改訂してください。 はっきりさせてください。提案されたデフォルト推進は認識されていないDSCPの場合、DS-イングレスノードにおけるイングレス調節に適用しないつもりです。 RFC1349とRFC1812への効果をはっきりさせてください。 登録されていて、動作がIANAである規格によって割り当てられたその唯一のRECOMMENDED DSCPsをはっきりさせてください。

      RFC 2475: revise definition of DS field.  Add SLS and TCS
      definitions.  Update body of document to use SLS and TCS
      appropriately.  Add definitions of PHB scheduling class and
      ordered aggregate.

RFC2475: DS分野の定義を改訂してください。 SLSとTCS定義を加えてください。 ドキュメントのボディーをアップデートして、適切にSLSとTCSを使用してください。 PHBスケジューリングのクラスと規則正しい集合の定義を加えてください。

      RFC 2497: revise to reflect understanding that, AF classes are
      instances of the AF PHB group, and are not collectively a PHB
      group.

RFC2497: それを理解しながら反射する改正、AF PHBの例が分類されるということであり、AFのクラスはPHBがまとめて、分類するということではありません。

Grossman                     Informational                      [Page 7]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[7ページ]のRFC3260の新しいTerminologyと明確化

   In addition, RFC 3246 [7] has added a reference to RFC 2475 in the
   security considerations section to cover the case of a DS egress node
   receiving an unrecognized DSCP which maps to EF in the DS ingress
   node.

さらに、RFC3246[7]は、DS出口ノードに関するケースをカバーするためにDSイングレスノードを中のEFに写像する認識されていないDSCPを受けながら、セキュリティ問題部でRFC2475の参照を加えました。

10. Security Considerations

10. セキュリティ問題

   Security considerations are addressed in RFC 2475.

セキュリティ問題はRFC2475に記述されます。

Acknowledgements

承認

   This memo captures agreements of the Diffserv working group.  Many
   individuals contributed to the discussions on the Diffserv list and
   in the meetings.  The Diffserv chairs were Brian Carpenter and Kathie
   Nichols.  Among many who participated actively in these discussions
   were Lloyd Wood, Juha Heinanen, Grenville Armitage, Scott Brim,
   Sharam Davari, David Black, Gerard Gastaud, Joel Halpern, John
   Schnizlein, Francois Le Faucheur, and Fred Baker.  Mike Ayers, Mike
   Heard and Andrea Westerinen provided valuable editorial comments.

このメモはDiffservワーキンググループの協定を得ます。 多くの個人がDiffservリストにおける議論とミーティングで貢献しました。 Diffservいすは、ブライアンCarpenterとキャシー・ニコルズでした。 これらの議論で活躍した多くの中に、ユハHeinanen、グレンビルのロイドWood、アーミテージ、スコットBrim、Sharam Davari、デヴィッドBlack、ジェラードGastaud、ジョエル・アルペルン、ジョンSchnizlein、フランソアLe Faucheur、およびフレッド・ベイカーはいました。 マイク・エアーズ、マイクHeard、およびアンドレアWesterinenは貴重な編集のコメントを提供しました。

Normative References

引用規格

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

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

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

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

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

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

   [4]  Ramakrishnan, K., Floyd, S. and D. Black "The Addition of
        Explicit Congestion Notification (ECN) to IP", RFC 3168,
        September 2001.

[4]はRamakrishnanします、K.、フロイド、S.、D.黒は「明白な混雑通知(電子証券取引ネットワーク)のIPへの追加」をS.です、RFC3168、2001年9月。

   [5]  Bradner, S. and V. Paxon, "IANA Allocation Guidelines for Values
        in the Internet Protocol and Related Headers", BCP 37, RFC2780,
        March 2000.

[5] ブラドナー、S.、および「インターネットプロトコルと関連ヘッダーの値のためのIANA配分ガイドライン」、BCP37、RFC2780(2000年3月)対Paxon

   [6]  Westerinen, A., Schnizlein, J., Strassner, J., Scherling, M.,
        Quinn, B., Herzog, S., Huynh, A., Carlson, M., Perry, J. and S.
        Waldbusser, "Terminology for Policy-Based Management", RFC 3198,
        November 2001.

[6]WesterinenとA.とSchnizleinとJ.とStrassnerとJ.とScherlingとM.、クインとB.とハーツォグとS.とHuynhとA.とカールソンとM.とペリーとJ.とS.Waldbusser、「方針を拠点とする管理のための用語」RFC3198(2001年11月)。

Grossman                     Informational                      [Page 8]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[8ページ]のRFC3260の新しいTerminologyと明確化

   [7]  Davie, B., Charny, A., Baker, F., Bennett, J.C.R., Benson, K.,
        Le Boudec, J., Chiu, A., Courtney, W., Cavari, S., Firoiu, V.,
        Kalmanek, C., Ramakrishnam, K. and D. Stiliadis, "An Expedited
        Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.

[7] デイビーとB.とシャルニーとA.とベイカーとF.とベネットとJ.C.R.とベンソンとK.とLe BoudecとJ.とチウとA.とコートニーとW.とCavariとS.とFiroiuとV.とKalmanekとC.とRamakrishnamとK.と2002年のD.Stiliadis、「完全優先転送PHB(1ホップあたりの振舞い)」、RFC3246行進。

   [8]  Baker, F., "Requirements for IP Version 4 Routers", RFC 1812,
        June 1995.

[8] ベイカー、F.、「IPバージョン4ルータのための要件」、RFC1812、1995年6月。

   [9]  Braden, R., "Requirements for Internet Hosts -- Communications
        Layers", STD 3, RFC 1122, October 1989.

[9] ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日

   [10] Braden, R., "Requirements for Internet Hosts -- Application and
        Support", STD 3, RFC 1123, October 1989.

[10] ブレーデン、R.、「インターネットホストのための要件--、アプリケーションとサポート、」、STD3、RFC1123、10月1989日

Author's Address

作者のアドレス

   Dan Grossman
   Motorola, Inc.
   20 Cabot Blvd.
   Mansfield, MA 02048

ダングロースマンモトローラ20カボーBlvd. マンスフィールド、MA 02048

   EMail: dan@dma.isg.mot.com

メール: dan@dma.isg.mot.com

Grossman                     Informational                      [Page 9]

RFC 3260    New Terminology and Clarifications for Diffserv   April 2002

Diffserv2002年4月のためのグロースマン情報[9ページ]のRFC3260の新しいTerminologyと明確化

Full Copyright Statement

完全な著作権宣言文

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

Copyright(C)インターネット協会(2002)。 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機能のための基金は現在、インターネット協会によって提供されます。

Grossman                     Informational                     [Page 10]

グロースマンInformationalです。[10ページ]