RFC3293 日本語訳

Network Working Group                                           A. Doria
Request for Comments: 3293                Lulea University of Technology
Category: Standards Track                                     J. Buerkle
                                                         Nortel Networks
                                                              T. Worster
                                                               June 2002

コメントを求めるワーキンググループA.ドーリア要求をネットワークでつないでください: 3293年の技術カテゴリのルーレオ大学: 規格はT.オースター2002年6月にJ.Buerkleノーテルネットワークを追跡します。

               General Switch Management Protocol (GSMP)
      Packet Encapsulations for Asynchronous Transfer Mode (ATM),
            Ethernet and Transmission Control Protocol (TCP)

非同期通信モード(気圧)のための一般スイッチ管理プロトコル(GSMP)パケットカプセル化、イーサネット、および通信制御プロトコル(TCP)

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

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

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(非同期なTransfer Mode)、イーサネット、およびTCP(通信制御プロトコル)でGSMP(一般Switch Managementプロトコル)パケットのカプセル化を指定します。

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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[7]で説明されるように本書では解釈されることであるべきですか?

1. Introduction

1. 序論

   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]で定義されて、輸送のためにいくつかの異なったプロトコルでカプセル化されるかもしれません。 このメモはATM AAL-5、イーサネットまたはTCPでそれらのカプセル化を指定します。 他のカプセル化は将来の仕様に基づき定義されるかもしれません。

Doria, et. al.              Standards Track                     [Page 1]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[1ページ]。

2. ATM Encapsulation

2. 気圧カプセル化

   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パケットは可変長です、そして、ATMデータ・リンク層において、それらはLLC/SNAPヘッダーと共に例証されるように直接AAL-5 CPCS-PDU[3][4]でカプセル化されます:

    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)                  +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | (0×00 00-00-88-0C)を折ってください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GSMPメッセージ~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0--47バイト)を水増ししてください。| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + AAL-5 CPCS-PDU Trailer(8バイト)+| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   (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]のドキュメンテーションにおけるコンベンションは小数における数を表すことになっています。 16進形式における数は. バイナリフォーマットの数が指定されるキャラクタと共にそれらについて前書きするキャラクタ"0x""0b"でそれらについて前書きすることによって、指定されます。データは「ビッグエンディアン」オーダーに描写されます。 すなわち、分野は左でまさしく言われます、権利における左の、そして、最も重要でないバイトで最も重要なバイトで。 ダイヤグラムがバイトのグループを示しているときはいつも、それらのバイトの送信の注文はそれらが英語で読まれる通常のオーダーです。 1バイトが数値量を表すときはいつも、ダイヤグラムで最も噛み付かれた左は、高位か最上位ビットです。 すなわち、0とラベルされたビットは最も重要なビットです。 同様に、マルチバイト分野が数値量を表すときはいつも、大部分が噛み付いた全体の分野の左は最も重要なビットです。 マルチバイト量が伝えられるとき、最も重要なバイトは最初に、伝えられます。 これはATM層の[2]とAAL-5[3][4]で使用される同じコード化コンベンションです。)

   The LLC/SNAP header contains the bytes: 0xAA 0xAA 0x03 0x00 0x00 0x00
   0x88 0x0C.  (0x880C is the assigned Ethertype for GSMP.)

LLC/SNAPヘッダーはバイトを含んでいます: 0xAA 0xAA、0×03 0×00 0×00 0×00 0×88 0x0C。 (0x880CはGSMPのための割り当てられたEthertypeです。)

   The maximum transmission unit (MTU) of the GSMP Message field is 1492
   bytes.

GSMP Message分野のマキシマム・トランスミッション・ユニット(MTU)は1492バイトです。

Doria, et. al.              Standards Track                     [Page 2]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[2ページ]。

   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制御チャンネルと呼ばれます。 ATMデータ・リンク層に関するGSMPメッセージであるとカプセル化されたLLC/SNAPのGSMP制御チャンネルのデフォルトVPIとVCIは以下の通りです。

      VPI = 0
      VCI = 15.

VPIは0VCI=15と等しいです。

   The GSMP control channel MAY be changed using the GSMP MIB.

GSMPは変えられた使用がGSMP MIBであったかもしれないならチャンネルを監督します。

3. Ethernet Encapsulation

