RFC2615 日本語訳

2615 PPP over SONET/SDH. A. Malis, W. Simpson. June 1999. (Format: TXT=18708 bytes) (Obsoletes RFC1619) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          A. Malis
Request for Comments: 2615                  Ascend Communications, Inc.
Obsoletes: 1619                                              W. Simpson
Category: Standards Track                                    DayDreamer
                                                              June 1999

Malisがコメントのために要求するワーキンググループA.をネットワークでつないでください: 2615はInc.が時代遅れにするコミュニケーションを昇ります: 1619年のW.シンプソンカテゴリ: 標準化過程空想家1999年6月

                           PPP over SONET/SDH

Sonet/SDHの上のppp

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

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

Abstract

要約

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.
   This document describes the use of PPP over Synchronous Optical
   Network (SONET) and Synchronous Digital Hierarchy (SDH) circuits.

Pointからポイントへのプロトコル(PPP)[1]はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。 このドキュメントは同期式光通信網(Sonet)と同期デジタルハイアラーキ(SDH)サーキットの上にPPPの使用について説明します。

   This document replaces and obsoletes RFC 1619.  See section 7 for a
   summary of the changes from RFC 1619.

このドキュメントは、RFC1619を取り替えて、時代遅れにします。 RFC1619からの変化の概要に関してセクション7を見てください。

Table of Contents

目次

   1.     Introduction ..........................................    2
   2.     Physical Layer Requirements ...........................    3
   3.     Framing ...............................................    4
   4.     X**43 + 1 Scrambler Description .......................    4
   5.     Configuration Details .................................    6
   6.     Security Considerations ...............................    6
   7.     Changes from RFC 1619 .................................    7
   8.     Intellectual Property .................................    7
   9.     Acknowledgments .......................................    8
   10.    References ............................................    8
   11.    Authors' Addresses ....................................    9
   12.    Full Copyright Statement ..............................   10

1. 序論… 2 2. 物理的な層の要件… 3 3. 縁どっています。 4 4. X**43+1秘話装置記述… 4 5. 構成の詳細… 6 6. セキュリティ問題… 6 7. RFC1619からの変化… 7 8. 知的所有権… 7 9. 承認… 8 10. 参照… 8 11. 作者のアドレス… 9 12. 完全な著作権宣言文… 10

Malis & Simpson             Standards Track                     [Page 1]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[1ページ]。

1.  Introduction

1. 序論

   PPP was designed as a standard method of communicating over
   point-to-point links.  Initial deployment has been over short local
   lines, leased lines, and plain-old-telephone-service (POTS) using
   modems.  As new packet services and higher speed lines are introduced,
   PPP is easily deployed in these environments as well.

ポイントツーポイントの上で交信する標準方法がリンクされるとき、PPPは設計されました。 短いローカル線、専用線、および明瞭な古い電話サービス(POTS)の上に初期の展開が、モデムを使用することでありました。新しいパケットサービスと、より高い速度線が紹介されるとき、PPPはまた、これらの環境で容易に配備されます。

   This specification is primarily concerned with the use of the PPP
   encapsulation over SONET/SDH links.  Since SONET/SDH is by definition
   a point-to-point circuit, PPP is well suited to use over these links.

Sonet/SDHリンクに関してPPPカプセル化の使用にこの仕様を主として心配させます。 Sonet/SDHが定義上二地点間サーキットであるので、PPPはこれらのリンクの上の使用によく合っています。

   Real differences between SONET and SDH (other than terminology) are
   minor; for the purposes of encapsulation of PPP over SONET/SDH, they
   are inconsequential or irrelevant.

SonetとSDH(用語を除いた)の本当の違いは小さい方です。 Sonet/SDHの上のPPPのカプセル化の目的のために、それらは、取るに足らないか、または無関係です。

   For the convenience of the reader, we list the equivalent terms below:

