Network Working Group A. Doria
Request for Comments: 3293 Lulea University of Technology
Category: Standards Track J. Buerkle
Nortel Networks
T. Worster
June 2002
General Switch Management Protocol (GSMP)
Packet Encapsulations for Asynchronous Transfer Mode (ATM),
Ethernet and Transmission Control Protocol (TCP)
Status of this 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.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This memo specifies the encapsulation of GSMP (General Switch Management Protocol) packets in ATM (Asynchronous Transfer Mode), Ethernet and TCP (Transmission Control Protocol).
このメモはATMでのGSMPのカプセル化（一般的にはスイッチ管理プロトコル）パケット（非同期転送モード）、イーサネットとTCP（Transmission Control Protocol）を指定します。
Specification of 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 RFC 2119 [7].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[7]。
GSMP messages are defined in [1] and MAY be encapsulated in several different protocols for transport. This memo specifies their encapsulation in ATM AAL-5, in Ethernet or in TCP. Other encapsulations may be defined in future specifications.
GSMPメッセージは、[1]で定義されており、輸送のために、いくつかの異なるプロトコルでカプセル化され得ます。このメモは、イーサネットまたはTCPで、ATM AAL-5でのカプセル化を指定します。その他のカプセル化は、将来の仕様で定義されてもよいです。
GSMP packets are variable length and for an ATM data link layer they are encapsulated directly in an AAL-5 CPCS-PDU [3][4] with an LLC/SNAP header as illustrated:
GSMPパケットは可変長それらはAAL-5 CPCS-PDU内に直接カプセル化されたATMデータリンク層のためのものである[3] [4]を示すようにLLC / SNAPヘッダを有します：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LLC (0xAA-AA-03) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| SNAP (0x00-00-00-88-0C) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad (0 - 47 bytes) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ AAL-5 CPCS-PDU Trailer (8 bytes) +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(The convention in the documentation of Internet Protocols [5] is to express numbers in decimal. Numbers in hexadecimal format are specified by prefacing them with the characters "0x". Numbers in binary format are specified by prefacing them with the characters "0b". Data is pictured in "big-endian" order. That is, fields are described left to right, with the most significant byte on the left and the least significant byte on the right. Whenever a diagram shows a group of bytes, the order of transmission of those bytes is the normal order in which they are read in English. Whenever a byte represents a numeric quantity the left most bit in the diagram is the high order or most significant bit. That is, the bit labelled 0 is the most significant bit. Similarly, whenever a multi-byte field represents a numeric quantity the left most bit of the whole field is the most significant bit. When a multi-byte quantity is transmitted, the most significant byte is transmitted first. This is the same coding convention as is used in the ATM layer [2] and AAL-5 [3][4].)
（インターネットプロトコルのドキュメントの規則は[5]小数で数値を表現することである。進形式の番号は文字「0x」でそれらを巻頭で指定されている。バイナリ形式で番号が文字「0B」でそれらを巻頭で指定されています。データは、「ビッグエンディアン」の順番で描かれている。つまり、図はバイトのグループを示しているときは常にフィールドが。左の最上位バイトと右の最下位バイトで、左から右に記載されているが、順序これらのバイトの送信のバイトが数値を表す場合は常に図中最も左のビットが高位または最上位ビットである。それらは英語で読み込まれた通常の順で、ビットは0が最もある標識されていることマルチバイトフィールドが数値を表すときはいつでもマルチバイト数が送信されると上位ビット。同様に、フィールド全体の最も左のビットが最上位ビット、最上位バイトが最初に送信される。これは、SAMであります[4] [3] [2]とAAL-5 ATMレイヤで使用されるように電子規則をコーディング。）
The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 0x00 0x88 0x0C. (0x880C is the assigned Ethertype for GSMP.)
0xAAを0xAAを0x03の0x00を0x00には0x00 0x88 0x0Cの：LLC / SNAPヘッダは、バイトを含みます。 （0x880CはGSMPのために割り当てられたイーサタイプです。）
The maximum transmission unit (MTU) of the GSMP Message field is 1492 bytes.
GSMPメッセージフィールドの最大伝送単位（MTU）が1492バイトです。
The virtual channel over which a GSMP session is established between a controller and the switch it is controlling is called the GSMP control channel. The default VPI and VCI of the GSMP control channel for LLC/SNAP encapsulated GSMP messages on an ATM data link layer is:
GSMPセッションがコントローラとそれが制御しているスイッチとの間に確立される、仮想チャネルはGSMP制御チャネルと呼ばれます。 LLC / SNAPのためのGSMP制御チャネルのデフォルトVPIとVCIは、ATMデータリンク層の上にGSMPメッセージをカプセル化しています。
VPI = 0 VCI = 15.
VPI = 0 VCI = 15。
The GSMP control channel MAY be changed using the GSMP MIB.
GSMP制御チャネルは、GSMP MIBを使用して変更することがあります。
GSMP packets MAY be encapsulated on an Ethernet data link as illustrated:
図示のようGSMPパケットは、イーサネットデータリンク上でカプセル化することができます。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ethertype (0x88-0C) | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sender Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Receiver Instance |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Pad |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination Address For the SYN message of the adjacency protocol the Destination Address is the broadcast address 0xFFFFFFFFFFFF. (Alternatively, it is also valid to configure the node with the unicast 48-bit IEEE MAC address of the destination. In this case the configured unicast Destination Address is used in the SYN message.) For all other messages the Destination Address is the unicast 48-bit
隣接プロトコルのSYNメッセージの宛先アドレスは、宛先アドレスはブロードキャストアドレス0xFFFFFFFFFFFFです。 （あるいは、宛先のユニキャスト48ビットIEEE MACアドレスを使用してノードを構成することも有効である。この場合、構成ユニキャスト宛先アドレスはSYNメッセージで使用されている。）他のすべてのメッセージの宛先アドレスがユニキャストであります48ビット
IEEE. MAC address of the destination. This address may be discovered from the Source Address field of messages received during synchronisation of the adjacency protocol.
IEEE。送信先のMACアドレス。このアドレスは、隣接プロトコルの同期中に受信したメッセージの送信元アドレスフィールドから発見することができます。
Source Address For all messages, the Source Address is the 48-bit IEEE MAC address of the sender.
すべてのメッセージの送信元アドレス、送信元アドレスは、送信者の48ビットIEEE MACアドレスです。
Ethertype The assigned Ethertype for GSMP is 0x880C.
GSMPに割り当てられたイーサタイプは0x880Cですイーサタイプ。
GSMP Message The maximum transmission unit (MTU) of the GSMP Message field is 1492 bytes.
GSMPメッセージGSMPメッセージフィールドの最大伝送単位（MTU）が1492バイトです。
Sender Instance The Sender Instance number for the link obtained from the adjacency protocol. This field is already present in the adjacency protocol message. It is appended to all non-adjacency GSMP messages in the Ethernet encapsulation to offer additional protection against the introduction of corrupt state.
差出人インスタンス隣接プロトコルから得られたリンクのための送信者インスタンス番号。このフィールドは、隣接プロトコルメッセージ内に既に存在しています。壊れた状態の導入に対する追加の保護を提供するために、イーサネットカプセル化におけるすべての非隣接GSMPメッセージに添付されています。
Receiver Instance The Receiver Instance number is what the sender believes is the current instance number for the link, allocated by the entity at the far end of the link. This field is already present in the adjacency protocol message. It is appended to all non-adjacency GSMP messages in the Ethernet encapsulation to offer additional protection against the introduction of corrupt state.
レシーバインスタンスザ・レシーバインスタンスの数は、送信者がリンクの遠端でのエンティティによって割り当てられたリンクの現在のインスタンス番号、であると考えているものです。このフィールドは、隣接プロトコルメッセージ内に既に存在しています。壊れた状態の導入に対する追加の保護を提供するために、イーサネットカプセル化におけるすべての非隣接GSMPメッセージに添付されています。
Pad After adjacency has been established the minimum length of the data field of an Ethernet packet is 46 bytes. If necessary, padding should be added such that it meets the minimum Ethernet frame size. This padding should be bytes of zero and is not to be considered part of the GSMP message.
隣接した後、パッドは、イーサネットパケットのデータフィールドの最小長さが46バイトで確立されています。必要であれば、パディングは、それが最小のイーサネットフレームサイズを満たすように添加されるべきです。このパディングはゼロバイトであるべきであり、GSMPメッセージの一部と見なされるべきではありません。
Frame Check Sequence The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6] as follows:
フレームチェックシーケンスフレームチェックシーケンス（FCS）は、IEEE802.3で定義されている[6]を次のように
Note: This section is included for informational and historical
purposes only. The normative reference can be found in IEEE
802.3 Standard [6].
"A cyclic redundancy check (CRC) is used by the transmit and receive algorithms to generate a CRC value for the FCS field. The frame check sequence (FCS) field contains a 4-byte (32-bit) cyclic redundancy check (CRC) value. This value is computed as a function of the contents of the source address, destination address, length, LLC data and pad (that is, all fields except the preamble, SFD, FCS and extension). The encoding is defined by the following generating polynomial.
「巡回冗長検査（CRC）を送信することによって使用され、FCSフィールドのCRC値を生成するアルゴリズムを受け取る。フレームチェックシーケンス（FCS）フィールドは、4バイト（32ビット）巡回冗長検査（CRC）が含まれています値は、この値は、ソースアドレス、宛先アドレス、長さ、LLCデータ及びパッド。符号化は、以下によって定義される（すなわち、プリアンブルを除くすべてのフィールドは、SFD、FCS及び拡張は、である）の内容の関数として計算されます。多項式を生成します。
G(x)=x^32+x^26+x^23+x^22+x^16+x^12+x^11+x^10+x^8+x^ 7+x^5+x^4+x^2+x^1."
G（X）= X ^ 32 + X ^ 26 + X ^ 23 + X ^ 22 + X ^ 16 + X ^ 12 + X ^ 11 + X ^ 10 + X ^ 8 + X ^ 7 + X ^ 5 + X ^ 4 + X ^ 2 + X ^ 1。」
The procedure for the CRC calculation can be found in [6].
CRC計算のための手順は、[6]に見出すことができます。
After the adjacency protocol has achieved synchronisation, for every GSMP message received with an Ethernet encapsulation, the receiver must check the Source Address from the Ethernet MAC header, the Sender Instance, and the Receiver Instance. The incoming GSMP message must be discarded if the Sender Instance and the Source Address do not match the values of the Sender Instance and the Sender Name stored by the "Update Peer Verifier" operation of the GSMP adjacency protocol. The incoming GSMP message must also be discarded if it arrives over any port other than the port over which the adjacency protocol has achieved synchronisation. In addition, the incoming message must also be discarded if the Receiver Instance field does not match the current value for the Sender Instance of the GSMP adjacency protocol.
隣接プロトコルは、イーサネットカプセル化で受信毎GSMPメッセージに対して、同期を達成した後、受信機は、イーサネットMACヘッダ、送信者インスタンス、および受信インスタンスから送信元アドレスをチェックしなければなりません。送信者インスタンスと送信元アドレスは、送信者インスタンスとGSMP隣接プロトコルの「更新ピア検証」操作によって保存された送信者名の値と一致しない場合は、着信GSMPメッセージは廃棄されなければなりません。それは隣接プロトコルは、同期を達成した上ポート以外のポートを介して到着した場合、着信GSMPメッセージは廃棄しなければなりません。受信インスタンスフィールドはGSMP隣接プロトコルの送信元のインスタンスの現在の値と一致しない場合に加えて、着信メッセージも廃棄しなければなりません。
When GSMP messages are transported over an IP network, they MUST be transported using the TCP encapsulation. TCP provides reliable transport, network flow control, and end-system flow control suitable for networks that may have high loss and variable or unpredictable delay.
GSMPメッセージは、IPネットワーク上で転送されると、それらはTCPカプセル化を使用して輸送しなければなりません。 TCPは信頼性の高いトランスポート、ネットワークフロー制御、及び高い損失及び変数または予測不可能な遅延を有することができるネットワークに適したエンドシステムフロー制御を提供します。
For TCP encapsulations of GSMP messages, the controller runs the client code and the switch runs the server code. Upon initialisation, the server is listening on GSMP's TCP port number: 6068. The controller establishes a TCP connection with each switch it manages. The switch under control MUST be a multi-connection server (PORT 6068) to allow creation of multiple control sessions from N GSMP controller instances. Adjacency protocol messages, which are used to synchronise the controller and switch and maintain handshakes, are sent by the controller to the switch after the TCP connection is established. GSMP messages other than adjacency protocol messages MUST NOT be sent until after the adjacency protocol has achieved synchronisation. The actual GSMP message flow will occur on other ports.
GSMPメッセージのTCPカプセル化のために、コントローラは、クライアントコードを実行し、スイッチは、サーバのコードを実行します。初期化すると、サーバーはGSMPのTCPポート番号をリッスンしている：6068.コントローラは、各それが管理して切り替えるとTCPコネクションを確立します。制御下のスイッチは、N GSMPコントローラインスタンスから複数のコントロール・セッションの作成を可能にするために複数接続サーバ（PORT 6068）でなければなりません。 TCP接続が確立された後にコントローラを同期させるスイッチとハンドシェイクを維持するために使用される隣接プロトコルメッセージは、スイッチコントローラによって送られます。隣接プロトコルメッセージ以外のGSMPメッセージは、隣接プロトコルは、同期を達成した後まで送ってはいけません。実際のGSMPメッセージフローは、他のポートで発生します。
GSMP messages are sent over a TCP connection. A GSMP message is processed only after it is entirely received. A four-byte TLV header field is prepended to the GSMP message to provide delineation of GSMP messages within the TCP stream.
GSMPメッセージは、TCP接続を介して送信されます。 GSMPメッセージは、それが完全に受信された後にのみ処理されます。 4バイトTLVヘッダフィールドは、TCPストリーム内GSMPメッセージの描写を提供するGSMPメッセージに付加されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type (0x88-0C) | Length |
|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ GSMP Message ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type This 2-byte field indicates the type code of the following message. The type code for GSMP messages is 0x88-0C (i.e., the same as GSMP's Ethertype).
この2バイトのフィールドは、次のメッセージのタイプコードを示して入力します。 GSMPメッセージのタイプコードは0x88-0C（すなわち、GSMPのイーサタイプと同じ）です。
Length This 2-byte unsigned integer indicates the total length of the GSMP message only. It does not include the 4-byte TLV header.
長さはこの2バイトの符号なし整数のみGSMPメッセージの全長を示します。これは、4バイトのTLVヘッダが含まれていません。
When GSMPv3 is implemented for use in IP networks, provisions for security between the controller and client MUST be available and MUST be provided by IP Security [IPSEC]. In this case, the IPSEC Encapsulation Security Payload (ESP) MUST be used to provide both integrity and confidentiality.
GSMPv3は、IPネットワークで使用するために実装されている場合は、コントローラとクライアント間の安全保障のための規定が利用可能でなければなりませんし、IPセキュリティ[IPSEC]によって提供されなければなりません。この場合、IPSECのカプセル化セキュリティペイロード（ESP）は、完全性と機密性の両方を提供するために使用されなければなりません。
The security of GSMP's TCP/IP control channel has been addressed in Section 4.2. For all uses of GSMP over an IP network it is REQUIRED that GSMP be run over TCP/IP using the security considerations discussed in Section 4.2. Security using ATM and Ethernet encapsulations MAY be provided at the link layer. Discussion of these methods is beyond the scope of this specification. For secure operation over any media, the IP encapsulation with IPsec SHOULD be used.
GSMPのTCP / IP制御チャネルのセキュリティは、セクション4.2で解決されています。 IPネットワーク上でGSMPのすべての使用のためには、GSMPは、4.2節で説明したセキュリティの考慮事項を使用してTCP / IP上で実行する必要があります。 ATMとイーサネットカプセル化を使用して、セキュリティは、リンク層を設けてもよいです。これらの方法の議論はこの仕様の範囲を超えています。任意のメディアを介した安全な動作のために、IPsecの持つIPカプセル化を使用する必要があります。
References
リファレンス
[1] Doria, A., Sundell, K., Hellstrand, F. and T. Worster, "General Switch Management Protocol (GSMP) V3", RFC 3292, June 2002.
[1]ドリア、A.、Sundell、K.、Hellstrand、F.とT. Worster、 "一般的なスイッチ管理プロトコル（GSMP）V3"、RFC 3292、2002年6月。
[2] "B-ISDN ATM Layer Specification," International Telecommunication Union, ITU-T Recommendation I.361, Feb. 1999.
[2] "B-ISDN ATM層仕様、" 国際電気通信連合、ITU-T勧告I.361、1999年2月。
[3] "B-ISDN ATM Adaptation Layer (AAL) Specification," International Telecommunication Union, ITU-T Recommendation I.363, Mar. 1993.
[3]、 "B-ISDN ATMアダプテーションレイヤ（AAL）仕様、" 国際電気通信連合、ITU-T勧告I.363、1993年3月。
[4] "B-ISDN ATM Adaptation Layer specification: Type 5 AAL", International Telecommunication Union, ITU-T Recommendation I.363.5, Aug. 1996.
[4] "B-ISDN ATMアダプテーションレイヤ仕様：タイプ5 AAL"、国際電気通信連合、ITU-T勧告I.363.5、1996年8月。
[5] Reynolds, J., Editor, "Assigned Numbers", RFC 3232, January 2002.
[5]レイノルズ、J.、エディタ、 "割り当て番号"、RFC 3232、2002年1月。
[6] IEEE Std 802.3, 1998 Edition "Information technology-Telecommunications and information exchange between systems - Local and metropolitan area networks - Specific requirements - Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications"
[6] IEEE 802.3、1998年版「情報技術 - 電気通信及びシステム間の情報交換 - 地方とメトロポリタンエリアネットワーク - 特定の要件 - パート3：衝突検出（CSMA / CD）アクセス方式および物理層仕様とキャリア検知多重アクセス"
[7] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[7]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
Authors' Addresses
著者のアドレス
Tom Worster
トムWorster
Phone: +1 617 247 2624 EMail: fsb@thefsb.org
電話：+1 617 247 2624 Eメール：fsb@thefsb.org
Avri Doria Div. of Computer Communications Lulea University of Technology S-971 87 Lulea Sweden
Avriドリア本部。コンピュータ通信ルレオ工科大学のS-971 87ルーレオスウェーデンの
Phone: +1 401 663 5024 EMail: avri@acm.com
電話：+1 401 663 5024 Eメール：avri@acm.com
Joachim Buerkle Nortel Networks Germany GmbH & Co. KG Hahnstr. 37-39 60528 Frankfurt am Main Germany
ヨアヒムBuerkle Nortel Networksのドイツ社＆株式会社KG Hahnstr。 37-39 60528フランクフルト・アム・マインドイツAm
EMail: Joachim.Buerkle@nortelnetworks.com
メールアドレス：Joachim.Buerkle@nortelnetworks.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
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.
この文書とその翻訳は、コピーして他の人に提供し、それ以外についてはコメントまたは派生物は、いかなる種類の制限もなく、全体的にまたは部分的に、準備コピーし、公表して配布することができることを説明したり、その実装を支援することができます、上記の著作権表示とこの段落は、すべてのそのようなコピーや派生物に含まれていることを条件とします。しかし、この文書自体は著作権のための手順はで定義されている場合には、インターネット標準を開発するために必要なものを除き、インターネットソサエティもしくは他のインターネット関連団体に著作権情報や参照を取り除くなど、どのような方法で変更されないかもしれませんインターネット標準化プロセスが続く、または英語以外の言語に翻訳するために、必要に応じなければなりません。
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機能のための基金は現在、インターネット協会によって提供されます。