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ページ]
一覧
スポンサーリンク