読者の都合のために、私たちは以下の同義語を記載します:

       SONET                   SDH
   ---------------------------------------------
   SPE                         VC
   STS-SPE                     Higher Order VC (VC-3/4/4-Nc)
   STS-1 frame                 STM-0 frame (rarely used)
   STS-1-SPE                   VC-3
   STS-1 payload               C-3
   STS-3c frame                STM-1 frame, AU-4
   STS-3c-SPE                  VC-4
   STS-3c payload              C-4
   STS-12c/48c/192c frame      STM-4/16/64 frame, AU-4-4c/16c/64c
   STS-12c/48c/192c-SPE        VC-4-4c/16c/64c
   STS-12c/48c/192c payload    C-4-4c/16c/64c

Sonet SDH--------------------------------------------- SPE VC STS-SPE Higher Order VC、(VC3/4/4Nc、)、STS-1フレームSTM-0は(めったに使用されません)STS-1-SPE VC-3 STS-1ペイロードC-3STS-3cフレームSTM-1フレームを縁どっています、AU-4 STS-3c-SPE VC-4 STS-3cペイロードC-4STS-12c/48c/192cフレームSTM-4/16/64のフレーム、192cペイロードC AU-4-4c/16c/64c STS-12c/48c/192c-SPE VC-4-4c/16c/64c STS-12c/48c/4-4c/16c/64c

   The only currently supported SONET/SDH SPE/VCs are the following:

唯一の現在支持されたSonet/SDH SPE/VCsが以下です:

       SONET                   SDH
   ----------------------------------------
   STS-3c-SPE                  VC-4
   STS-12c-SPE                 VC-4-4c
   STS-48c-SPE                 VC-4-16c
   STS-192c-SPE                VC-4-64c

Sonet SDH---------------------------------------- STS-3c-SPE VC-4 STS-12c-SPE VC-4-4c STS-48c-SPE VC-4-16c STS-192c-SPE VC-4-64c

   The keywords MUST, MUST NOT, MAY, OPTIONAL, REQUIRED, RECOMMENDED,
   SHALL, SHALL NOT, SHOULD, and SHOULD NOT are to be interpreted as
   defined in [6].

キーワードが解釈しなければならない、[6]で定義されるようにNOT、5月、OPTIONAL、REQUIRED、RECOMMENDED、SHALL、SHALL NOT、SHOULD、およびSHOULD NOTを解釈することになっていなければなりませんか?

Malis & Simpson             Standards Track                     [Page 2]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[2ページ]。

2.  Physical Layer Requirements

2. 物理的な層の要件

   PPP treats SONET/SDH transport as octet oriented synchronous links.
   SONET/SDH links are full-duplex by definition.

八重奏が同期リンクを適応させたので、PPPはSonet/SDH輸送を扱います。 Sonet/SDHリンクは定義上全二重です。

   Interface Format

インタフェース形式

      PPP in HDLC-like framing presents an octet interface to the
      physical layer.  There is no provision for sub-octets to be
      supplied or accepted [3][5].

HDLCのような縁どりにおけるPPPは物理的な層に八重奏インタフェースを提示します。 供給されるサブ八重奏か受け入れられた[3][5]への支給が全くありません。

      The octet stream is mapped into the SONET STS-SPE/SDH Higher Order
      VC, with the octet boundaries aligned with the SONET STS-SPE/SDH
      Higher Order VC octet boundaries.

八重奏の流れはSonet STS-SPE/SDH Higher Order VCに写像されます、八重奏境界がSonet STS-SPE/SDH Higher Order VC八重奏境界に並べられている状態で。

      Scrambling is performed during insertion into the SONET STS-
      SPE/SDH Higher Order VC to provide adequate transparency and
      protect against potential security threats (see Section 6).  For
      backwards compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), the
      scrambler MAY have an on/off capability where the scrambler is
      bypassed entirely when it is in the off mode.  If this capability
      is provided, the default MUST be set to scrambling enabled.