3. イーサネットカプセル化

   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                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先アドレス| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ソースアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Ethertype(0×88-0C)| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | ~ GSMPメッセージ~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付者インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 受信機インスタンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | パッド| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | フレームチェックシーケンス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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

目的地Address For SYNは隣接番組プロトコルについて通信します。Destination Addressは放送演説0xFFFFFFFFFFFFです。 (あるいはまた、また、目的地のユニキャストの48ビットのIEEE MACアドレスでノードを構成するのも有効です。 この場合、構成されたユニキャストDestination AddressはSYNメッセージで使用されます。) 他のすべてのメッセージに関しては、Destination Addressはユニキャストの48ビットです。

Doria, et. al.              Standards Track                     [Page 3]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[3ページ]。

      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分野から発見されるかもしれません。

   Source Address
      For all messages, the Source Address is the 48-bit IEEE MAC
      address of the sender.

メッセージ、すべてのソースAddress For Source Addressが48ビットのIEEE MAC送信者のアドレスです。

   Ethertype
      The assigned Ethertype for GSMP is 0x880C.

GSMPのためのEthertypeの割り当てられたEthertypeは0x880Cです。

   GSMP Message
      The maximum transmission unit (MTU) of the GSMP Message field is
      1492 bytes.

GSMP Message分野のGSMP Messageマキシマム・トランスミッション・ユニット(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.

リンクの数が入手した送付者Instance Sender Instanceは隣接番組より議定書を作ります。 この分野は隣接番組プロトコルメッセージに既に存在しています。 不正な状態の導入に対する追加保護を提供するイーサネットカプセル化におけるすべての非隣接番組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.

受信機Instance、Receiver Instance番号は送付者がリンクの遠端における実体によって割り当てられたリンクの現在のインスタンス番号であると信じていることです。 この分野は隣接番組プロトコルメッセージに既に存在しています。 不正な状態の導入に対する追加保護を提供するイーサネットカプセル化におけるすべての非隣接番組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.

パッドAfter隣接番組は設立されて、イーサネットパケットのデータ・フィールドの最小の長さが46バイトであるということです。 必要なら、詰め物が加えられるべきであるので、それは最小のイーサネットフレーム・サイズを達成します。 この詰め物は、バイトのゼロであるべきであり、GSMPメッセージの一部であることは考えられないことです。

   Frame Check Sequence
      The Frame Check Sequence (FCS) is defined in IEEE 802.3 [6] as
      follows:

フレームCheck Sequence Frame Check Sequence(FCS)は[6] 以下のIEEE802.3で定義されます:

         Note: This section is included for informational and historical
         purposes only.  The normative reference can be found in IEEE
         802.3 Standard [6].

以下に注意してください。 このセクションは情報的、そして、歴史的な目的だけのために含まれています。 IEEE802.3Standard[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)

「周期冗長検査(CRC)が使用される、アルゴリズムを送受信して、FCS分野にCRC値を生成してください、」 フレームチェックシーケンス(FCS)分野は4バイトを含んでいます。(32ビット)

Doria, et. al.              Standards Track                     [Page 4]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[4ページ]。

         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)値。 この値はソースアドレス、送付先アドレス、長さ、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].

[6]でCRC計算のための手順を見つけることができます。

   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ヘッダー、Sender Instance、およびReceiver InstanceからSource Addressをチェックしなければなりません。 Sender InstanceとSource AddressがGSMP隣接番組プロトコルの「アップデート同輩検証」操作で保存されたSender InstanceとSender Nameの値に合っていないなら、入って来るGSMPメッセージを捨てなければなりません。 また、隣接番組プロトコルが連動を実現したポート以外のどんなポートにわたっても到着するなら、入って来るGSMPメッセージを捨てなければなりません。 また、さらに、Receiver Instance分野がGSMP隣接番組プロトコルのSender Instanceのための現行価値に合っていないなら、入力メッセージを捨てなければなりません。

4. TCP/IP Encapsulation

4. TCP/IPカプセル化

   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コントローラインスタンスからの複合管理セッションの作成を許容するためにはマルチ接続サーバでなければなりません(PORT6068)。 そして、連動するのに使用される隣接番組プロトコルメッセージ、コントローラ、切り換えてください、そして、握手が発信して、TCP接続の後のスイッチへのコントローラが設立されるということであると主張してください。 隣接番組プロトコルが連動を実現した後まで隣接番組プロトコルメッセージ以外のGSMPメッセージを送ってはいけません。 実際のGSMPメッセージ流動は他のポートの上に起こるでしょう。

