RFC2836 日本語訳
2836 Per Hop Behavior Identification Codes. S. Brim, B. Carpenter, F.Le Faucheur. May 2000. (Format: TXT=13399 bytes) (Obsoleted by RFC3140) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Brim
Request for Comments: 2836 B. Carpenter
Category: Standards Track F. Le Faucheur
May 2000
コメントを求めるワーキンググループS.縁の要求をネットワークでつないでください: 2836年のB.大工カテゴリ: 標準化過程F.Le Faucheur2000年5月
Per Hop Behavior Identification Codes
ホップ振舞い識別コード単位で
Status of this Memo
このMemoの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 All rights reserved。
Table of Contents:
目次:
1. Introduction................................................. 1 1.1. Usage Scenarios............................................ 2 2. Encoding..................................................... 3 3. IANA Considerations.......................................... 4 4. Security considerations...................................... 4 References...................................................... 4 Authors' Addresses.............................................. 5 Intellectual Property........................................... 6 Full Copyright Statement........................................ 7
1. 序論… 1 1.1. 用法シナリオ… 2 2. コード化します。 3 3. IANA問題… 4 4. セキュリティ問題… 4つの参照箇所… 4人の作者のアドレス… 5知的所有権… 6 完全な著作権宣言文… 7
1. Introduction
1. 序論
Differentiated Services [RFC 2474, RFC 2475] introduces the notion of Per Hop Behaviors (PHBs) that define how traffic belonging to a particular behavior aggregate is treated at an individual network node. In IP packet headers, PHBs are not indicated as such; instead Differentiated Services Codepoint (DSCP) values are used. There are only 64 possible DSCP values, but there is no such limit on the number of PHBs. In a given network domain, there is a locally defined mapping between DSCP values and PHBs. Standardized PHBs recommend a DSCP mapping, but network operators may choose alternative mappings.
微分されたServices[RFC2474、RFC2475]は特定の振舞い集合に属す交通が個々のネットワーク・ノードでどう扱われるかを定義するPer Hop Behaviors(PHBs)の概念を紹介します。 IPパケットのヘッダーでは、PHBsはそういうものとして示されません。 代わりに、Differentiated Services Codepoint(DSCP)値は使用されています。 64の可能なDSCP値しかありませんが、どんなそのような限界もPHBsの数にありません。 与えられたネットワークドメインに、DSCP値とPHBsの間には、局所的に定義されたマッピングがあります。 標準化されたPHBsはDSCPマッピングを推薦しますが、ネットワーク・オペレータは代替のマッピングを選ぶかもしれません。
Brim, et al. Standards Track [Page 1] RFC 2836 Per Hop Behavior Identification Codes May 2000
縁、他 規格は2000年5月にホップ振舞い識別コードあたりのRFC2836を追跡します[1ページ]。
In some cases it is necessary or desirable to identify a particular PHB in a protocol message, such as a message negotiating bandwidth management or path selection, especially when such messages pass between management domains. Examples where work is in progress include communication between bandwidth brokers, and MPLS support of diffserv.
いくつかの場合、メッセージなどのプロトコルメッセージの帯域幅管理か経路選択を交渉する特定のPHBを特定するのは、必要であるか、または望ましいです、特にそのようなメッセージが管理ドメインの間で終わると。 仕事が進行している例は帯域幅ブローカーと、diffservのMPLSサポートとのコミュニケーションを含んでいます。
In certain cases, what needs to be identified is not an individual PHB, but a set of PHBs. One example is a set of PHBs that must follow the same physical path to prevent re-ordering. An instance of this is the set of three PHBs belonging to a single Assured Forwarding class, such as the PHBs AF11, AF12 and AF13 [RFC 2597].
ある場合には、特定される必要があることは個々のPHBではなく、PHBsの1セットです。 1つの例が再注文するのを防ぐために同じ物理的な経路に続かなければならないPHBsの1セットです。 この例は1つのAssured Forwardingのクラスのもの3PHBsのセットです、PHBs AF11や、AF12やAF13[RFC2597]などのように。
This document defines a binary encoding to uniquely identify PHBs and/or sets of PHBs in protocol messages. This encoding MUST be used when such identification is required.
このドキュメントはプロトコルメッセージで唯一PHBsのPHBs、そして/または、セットを特定するためにコード化されるバイナリーを定義します。 そのような識別が必要であるときに、このコード化を使用しなければなりません。
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]で説明されるように本書では解釈されることであるべきですか?
1.1. Usage Scenarios
1.1. 用法シナリオ
Diffserv services are expected to be supported over various underlying technologies which we broadly refer to as "link layers" for the purpose of this discussion. For the transport of IP packets, some of these link layers make use of connections or logical connections where the forwarding behavior supported by each link layer device is a property of the connection. In particular, within the link layer domain, each link layer node will schedule traffic depending on which connection the traffic is transported in. Examples of such "link layers" include ATM and MPLS.
私たちがこの議論の目的のために「リンクレイヤ」を広く呼ぶ様々な基本的な技術の上でDiffservサービスが支持されると予想されます。 IPパケットの輸送のために、これらのいくつかのリンクレイヤがそれぞれのリンクレイヤ装置で後押しされている推進の振舞いが接続の所有地であるところで接続か論理的な接続を利用します。 特に、リンクレイヤドメインの中では、それぞれのリンクレイヤノードは交通がどの接続に輸送されるかによる交通の計画をするでしょう。 そのような「リンクレイヤ」に関する例はATMとMPLSを含んでいます。
For efficient support of diffserv over these link layers, one model is for different Behavior Aggregates (BAs) (or sets of Behavior Aggregates) to be transported over different connections so that they are granted different (and appropriate) forwarding behaviors inside the link layer cloud. When those connections are dynamically established for the transport of diffserv traffic, it is very useful to communicate at connection establishment time what forwarding behavior(s) is(are) to be granted to each connection by the link layer device so that the BAs transported experience consistent forwarding behavior inside the link layer cloud. This can be achieved by including in the connection establishment signaling messages the encoding of the corresponding PHB, or set of PHBs, as defined in this document. Details on proposed usage of PHB encodings by some MPLS label distribution protocols (RSVP and LDP) for support of Diff-Serv over MPLS, can be found in [MPLS-DS].
これらのリンクレイヤの上のdiffservの効率的なサポートにおいて、1つのモデルは異なった接続の上で異なったBehavior Aggregates(BAs)(または、Behavior Aggregatesのセット)を輸送されることになっているので、異なって(適切)の推進の振舞いはリンクレイヤ雲の中で彼らに承諾されます。 それらの接続がdiffserv交通の輸送のためにダイナミックに確立されるとき、コネクション確立時にリンクレイヤ装置で各接続に与えるために推進の振舞いが何(ある)であるかを伝えるのが非常に役に立つので、輸送されたBAsはリンクレイヤ雲の中で一貫した推進の振舞いを経験します。 コネクション確立シグナリングメッセージでの対応するPHBのコード化、またはPHBsのセットを含んでいることによって、これを達成できます、本書では定義されるように。 MPLSの上のDiff-ServのサポートのためのいくつかのMPLSラベル分配プロトコル(RSVPと自由民主党)によるPHB encodingsの提案された使用法に関する詳細、[MPLS-DS]で見つけることができます。
Brim, et al. Standards Track [Page 2] RFC 2836 Per Hop Behavior Identification Codes May 2000
縁、他 規格は2000年5月にホップ振舞い識別コードあたりのRFC2836を追跡します[2ページ]。
In another approach, the ATM Forum has a requirement to indicate desired IP QOS treatments in ATM signaling, so that ATM switches can be just as supportive of the desired service as are IP forwarders. To do so the Forum is defining a new VC call setup information element is which will carry PHB identification codes (although will be generalized to do more if needed).
別のアプローチでは、ATM ForumはATMシグナリングにおける必要なIP QOS処理を示すという要件を持っています、ATMスイッチがIP混載業者のように必要なサービスをちょうど同じくらい支持するように。 新しいVC呼び出しセットアップ情報要素をForumが定義しているそうにするのは、どれがPHB識別コードを運ぶかということ(意志ですが、必要であるなら一般化されて、それ以上のことをする)です。
2. Encoding
2. コード化
PHBs and sets of PHBs are encoded in an unsigned 16 bit binary field.
PHBsのPHBsとセットは16ビットの無記名の2進の分野でコード化されます。
The 16 bit field is arranged as follows:
16ビットの分野は以下の通りアレンジされます:
Case 1: PHBs defined by standards action, as per [RFC 2474].
ケース1: [RFC2474]に従って規格動作で定義されたPHBs。
The encoding for a single PHB is the recommended DSCP value for that PHB, left-justified in the 16 bit field, with bits 6 through 15 set to zero. Note that the recommended DSCP value MUST be used, even if the network in question has chosen a different mapping.
独身のPHBのためのコード化はそのPHBにおけるお勧めのDSCP値です、16ビットの分野で左で正当です、6〜15がゼロに設定するビットで。 問題のネットワークが異なったマッピングを選んだとしても、お勧めのDSCP値を使用しなければならないことに注意してください。
The encoding for a set of PHBs is the numerically smallest of the set of encodings for the various PHBs in the set, with bit 14 set to 1. (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with bit 14 set to 1.)
様々なPHBsには、encodingsのセットでPHBsの1セットのためのコード化はセットで数の上で最も小さいです、1に設定されたビット14で。 (その結果、AF1x PHBsに関して、コード化は1へのビット14セットがあるAF11 PHBのものです。)
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| DSCP | 0 0 0 0 0 0 0 0 X 0 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | DSCP| 0 0 0 0 0 0 0 0X0| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Case 2: PHBs not defined by standards action, i.e. experimental or local use PHBs as allowed by [RFC 2474]. In this case an arbitrary 12 bit PHB identification code, assigned by the IANA, is placed left- justified in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero.
ケース2: [RFC2474]によって許容されているように規格動作ですなわち、実験的であるか、または地方で定義されなかったPHBsはPHBsを使用します。 この場合、IANAによって割り当てられた12ビットの任意のPHB識別コードは16ビットの分野に左に正当な状態で置かれます。 ビット14は、ビット15は1に設定されて、独身のPHBのためのゼロかPHBsの1セットのための1です。 ビット12と13はゼロです。
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
| PHB id code | 0 0 X 1 |
+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | PHBイドコード| 0 0X1| +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+
Bits 12 and 13 are reserved either for expansion of the PHB identification code, or for other use, at some point in the future.
ビット12と13はPHB識別コードの拡大、または他の使用のために予約されます、未来の何らかのポイントで。
Brim, et al. Standards Track [Page 3] RFC 2836 Per Hop Behavior Identification Codes May 2000
縁、他 規格は2000年5月にホップ振舞い識別コードあたりのRFC2836を追跡します[3ページ]。
3. IANA Considerations
3. IANA問題
IANA is requested to create a new assignment registry for "Per-Hop Behavior Identification Codes", initially allowing values in the range 0 to 4095 decimal.
IANAが「1ホップあたりの振舞い識別コード」のための新しい課題登録を作成するよう要求されています、初めは0〜4095小数を範囲の値に許容して。
Assignment of values in this field require:
この分野の値の課題は以下を必要とします。
-the identity of the assignee
-a brief description of the new PHB, with enough detail to
distinguish it from existing standardized and non-standardized
PHBs. In the case of a set of PHBs, this description should cover
all PHBs in the set.
-a reference to a stable document describing the PHB in detail.
-既存の標準化されて非標準化されたPHBsとそれを区別できるくらいの詳細がある新しいPHBの指定代理人-a簡単な説明のアイデンティティ。 PHBsの1セットの場合では、この記述はセットにおけるすべてのPHBsを覆うべきです。 -詳細にPHBについて説明する安定したドキュメントの参照。
During the first year of existence of this registry, IANA is requested to refer all requests to the IETF diffserv WG for review. Subsequently, requests should be reviewed by the IETF Transport Area Directors or by an expert that they designate.
この登録の存在の初年度の間、IANAがレビューについてすべての要求をIETF diffserv WGを参照するよう要求されています。 次に、要求はIETF Transport Areaディレクターか彼らが任命する専門家によって再検討されるべきです。
If the number of assignments begins to approach 4096, the Transport Area Directors should be alerted.
課題の数が4096にアプローチし始めるなら、Transport Areaディレクターは警告されるべきです。
4. Security Considerations
4. セキュリティ問題
This encoding in itself raises no security issues. However, users of this encoding should consider that modifying a PHB identification code may constitute theft or denial of service, so protocols using this encoding must be adequately protected.
このコード化は本来安全保障問題を全く提起しません。 しかしながら、このコード化のユーザが、PHB識別コードを変更するとサービスの窃盗か否定が構成されるかもしれないと考えるべきであるので、適切にこのコード化を使用するプロトコルを保護しなければなりません。
References
参照
[RFC 2119] 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月。
[RFC 2474] 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.
[RFC2474] ニコルズとK.とブレークとS.、ベイカーとF.とD.黒、「IPv4とIPv6ヘッダーとの微分されたサービス分野(DS分野)の定義」RFC2474(1998年12月)。
[RFC 2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
and W. Weiss, "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2475] ブレークとS.と黒とD.とカールソンとM.とデイヴィースとE.とワングとZ.とW.ウィス、「微分されたサービスのための構造」、RFC2475、1998年12月。
[RFC 2597] Heinanen, J., Baker, F., Weiss, W. and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2597] HeinanenとJ.とベイカーとF.とウィスとW.とJ.Wroclawski、「相対的優先転送PHBは分類する」RFC2597、1999年6月。
Brim, et al. Standards Track [Page 4] RFC 2836 Per Hop Behavior Identification Codes May 2000
縁、他 規格は2000年5月にホップ振舞い識別コードあたりのRFC2836を追跡します[4ページ]。
[MPLS-DS] MPLS Support of Differentiated Services, Francois Le
Faucheur, Liwen Wu, Bruce Davie, Shahram Davari, Pasi
Vaananen, Ram Krishnan, Pierrick Cheval, Juha Heinanen,
Work in Progress.
微分されたサービスの[MPLS-DS]MPLSサポート、フランソアLe Faucheur、Liwenウー、ブルース・デイビー、Shahram Davari(パシ・バーナネン)はクリシュナンに激突します、Pierrickシェヴァル、ユハHeinanen、処理中の作業。
Authors' Addresses
作者のアドレス
Scott W. Brim 146 Honness Lane Ithaca, NY 14850 USA
スコットW.縁146のHonness Laneニューヨーク14850イタケー(米国)
EMail: sbrim@cisco.com
メール: sbrim@cisco.com
Brian E. Carpenter IBM c/o iCAIR Suite 150 1890 Maple Avenue Evanston, IL 60201 USA
ブライアンE.大工IBM気付iCAIRスイート150 1890カエデAvenue IL60201エバンストン(米国)
EMail: brian@icair.org
メール: brian@icair.org
Francois Le Faucheur Cisco Systems Petra B - Les Lucioles 291, rue Albert Caquot 06560 Valbonne France
フランソア・Le FaucheurシスコシステムズペトラB--レスルシオール291、悔悟アルバート・カコ06560・Valbonneフランス
EMail: flefauch@cisco.com
メール: flefauch@cisco.com
Brim, et al. Standards Track [Page 5] RFC 2836 Per Hop Behavior Identification Codes May 2000
縁、他 規格は2000年5月にホップ振舞い識別コードあたりのRFC2836を追跡します[5ページ]。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat.
IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 権利のクレームのコピーで利用可能に作られるべきライセンスの保証、または一般的なライセンスか許可が作成者によるそのような所有権の使用に得させられた試みの結果が公表といずれにも利用可能になったか、またはIETF事務局からこの仕様のユーザを得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.
IETFはこの規格を練習するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 IETF専務に情報を記述してください。
Brim, et al. Standards Track [Page 6] RFC 2836 Per Hop Behavior Identification Codes May 2000
縁、他 規格は2000年5月にホップ振舞い識別コードあたりのRFC2836を追跡します[6ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2000). All Rights Reserved.
Copyright(C)インターネット協会(2000)。 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機能のための基金は現在、インターネット協会によって提供されます。
Brim, et al. Standards Track [Page 7]
縁、他 標準化過程[7ページ]
一覧
スポンサーリンク