よじ登ることは、適切な透明を提供して、潜在的軍事的脅威から守るために挿入の間、Sonet STS- SPE/SDH Higher Order VCに実行されます(セクション6を見てください)。 RFC1619(STS-3c-SPE/VC-4専用)との遅れている互換性のために、完全にそれがオフモードであるとき、秘話装置が迂回するところに秘話装置はオンであるかオフな能力を持っているかもしれません。 この能力を提供するなら、可能にされたよじ登るのにデフォルトを設定しなければなりません。

      For PPP over SONET/SDH, the entire SONET/SDH payload (SONET STS-
      SPE/SDH Higher Order VC minus the path overhead and any fixed
      stuff) is scrambled using a self-synchronous scrambler of
      polynomial X**43 + 1.  See Section 4 for the description of the
      scrambler.

Sonet/SDHの上のPPPに関して、全体のSonet/SDHペイロード(経路オーバーヘッドを引いたSonet STS- SPE/SDH Higher Order VCとどんな固定ものも)は、多項式X*の自己同期の秘話装置を使用することで急いで移動します。*43+1。 秘話装置の記述に関してセクション4を見てください。

      The proper order of operation is:

操作の適切な注文は以下の通りです。

      When transmitting:

伝わるとき:

         IP -> PPP -> FCS generation -> Byte stuffing -> Scrambling  ->
         SONET/SDH framing

->Scrambling->Sonet/SDH縁どりを詰めるIP->PPP->FCS世代->Byte

      When receiving:

受信するとき:

         SONET/SDH framing -> Descrambling -> Byte destuffing -> FCS
         detection -> PPP -> IP

Sonet/SDH縁どり->Descrambling->Byte destuffing->FCS検出->PPP->IP

   The Path Signal Label (C2) indicates the contents of the SONET STS-
   SPE/SDH Higher Order VC.  The value of 22 (16 hex) is used to
   indicate PPP with X^43 + 1 scrambling [4].

Path Signal Label(C2)はSonet STS- SPE/SDH Higher Order VCのコンテンツを示します。 22(16十六進法)の値は、[4]を急いで移動させるX^43+1でPPPを示すのに使用されます。

   For compatibility with RFC 1619 (STS-3c-SPE/VC-4 only), if scrambling
   has been configured to be off, then the value 207 (CF hex) is used
   for the Path Signal Label to indicate PPP without scrambling.

RFC1619(STS-3c-SPE/VC-4専用)との互換性において、よじ登ることがオフになるように構成されたなら、Path Signal Labelがよじ登らないでPPPを示すのに値207(CF十六進法)は使用されます。

Malis & Simpson             Standards Track                     [Page 3]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[3ページ]。

   The Multiframe Indicator (H4) is unused, and MUST be zero.

Multiframe Indicator(H4)は未使用であり、ゼロであるに違いありません。

   Control Signals

制御信号

      PPP does not require the use of control signals.  When available,
      using such signals can allow greater functionality and
      performance.  Implications are discussed in [2].

PPPは制御信号の使用を必要としません。 利用可能であるときに、そのような信号を使用すると、より大きい機能性と性能を許容できます。 [2]で含意について議論します。

3.  Framing

3. 縁どり

   The framing for octet-synchronous links is described in "PPP in
   HDLC-like Framing" [2].

八重奏同期のリンクのための縁どりは「HDLCのような縁どりにおけるppp」[2]で説明されます。

   The PPP frames are located by row within the SONET STS-SPE/SDH Higher
   Order VC payload.  Because frames are variable in length, the frames
   are allowed to cross SONET STS-SPE/SDH Higher Order VC boundaries.

PPPフレームはSonet STS-SPE/SDH Higher Order VCペイロードの中に列によって位置させられています。 フレームが長さで可変であるので、フレームはSonet STS-SPE/SDH Higher Order VC境界に交差できます。

4.  X**43 + 1 Scrambler Description