Doria, et. al.              Standards Track                     [Page 5]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[5ページ]。

4.1 Message Formats

4.1 メッセージ形式

   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.

TCP接続の上にGSMPメッセージを送ります。 それを完全に受け取った後にだけGSMPメッセージを処理します。 4バイトのTLVヘッダーフィールドはTCPストリームの中でGSMPメッセージの輪郭描写を提供するGSMPメッセージにprependedされます。

    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                          ~
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | (0×88-0C)をタイプしてください。| 長さ| |-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ GSMPメッセージ~| | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   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バイトの分野が、タイプがコード化するのを示す以下のメッセージのThisをタイプしてください。 GSMPメッセージのためのタイプコードは0×88-0C(すなわち、GSMPのEthertypeと同じ)です。

   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の全長が通信するのを示す長さのThis専用。 それは4バイトのTLVヘッダーを含んでいません。

4.2 TCP/IP Security consideration

4.2 TCP/IP Securityの考慮

   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 Security[IPSEC]は提供しなければなりません。 この場合、保全と秘密性の両方を提供するのに、IPSEC Encapsulation Security有効搭載量(超能力)を使用しなければなりません。

5. Security Considerations

5. セキュリティ問題

   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の上の走行であることはREQUIREDです。 リンクレイヤでATMを使用するセキュリティとイーサネットカプセル化を提供するかもしれません。 これらのメソッドの議論はこの仕様の範囲を超えています。 どんなメディアの上の安全な操作、IPsec SHOULDが使用されているIPカプセル化のために。

Doria, et. al.              Standards Track                     [Page 6]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[6ページ]。

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.オースター、「一般スイッチ経営者側は2002年6月に(GSMP)V3"、RFC3292について議定書の中で述べます」。

   [2] "B-ISDN ATM Layer Specification," International Telecommunication
       Union, ITU-T Recommendation I.361, Feb. 1999.

[2] 「B-ISDN気圧層の仕様」、国際電気通信連合、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気圧適合層(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 Adaptation Layer仕様:」 「タイプ5AAL」、国際電気通信連合、ITU-T推薦I.363.5、1996年8月。

   [5] Reynolds, J., Editor, "Assigned Numbers", RFC 3232, January 2002.

[5] レイノルズ、J.、エディタ、「規定番号」、RFC3232、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 Std802.3、1998Edition、「システムの間の情報交換--地方とメトロポリタンエリアネットワーク--情報技術テレコミュニケーションと決められた一定の要求--3を分けてください」 「衝突検出(CSMA/CD)アクセス法と物理的な層の仕様がある搬送波感知多重アクセス」

   [7] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

[7] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

Doria, et. al.              Standards Track                     [Page 7]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[7ページ]。

Authors' Addresses

作者のアドレス

   Tom Worster

トム・オースター

   Phone: +1 617 247 2624
   EMail: fsb@thefsb.org

以下に電話をしてください。 +1 2624年の617 247メール: fsb@thefsb.org

   Avri Doria
   Div. of Computer Communications
   Lulea University of Technology
   S-971 87 Lulea
   Sweden

AvriドーリアDiv技術S-971 87ルーレオスウェーデンのコンピュータコミュニケーションルーレオ大学について

   Phone: +1 401 663 5024
   EMail: avri@acm.com

以下に電話をしてください。 +1 5024年の401 663メール: avri@acm.com

   Joachim Buerkle
   Nortel Networks Germany GmbH & Co. KG
   Hahnstr. 37-39
   60528 Frankfurt am Main
   Germany

ヨアヒムBuerkleノーテルはドイツGmbH社のkg Hahnstrをネットワークでつなぎます。 37-39 60528 フランクフルト・アム・マインドイツ

   EMail: Joachim.Buerkle@nortelnetworks.com

メール: Joachim.Buerkle@nortelnetworks.com

Doria, et. al.              Standards Track                     [Page 8]

RFC 3293               GSMP Packet Encapsulations              June 2002

etドーリア、アル。 規格はGSMPパケットカプセル化2002年6月にRFC3293を追跡します[8ページ]。

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

Doria, et. al.              Standards Track                     [Page 9]

etドーリア、アル。 標準化過程[9ページ]