4. X**43+1秘話装置記述

   The X**43 + 1 scrambler transmitter and receiver operation are as
   follows:

X**43+1秘話装置送信機と受信機操作は以下の通りです:

   Transmitter schematic:

送信機概要:

                                              Unscrambled Data
                                                     |
                                                     v
        +-------------------------------------+    +---+
     +->|     --> 43 bit shift register -->   |--->|xor|
     |  +-------------------------------------+    +---+
     |                                               |
     +-----------------------------------------------+
                                                     |
                                                     v
                                               Scrambled Data

もとに戻されたデータ| +に対して-------------------------------------+ +---+ +->| -->43ビットシフトレジスタ-->。|、-、--、>|xor| | +-------------------------------------+ +---+ | | +-----------------------------------------------+ | Scrambled Dataに対して

Malis & Simpson             Standards Track                     [Page 4]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[4ページ]。

   Receiver schematic:

受信機概要:

                                               Scrambled Data
                                                     |
     +-----------------------------------------------+
     |                                               |
     |                                               v
     |  +-------------------------------------+    +---+
     +->|     --> 43 bit shift register -->   |--->|xor|
        +-------------------------------------+    +---+
                                                     |
                                                     v
                                             Unscrambled Data

急いで移動しているデータ| +-----------------------------------------------+ | | | v| +-------------------------------------+ +---+ +->| -->43ビットシフトレジスタ-->。|、-、--、>|xor| +-------------------------------------+ +---+ | Unscrambled Dataに対して

   Note: While the HDLC FCS is calculated least significant bit first as
   shown:

以下に注意してください。 HDLC FCSは最初に、示されるように計算された最下位ビットですが:

              <-  <-  <-  <-
              A   B   C   D

<<<<B C D

   (that is, the FCS calculator is fed as follows: A[0], A[1], ... A[7],
   B[0], B[1], etc...),  scrambling is done in the opposite manner, most
   significant bit first, as shown:

(すなわち、計算機が以下の通り与えられているFCS: A[0]、A[1]、…A[7]、B[0]、B[1]など)、反対の方法でよじ登ることをして、最上位ビットは1番目です、示されるように:

               ->  ->  ->  ->
               A   B   C   D.

->->->->A B C D。

   That is, the scrambler is fed as follows: A[7], A[6], ... A[0], B[7],
   B[6], etc...

すなわち、秘話装置を以下の通りに与えます: A[7]、A[6]… A[0]、B[7]、B[6]など。

   The scrambler operates continuously through the bytes of the SONET
   STS-SPE/SDH Higher Order VC, bypassing bytes of SONET Path Overhead
   and any fixed stuff (see Figure 20 of ANSI T1.105 [3] or Figure 10-17
   of ITU G.707 [5]).  The scrambling state at the beginning of a SONET
   STS-SPE/SDH Higher Order VC is the state at the end of the previous
   SONET STS-SPE/SDH Higher Order VC.  Thus, the scrambler runs
   continuously and is not reset per frame. The initial seed is randomly
   chosen by transmitter to improve operational security (see Section
   6).  Consequently, the first 43 transmitted bits following startup or
   reframe operation will not be descrambled correctly.

秘話装置はSonet STS-SPE/SDH Higher Order VCのバイトを通して絶え間なく作動します、バイトのSonet Path Overheadとどんな固定ものも迂回させて。(ANSI T1.105[3]の図20かITU G.707[5])の図10-17を見てください。 Sonet STS-SPE/SDH Higher Order VCの始めのよじ登る状態は前のSonet STS-SPE/SDH Higher Order VCの端の状態です。 したがって、秘話装置は、絶え間なく動いて、フレーム単位でリセットされません。 初期の種子は、操作上のセキュリティを向上させるために送信機によって手当たりしだいに選ばれています(セクション6を見てください)。 その結果、最初の43は、始動に続いて、ビットを伝えるか、または操作を再構成します。正しく、反急いで移動しないでしょう。

Malis & Simpson             Standards Track                     [Page 5]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[5ページ]。

5.  Configuration Details

5. 構成の詳細

   Other than the FCS length (see below), the standard LCP sync
   configuration defaults apply to SONET/SDH links.

FCSの長さ(以下を見る)を除いて、標準のLCP同時性構成デフォルトはSonet/SDHリンクに適用されます。

   The following Configuration Options are RECOMMENDED for STS-3c-
   SPE/VC-4:

以下のConfiguration OptionsはSTS-3c- SPE/VC-4のためのRECOMMENDEDです:

      Magic Number
      No Address and Control Field Compression
      No Protocol Field Compression

マジックナンバーいいえアドレスと制御フィールド圧縮いいえプロトコル分野圧縮

   For operation at STS-12c-SPE/VC-4-4c and above, Address and Control
   Field Compression and Protocol Field Compression are NOT RECOMMENDED.
   The Magic Number option remains RECOMMENDED.

操作のために、Address、Control Field Compression、およびプロトコルField CompressionはSTS-12c-SPE/VC-4-4cにおける上では、NOT RECOMMENDEDです。 マジックNumberオプションはRECOMMENDEDのままで残っています。

   Regarding the FCS length, with one exception, the 32-bit FCS MUST be
   used for all SONET/SDH rates. For STS-3c-SPE/VC-4 only, the 16-bit
   FCS MAY be used, although the 32-bit FCS is RECOMMENDED.  The FCS
   length is set by provisioning and is not negotiated.

FCSの長さの1つの例外による32ビットFCS MUSTを見なして、すべてのSonet/SDHレートに使用されてください。 STS-3c-SPE/VC-4だけに関しては、16ビットのFCS MAYが使用されて、32ビットですが、FCSはRECOMMENDEDです。 FCSの長さは、食糧を供給することによって設定されて、交渉されません。

6.  Security Considerations

6. セキュリティ問題

   The major change from RFC 1619 is the addition of payload scrambling
   when inserting the HDLC-like framed PPP packets into the SONET STS-
   SPE/SDH Higher Order VC.  RFC 1619 was operationally found to permit
   malicious users to generate packets with bit patterns that could
   create SONET/SDH-layer low-transition-density synchronization
   problems, emulation of the SDH set-reset scrambler pattern, and
   replication of the STM-N frame alignment word.

HDLCのような縁どられたPPPパケットをSonet STS- SPE/SDH Higher Order VCに挿入するとき、RFC1619からの大きな変化はペイロードのよじ登ることの添加です。 RFC1619は悪意あるユーザーがSDH-層の低変遷Sonet/密度同期問題、SDHセットリセット秘話装置パターンのエミュレーションを作成できたビット・パターン、およびSTM-Nフレーム整列単語の模写でパケットを発生させるのを許容するのが操作上わかりました。

   The use of the x^43 + 1 self-synchronous scrambler was introduced to
   alleviate these potential security problems.  Predicting the output
   of the scrambler requires knowledge of the 43-bit state of the
   transmitter as the scrambling of a known input is begun.  This
   requires knowledge of both the initial 43-bit state of the scrambler
   when it started and every byte of data scrambled by the device since
   it was started.  The odds of guessing correctly are 1/2**43, with the
   additional probability of 1/127 that a correct guess will leave the
   frame properly aligned in the SONET/SDH payload, which results in a
   probability of 9e-16 against being able to deliberately cause
   SONET/SDH-layer problems.  This seems reasonably secure for this
   application.

これらの潜在的警備上の問題を軽減するためにx^43+1の自己同期の秘話装置の使用を導入しました。既知入力をよじ登ることが始められるとき、秘話装置の出力を予測するのは送信機の43ビットの状態に関する知識を必要とします。 これはそれが始まった秘話装置の初期の43ビットの状態とそれが始められて以来装置によって急いで移動させられるあらゆるバイトのデータの両方に関する知識を必要とします。 正しく推量する可能性は1/2**43です、故意にSDH Sonet/層の問題を引き起こすことができることに対して正しい推測がフレームをSonet/SDHペイロードで適切に並べられたままにするという1/127の追加確率で。ペイロードは9e-16の確率をもたらします。これはこのアプリケーションには合理的に安全に見えます。

   This scrambler is also used when transmitting ATM over SONET/SDH, and
   public network carriers have considerable experience with its use.

また、Sonet/SDHの上にATMを伝えるとき、この秘話装置は使用されます、そして、公衆通信回線キャリヤーは使用で経験に富みます。

Malis & Simpson             Standards Track                     [Page 6]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[6ページ]。

   A known security issue is bandwidth reduction by intentional
   transmission of characters or sequences requiring transparency
   processing by including flag and/or escape characters in user data. A
   user may cause up to a 100% increase in the bandwidth required for
   transmitting his or her packets by filling the packet with flag
   and/or escape characters.

利用者データに旗、そして/または、拡張文字を含んでいることによって透明処理を必要とするキャラクタか系列の意図的な送信で知られている安全保障問題は帯域幅削減です。 ユーザは帯域幅の増加が旗、そして/または、拡張文字でパケットを満たすことによってその人のパケットを伝えるために必要とした%を100まで引き起こすかもしれません。

7.  Changes from RFC 1619

7. RFC1619からの変化

   As mentioned in the previous section, the major change from RFC 1619
   was the addition of payload scrambling when inserting the HDLC-like
   framed PPP packets into the SONET STS-SPE/SDH Higher Order VC.  Other
   changes were:

HDLCのような縁どられたPPPパケットをSonet STS-SPE/SDH Higher Order VCに挿入するとき、前項で言及されるように、RFC1619からの大きな変化はペイロードのよじ登ることの添加でした。 他の変化は以下の通りでした。

   The terminology was updated to better match that used by ANSI and
   ITU-T.

より一層ANSIとITU-Tによって使用されるそれを合わせるために用語をアップデートしました。

   The specification's applicability is now specifically restricted to:

仕様の適用性は現在、以下のことのために明確に制限されます。

       SONET                   SDH
   ----------------------------------------
   STS-3c-SPE                  VC-4
   STS-12c-SPE                 VC-4-4c
   STS-48c-SPE                 VC-4-16c
   STS-192c-SPE                VC-4-64c

Sonet SDH---------------------------------------- STS-3c-SPE VC-4 STS-12c-SPE VC-4-4c STS-48c-SPE VC-4-16c STS-192c-SPE VC-4-64c

   The Path Signal Label (C2) is set to 22 (16 hex) when using X^43 + 1
   scrambling.

X^43+1のよじ登ることを使用するとき、Path Signal Label(C2)は22(16十六進法)に用意ができています。

   The 32-bit FCS is required except for operation with STS-3c-SPE/VC-4,
   in which case the 16-bit FCS is allowed (but the 32-bit FCS is still
   recommended).

STS-3c-SPE/VC-4とのFCSが必要である32ビット操作、その場合、16ビットのFCSは許容されています(32ビットのFCSはまだお勧めです)。

   The Security Considerations section was added.

Security Considerations部は加えられました。

8.  Intellectual Property

8. 知的所有権

   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

IETFはどんな知的所有権の正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 どちらも、それはそれを表しません。いずれもどんなそのような権利も特定するための努力にしました。 BCP-11で標準化過程の権利と規格関連のドキュメンテーションに関するIETFの手順に関する情報を見つけることができます。 公表に利用可能にされた権利のクレームと利用可能に作られるべきライセンスのどんな保証のコピー、または一般的なライセンスか許可をそのようなものの使用に得るのがされた試みの結果

Malis & Simpson             Standards Track                     [Page 7]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[7ページ]。

   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

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専務に情報を記述してください。

9.  Acknowledgments

9. 承認

   The scrambler description was provided by J. Manchester, S. Davida,
   B. Doshi, and J. Anderson of Lucent Technologies, R. Broberg of Cisco
   Systems, and Peter Lothberg of Sprint Corporation.  The security
   analysis was provided by Iain Verigin of PMC-Sierra and Larry McAdams
   of Cisco Systems.  The authors would also like to thank the members
   of the IETF's Point-to-Point Protocol Extensions Working Group for
   their many suggestions and improvements to the text.

秘話装置記述はJ.マンチェスター、S.ダビダ、B.ドーシ、およびJ.のルーセントテクノロジーズのアンダーソン、シスコシステムズのR.Broberg、およびスプリント社のピーターLothbergによって提供されました。 証券分析はPMC-連峰のイアンVeriginとシスコシステムズのラリーMcAdamsによって前提とされました。また、作者はテキストへの彼らの多くの提案と改良についてIETFのPointからポイントへのプロトコルExtensions作業部会のメンバーに感謝したがっています。

10.  References

10. 参照

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, Daydreamer, July 1994.

[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、空想家、1994年7月。

   [2]   Simpson, W., Editor, "PPP in HDLC-like Framing", STD 51, RFC
         1662, Daydreamer, July 1994.

[2] シンプソン、W.、エディタ、「HDLCのような縁どりにおけるppp」、STD51、RFC1662、空想家、1994年7月。

   [3]   American National Standards Institute, "Synchronous Optical
         Network (SONET) - Basic Description including Multiplex
         Structure, Rates and Formats," ANSI T1.105-1995.

[3] American National Standards Institut、「同期式光通信網(Sonet)--Multiplex Structureを含む基本的な記述、RatesとFormats、」、ANSI T1.105-1995。

   [4]   American National Standards Institute, "Synchronous Optical
         Network (SONET)--Payload Mappings," T1.105.02-1998.

[4] American National Standards Institut、「同期式光通信網(Sonet)--、有効搭載量マッピング、」、T1.105.02-1998。

   [5]   ITU Recommendation G.707, "Network Node Interface For The
         Synchronous Digital Hierarchy", 1996.

[5] ITU推薦G.707、「同期デジタルハイアラーキのためのネットワーク・ノードインタフェース」、1996。

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

[6] ブラドナー、S.、「使用のためのRequirement Levelsを示すRFCsのキーワード」、BCP14、RFC2119、1997年3月。

Malis & Simpson             Standards Track                     [Page 8]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[8ページ]。

11.  Authors' Addresses

11. 作者のアドレス

   Andrew G. Malis
   Ascend Communications, Inc.
   1 Robbins Road
   Westford, MA 01810 USA

アンドリューG.MalisはCommunications Inc.1ロビンスRoadウェストフォード(MA)01810米国を昇ります。

   Phone: +1 978 952 7414
   EMail: malis@ascend.com

以下に電話をしてください。 +1 7414年の978 952メール: malis@ascend.com

   William Allen Simpson
   DayDreamer
   Computer Systems Consulting Services
   1384 Fontaine
   Madison Heights, Michigan  48071

ミシガン ウィリアムアレンのシンプソン空想家コンピュータシステムズのコンサルタント業務1384フォンテーヌマディソンの高さ、48071

   EMail: wsimpson@GreenDragon.com

メール: wsimpson@GreenDragon.com

Malis & Simpson             Standards Track                     [Page 9]

RFC 2615                  PPP over SONET/SDH                   June 1999

MalisとシンプソンStandardsは1999年6月にSonet/SDHの上でRFC2615pppを追跡します[9ページ]。

12.  Full Copyright Statement

12. 完全な著作権宣言文

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

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

Malis & Simpson             Standards Track                    [Page 10]

Malisとシンプソン標準化過程[10ページ]

一覧

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

スポンサーリンク

CHARACTER_LENGTH関数 文字列長を求める

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

上に戻る