RFC3336 日本語訳
3336 PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2). B.Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT=33631 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group B. Thompson
Request for Comments: 3336 T. Koren
Category: Standards Track Cisco Systems
B. Buffam
Seaway Networks
December 2002
コメントを求めるワーキンググループB.トンプソン要求をネットワークでつないでください: 3336年のT.コーレンカテゴリ: 規格は2002年12月にシスコシステムズB.Buffam海路ネットワークを追跡します。
PPP Over Asynchronous Transfer Mode Adaptation Layer 2 (AAL2)
非同期通信モード適合層2の上のppp(AAL2)
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
要約
The Point-to-Point Protocol (PPP) provides a standard method for transporting multi-protocol datagrams over point-to-point links.
Pointからポイントへのプロトコル(PPP)はポイントツーポイント接続の上でマルチプロトコルデータグラムを輸送するための標準方法を提供します。
This document describes the use of ATM Adaptation Layer 2 (AAL2) for framing PPP encapsulated packets.
縁どりPPPがパケットをカプセルに入れったので、このドキュメントはATM Adaptation Layer2(AAL2)の使用について説明します。
Applicability
適用性
This specification is intended for those implementations which desire to use the facilities which are defined for PPP, such as the Link Control Protocol, Network-layer Control Protocols, authentication, and compression. These capabilities require a point-to-point relationship between the peers, and are not designed for the multi- point relationships which are available in ATM and other multi-access environments.
この仕様はPPPのために定義される施設を使用するそれの願望がLink ControlプロトコルなどのようにControlプロトコル、認証をNetwork層にするそれらの実現と圧縮のために意図します。 これらの能力は、同輩の間の二地点間関係を必要として、ATMと他のマルチアクセス環境で利用可能なマルチポイント関係のために設計されていません。
Thompson, et. al. Standards Track [Page 1] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[1ページ]RFC3336ppp
1. Introduction
1. 序論
PPP over AAL5 [2] describes the encapsulation format and operation of PPP when used with the ATM AAL5 adaptation layer. While this encapsulation format is well suited to PPP transport of IP, it is bandwidth inefficient when used for transporting small payloads such as voice. PPP over AAL5 is especially bandwidth inefficient when used with RTP header compression [3].
ATM AAL5適合層と共に使用されると、AAL5[2]の上のPPPはPPPのカプセル化形式と操作について説明します。 このカプセル化形式はIPのPPP輸送によく合っていますが、声などのわずかなペイロードを輸送するのに使用されると、それは帯域幅効率が悪いです。 RTPヘッダー圧縮[3]と共に使用されると、AAL5の上のPPPは帯域幅特に効率が悪いです。
PPP over AAL2 addresses the bandwidth efficiency issues of PPP over AAL5 for small packet transport by making use of the AAL2 Common Part Sublayer (CPS) [4] to allow multiple PPP payloads to be multiplexed into a set of ATM cells.
AAL2 Common Part Sublayer(CPS)[4]を利用するのによる小型小包輸送が、複数のPPPペイロードが1セットのATMセルの中に多重送信されるのを許容するように、AAL2の上のPPPはAAL5の上にPPPの帯域幅効率問題を記述します。
2. Conventions
2. コンベンション
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this document, are to be interpreted as described in [6].
キーワードが解釈しなければならない、本書では現れるとき、[6]で説明されるようにNOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、5月、およびOPTIONALを解釈することになっていなければなりませんか?
3. AAL2 Layer Service Interface
3. AAL2層のサービスインタフェース
The PPP layer treats the underlying ATM AAL2 layer service as a bit- synchronous point-to-point link. In this context, the PPP link corresponds to an ATM AAL2 virtual connection. The virtual connection MUST be full-duplex, point to point, and it MAY be either dedicated (i.e., permanent, set up by provisioning) or switched (set up on demand). In addition, the PPP/AAL2 service interface boundary MUST meet the following requirements.
PPP層は基本的なATM AAL2層のサービスを少し同期のポイントツーポイント接続として扱います。 このような関係においては、PPPリンクはATM AAL2仮想接続に文通されます。 仮想接続が全二重、ポイント・ツー・ポイントでなければならなく、それは、捧げられるか(すなわち、永久的であることで、食糧を供給することによって、セットアップしてください)、または切り換えられるかもしれません(要求に応じてセットアップしてください)。 さらに、PPP/AAL2サービスインタフェース境界は以下の必要条件を満たさなければなりません。
Interface Format - The PPP/AAL2 layer boundary presents an octet
service interface to the AAL2 layer. There is no provision for
sub-octets to be supplied or accepted.
インタフェースFormat--PPP/AAL2層の境界は八重奏サービスインタフェースをAAL2層に提示します。 サブ八重奏を供給するか、または受け入れるために、支給は全くありません。
Transmission Rate - The PPP layer does not impose any
restrictions regarding transmission rate on the underlying ATM
layer traffic descriptor parameters.
トランスミッションRate--PPP層は基本的なATM層の交通記述子パラメタに通信速度に関する少しの制限も課しません。
Control Signals - The AAL2 layer MUST provide control signals to
the PPP layer which indicate when the virtual connection link has
become connected or disconnected. These provide the "Up" and
"Down" events to the LCP state machine [1] within the PPP layer.
コントロールSignals--AAL2層はPPP層への仮想接続リンクがいつ接続されるようになるか、または連絡を断ったかを示す制御信号を提供しなければなりません。 これらはPPP層の中のLCP州のマシン[1]に“Up"と“Down"出来事を供給します。
In the case of PPP over AAL2, the state of the link can be derived
from the type 3 fault management packets carried in-band within a
given AAL2 CID flow.
AAL2の上のPPPの場合では、3つの障害管理パケットが運んだタイプから与えられたAAL2 CID流動の中でバンドでリンクの状態を得ることができます。
Thompson, et. al. Standards Track [Page 2] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[2ページ]RFC3336ppp
4. PPP Operation with AAL2
4. AAL2とのppp操作
PPP over AAL2 defines an encapsulation that uses the Service Specific Segmentation and Reassembly Sublayer (SSSAR) [5] for AAL type 2. The SSSAR sub-layer is used to segment PPP packets into frames that can be transported using the AAL2 CPS. The SSSAR sub-layer uses different AAL2 UUI code-points to indicate whether a segment is the last segment of a packet or not.
AAL2の上のPPPはService Specific Segmentationを使用するカプセル化を定義します、そして、AALのためのReassembly Sublayer(SSSAR)[5]は2をタイプします。 SSSAR副層はAAL2 CPSを使用することで輸送できるフレームへのセグメントPPPパケットに使用されます。SSSAR副層は、セグメントがパケットの最後のセグメントであるかどうかを示すのに異なったAAL2 UUIコード・ポイントを使用します。
The encapsulation of PPP over AAL2 provides a 16-bit CRC for PPP payloads. There are 2 UUI code points assigned from SSSAR to indicate intermediate fragments of a packet and the last fragment of a packet. Code point 27 indicates intermediate frames of a fragmented packet and code point 26 indicates the last frame of a packet. The encapsulation format is more fully described in section 6.2.1.
AAL2の上のPPPのカプセル化は16ビットのCRCをPPPペイロードに供給します。 パケットの中間的断片とパケットの最後の断片を示すためにSSSARから割り当てられた2つのUUIコード・ポイントがあります。 コード・ポイント27は断片化しているパケットの中間的フレームを示します、そして、コード・ポイント26はパケットの最後のフレームを示します。 カプセル化形式はセクション6.2.1において、より完全に説明されます。
An implementation of PPP over AAL2 MAY use one or more AAL2 Channel Identifiers (CIDs) for transport of PPP packets associated with each PPP session. Multiple CIDs could be used to implement a multiple class real time transport service for PPP using the AAL2 layer for link fragmentation and interleaving. A companion document [10] describes class extensions for PPP over AAL2 using multiple AAL2 CIDs.
AAL2 MAY使用1の上のPPPかPPPパケットの輸送のための、より多くのAAL2 Channel Identifiers(CIDs)の実現はそれぞれのPPPセッションと交際しました。 PPPのためにリンク断片化とインターリービングのためのAAL2層を使用することで複数のクラスリアルタイムで輸送サービスを実行するのに複数のCIDsを使用できました。 仲間ドキュメント[10]は、PPPのためにAAL2の上で複数のAAL2 CIDsを使用することでクラス拡大について説明します。
5. Comparison of PPP Over AAL2 with Existing Encapsulations
5. 既存のカプセル化があるAAL2の上のpppの比較
This document proposes the substitution of AAL2 transport for PPP in scenarios where small packets are being transported over an ATM network. This is most critical in applications such as voice transport using RTP [9] where RTP Header compression [3] is used. In applications such as voice transport, both bandwidth efficiency and low delay are very important.
このドキュメントはPPPのために小型小包がATMネットワークの上で輸送されているシナリオでAAL2輸送の代替を提案します。 これは、声の輸送などの応用でRTP Header圧縮[3]が使用されているところでRTP[9]を使用することで最も批判的です。 声の輸送などの応用では、帯域幅効率と低い遅れの両方が非常に重要です。
This section provides justification for the PPP over AAL2 service for ATM transport by comparing it to existing PPP encapsulation formats used for transport over ATM. Two encapsulation formats will be examined here: PPP over AAL5 [2], and PPP with PPPMUX [8] over AAL5.
このセクションは、ATM輸送のためのAAL2サービスの上でATMの上の輸送に使用される既存のPPPカプセル化形式とそれを比較することによって、正当化をPPPに供給します。 2つのカプセル化形式がここで調べられるでしょう: AAL5[2]の上のppp、およびAAL5の上のPPPMUX[8]があるppp。
5.1 Comparison With PPP Over AAL5
5.1 AAL5の上のpppとの比較
This proposal uses ATM AAL2 [4] rather than AAL5 as the transport for PPP. SSSAR along with the AAL2 CPS generates less ATM encapsulation overhead per PPP payload. The payload encapsulation consists of a 2 byte CRC. The AAL2 CPS header consists of 3 bytes, and the AAL2 Start Field (STF) is 1 byte. This is a total encapsulation overhead of 6 bytes. This compares to 8 bytes of overhead for the AAL5 trailer used for PPP over AAL5.
この提案はPPPに輸送として[4] AAL5よりむしろATM AAL2を使用します。 AAL2 CPSに伴うSSSARは、より少ないPPPペイロードあたりのATMカプセル化オーバーヘッドを発生させます。 ペイロードカプセル化は2バイトのCRCから成ります。 AAL2 CPSヘッダーは3バイトから成ります、そして、AAL2 Start Field(STF)は1バイトです。 これは6バイトの総カプセル化オーバーヘッドです。 これはPPPにAAL5の上で使用されるAAL5トレーラのために8バイトのオーバーヘッドと比較されます。
Thompson, et. al. Standards Track [Page 3] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[3ページ]RFC3336ppp
The multiplexing function of the AAL2 CPS layer allows more bandwidth efficient transport of PPP frames by multiplexing multiple PPP frames into one or more ATM cells using the AAL2 CPS function. This removes the pad overhead of AAL5 when used to transport short frames.
AAL2 CPS層のマルチプレクシング関数は、AAL2 CPS機能を使用することで1つ以上のATMセルの中に複数のPPPフレームを多重送信することによって、PPPフレームの、より多くの帯域幅の効率的な輸送を許容します。 短いフレームを輸送するのに使用されると、これはAAL5のパッドオーバーヘッドを取り除きます。
5.2 Comparison with PPPMUX over AAL5
5.2 AAL5の上のPPPMUXとの比較
PPP Multiplexing (PPPMUX) [8] is a new method for doing multiplexing in the PPP layer. PPPMUX provides functionality similar to the CPS based multiplexing function of AAL2. Using PPP multiplexing, a PPP stack would look like PPP/PPPMUX/AAL5.
PPP Multiplexing(PPPMUX)[8]は、PPP層の中でマルチプレクシングをするための新しい方法です。 PPPMUXはAAL2のCPSのベースのマルチプレクシング機能と同様の機能性を提供します。 PPPマルチプレクシングを使用して、PPPスタックはPPP/PPPMUX/AAL5に似ているでしょう。
Both PPP/PPPMUX/AAL5 and PPP/AAL2 use multiplexing to reduce the overhead of cell padding when frames are sent over an ATM virtual circuit. However, the bandwidth utilization of PPP/AAL2 will typically be better than the bandwidth used by PPP/PPPMUX/AAL5. This is because multiplexed frames in PPP/PPPMUX/AAL5 must always be encapsulated within an AAL5 frame before being sent. This encapsulation causes an additional 8 bytes of AAL5 trailer to be added to the PPPMUX encapsulation. In addition to the 8 bytes of AAL5 trailer, PPPMUX will incur an average of 24 additional bytes of AAL5 PAD. These 2 factors will end up reducing the effective efficiency of PPPMUX when it is used over AAL5.
PPP/PPPMUX/AAL5とPPP/AAL2の両方が、ATMの仮想のサーキットの上にフレームを送るとき、セル詰め物のオーバーヘッドを下げるのにマルチプレクシングを使用します。 しかしながら、PPP/AAL2の帯域幅利用はPPP/PPPMUX/AAL5によって使用された帯域幅より通常良くなるでしょう。 これは送る前にAAL5フレームの中にいつもPPP/PPPMUX/AAL5の多重送信されたフレームを要約しなければならないからです。 このカプセル化で、追加8バイトのAAL5トレーラをPPPMUXカプセル化に加えます。 8バイトのAAL5トレーラに加えて、PPPMUXは追加平均24バイトのAAL5 PADを被るでしょう。 それが結局AAL5の上で使用されるとき、これらの2つの要素がPPPMUXの有効な効率を減少させるでしょう。
With PPP/AAL2, the AAL2 CPS layer treats individual PPP frames as a series of CPS payloads that can be multiplexed. As long as PPP frames arrive at the CPS layer before the CPS TIMER_CU expires, all ATM cells coming from the CPS layer will be filled. Under these conditions, PPP/AAL2 will have no PAD associated with it. When the AAL2 CPS function causes no PAD to be generated, PPP/AAL2 will be more bandwidth efficient than PPP/PPPMUX/AAL5.
PPP/AAL2と共に、AAL2 CPS層は多重送信できる一連のCPSペイロードとして個々のPPPフレームを扱います。 CPS TIMER_CUが期限が切れる前にPPPフレームがCPS層に届く限り、CPS層から来るすべてのATMセルがいっぱいにされるでしょう。 これらの条件で、PPP/AAL2には、それに関連しているどんなPADもないでしょう。 AAL2 CPS機能でPADを全く発生させないとき、PPP/AAL2はPPP/PPPMUX/AAL5よりさらに多くの帯域幅効率的になるでしょう。
In PPP/PPPMUX/AAL5, the AAL5 SAR and the PPP MUX/DEMUX are performed in two different layers. Thus, the PPPMUX/AAL5 receiver must reassemble a full AAL5 frame from the ATM layer before the PPPMUX layer can extract the PPP payloads. To derive maximum PPP Multiplexing efficiency, many PPP payloads may be multiplexed together. This increases the size of the multiplexed frame to many ATM cells. If one of these ATM cells is lost, the whole PPPMUX packet will be discarded. Also, there may be a significant delay incurred while the AAL5 layer waits for many ATM cell arrival times until a full frame has been assembled before the full frame is passed up to the PPP Multiplexing layer where the inverse PPP demux then occurs. This same issue also applies to PPPMUX/AAL5 frames progressing down the stack.
PPP/PPPMUX/AAL5では、AAL5 SARとPPP MUX/DEMUXは2つの異なった層で実行されます。 したがって、PPPMUX層がPPPペイロードを抽出できる前にPPPMUX/AAL5受信機はATM層から完全なAAL5フレームを組み立て直さなければなりません。 最高のPPP Multiplexing効率を引き出すために、多くのPPPペイロードを一緒に多重送信するかもしれません。 これは多くのATMセルに多重送信されたフレームのサイズを増加させます。 これらのATMセルの1つが無くなると、全体のPPPMUXパケットは捨てられるでしょう。 また、PPP Multiplexing層まで通り過ぎられる前に完全なフレームが組み立てられるまでAAL5層が多くのATMセル到着時間の間待っていますが、被られた重要な遅れが次に逆さのPPP demuxが起こるところにあるかもしれません。 また、この同じ問題はスタックの下で進歩をするPPPMUX/AAL5フレームに適用されます。
Thompson, et. al. Standards Track [Page 4] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[4ページ]RFC3336ppp
With AAL2, both the segmentation and reassembly and multiplexing functions are performed in the AAL2 CPS layer. Because of the definition of the AAL2 CPS function, a multiplexed payload will be extracted as soon as it is received. The CPS receiver does not wait until the many payloads of an AAL2 multiplexed frame are received before removing payloads from the multiplexed stream. The same benefit also applies to AAL2 CPS sender implementations. Also, the loss of an ATM cell causes the loss of the packets that are included in that cell only.
AAL2と共に、分割と再アセンブリとマルチプレクシング機能の両方がAAL2 CPS層の中で実行されます。 AAL2 CPS機能の定義のために、それが受け取られているとすぐに、多重送信されたペイロードは抽出されるでしょう。 多重送信された流れからペイロードを取り外す前に、AAL2の多くのペイロードがフレームを多重送信するまでの待ちではなく、受信機がするCPSを受け取ります。 また、同じ利益はAAL2 CPS送付者実現に申請されます。 また、ATMセルの損失が、そのセルだけに含まれているパケットの損失をもたらします。
The AAL2 CPS function provides multiplexing in AAL2. This function often needs to be implemented in hardware for performance reasons. Because of this, a PPP/AAL2 implementation that takes advantage of an AAL2 SAR implemented in hardware will have significant performance benefits over a PPP/PPPMUX/AAL5 implementation where PPPMUX is implemented in software. Also, the AAL2 specification has been available significantly longer than the PPP Multiplexing specification and because of this, optimized software and hardware implementations of the AAL2 CPS function are further in development than PPP Multiplexing implementations.
AAL2 CPS機能はマルチプレクシングをAAL2に供給します。 この機能は、しばしば性能理由によるハードウェアで実行される必要があります。 これのために、PPPMUXがソフトウェアで実行されるところにハードウェアで実行されたAAL2 SARを利用するPPP/AAL2実現はPPP/PPPMUX/AAL5実現の上に重要な性能利益を持つでしょう。 また、AAL2仕様は利用可能なかなり長いPPP Multiplexing実現より遠いこれによるAAL2 CPS機能のPPP Multiplexing仕様、最適化されたソフトウェア、およびハードウェア実装より開発です。
6. Detailed Protocol Operation Description
6. 詳細なプロトコル操作記述
6.1 Background
6.1 バックグラウンド
6.1.1 AAL2 Multiplexing
6.1.1 AAL2マルチプレクシング
ITU-T I.363.2 specifies ATM Adaptation Layer Type 2. This AAL type provides for bandwidth efficient transmission of low-rate, short and variable length packets in delay sensitive applications. More than one AAL type 2 user information stream can be supported on a single ATM connection. There is only one definition for the sub-layer because it implements the interface to the ATM layer and is shared by more than one SSCS layer.
ITU-T I.363.2はATM Adaptation Layer Type2を指定します。 このAALタイプは遅れで低レートの、そして、短くて可変な長さのパケットの帯域幅の効率的なトランスミッションに敏感な利用を提供します。 単独のATM接続のときに1つ以上のAALタイプ2ユーザー情報ストリームを支持できます。 それがATM層にインタフェースを実行して、1つ以上のSSCS層によって共有されるので、副層のための1つの定義しかありません。
6.1.2 AAL2 Service Specific Convergence Sub-layers
6.1.2 AAL2のサービスの特定の集合副層
ITU-T I.366.1 and I.366.2 define Service Specific Convergence Sub- layers (SSCS) that operate above the Common Part Sub-layer defined in I.363.2. This layer specifies packet formats and procedures to encode the different information streams in bandwidth efficient transport. As the name implies, this sub-layer implements those elements of service specific transport. While there is only one definition of the Common Part Sublayer for AAL2, there can be multiple SSCS functions defined to run over this CPS layer. Different CIDs within an AAL2 virtual circuit may run different SSCSs.
ITU-TのI.366.1とI.366.2はI.363.2で定義されたCommon Part Sub-層を超えて作動するService Specific Convergence Sub層(SSCS)を定義します。 この層は、帯域幅の効率的な輸送における異なった情報ストリームをコード化するためにパケット・フォーマットと手順を指定します。 名前が含意するように、サービス特有のそれらの要素の道具が輸送するこの副層です。 AAL2のためのCommon Part Sublayerの1つの定義しかない間、このCPS層をひくために定義された複数のSSCS機能があることができます。 AAL2の仮想のサーキットの中の異なったCIDsは異なったSSCSsを走らせるかもしれません。
Thompson, et. al. Standards Track [Page 5] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[5ページ]RFC3336ppp
6.1.3 AAL2 CPS Packet (CPS-PKT) Format
6.1.3 AAL2 CPSパケット(CPS-PKT)形式
The CPS-PKT format over AAL2 as defined in I.363.2:
I.363.2で定義されるAAL2の上のCPS-PKT形式:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + | | CID + LI + UUI + HEC + CPS-INFO | | + + + + | | + + + + | | (8) + (6) + (5) + (5) + (45/64 * 8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + | | CPS Cid+李+UUI+HEC+インフォメーション| | + + + + | | + + + + | | (8) + (6) + (5) + (5) + (45/64 * 8) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The size of the fields denote bit-width
以下に注意してください。 分野のサイズはビット-幅を指示します。
The Channel ID (CID) identifies the sub-stream within the AAL2 connection. The Length indication (LI) indicates the length of the CPS-INFO payload. The User-to-User Indication (UUI) carries information between the SSCS/Application running above the CPS. The SSSAR sub-layer as defined in I.366.1 uses the following code points:
英仏海峡ID(CID)はAAL2接続の中でサブの流れを特定します。 Length指示(LI)はCPS-INFOペイロードの長さを示します。 UserからユーザへのIndication(UUI)はCPSの上を走るSSCS/アプリケーションの間まで情報を運びます。I.366.1で定義されるSSSAR副層は以下のコード・ポイントを使用します:
UUI Code-point Packet Content
++++++++++++++ ++++++++++++++
UUIコード・ポイントパケット内容++++++++++++++++++++++++++++
0-26 Framed mode data, final packet.
0-26 縁どられたモードデータ、最終的なパケット。
27 Framed mode data, more to come.
27は、さらに来るためにモードデータを縁どりました。
This proposal uses two UUI code-points as follows:
この提案は以下の2つのUUIコード・ポイントを使用します:
UUI Code-point Packet Content
++++++++++++++ ++++++++++++++
UUIコード・ポイントパケット内容++++++++++++++++++++++++++++
27 non-final packet.
27の非最終的なパケット。
26 final packet.
26の最終的なパケット。
Thompson, et. al. Standards Track [Page 6] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[6ページ]RFC3336ppp
6.1.4 AAL2 CPS-PDU Format
6.1.4 AAL2 CPS-PDU形式
The CPS-PDU format over AAL2 as defined in I.363.2:
I.363.2で定義されるAAL2の上のCPS-PDU形式:
+-+-+-+~+~+-+-+
|CPS| CPS-INFO|
|PKT| |
|HDR| |
+-+-+-+~+~+-+-+
| CPS-PKT |
+-+-+-+~+~+-+-+ |CPS| CPS-インフォメーション| |PKT| | |HDR| | +-+-+-+~+~+-+-+ | CPS-PKT|
| +-+-+-+~+~+-+-+
|CPS| CPS-INFO|
| |PKT| |
|HDR| |
| +-+-+-+~+~+-+-+
CPS-PKT
| | +-+-+-+~+~+-+-+
|CPS| CPS-INFO|
| | |PKT| |
|HDR| |
| | +-+-+-+~+~+-+-+
CPS-PKT
V V V V
+-+-+-+-+-+-+-+~+~+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Cell | | | |
Header | STF | CPS-PDU Payload | PAD |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
| +-+-+-+~+~+-+-+ |CPS| CPS-インフォメーション| | |PKT| | |HDR| | | ++++~++~++CPS-PKT| | +-+-+-+~+~+-+-+ |CPS| CPS-インフォメーション| | | |PKT| | |HDR| | | | ++++~++~++CPS-PKT対+++++++対V V、-、+ ~+~+++++++++++++++++++++++++++、セル| | | | ヘッダー| STF| CPS-PDU有効搭載量| パッド| | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+~+~+
Note: The size of the fields denote bitwidth
以下に注意してください。 分野のサイズはbitwidthを指示します。
The CPS-PDU format is used to carry one or more CPS-PKT's multiplexed on a single CPS-PDU. The CPS header contains enough information to identify the CPS packets within a CPS-PDU. In the event of cell loss, the STF field is used to find the first CPS-PKT in the current cell.
1つを運ぶのにCPS-PDU形式を使用するか、または独身のCPS-PDUで、より多くのCPS-PKTを多重送信しました。 CPSヘッダーはCPS-PDUの中でCPSパケットを特定できるくらいの情報を含んでいます。 細胞消失の場合、STF分野は、現在のセルにおける最初のCPS-PKTを見つけるのに使用されます。
Thompson, et. al. Standards Track [Page 7] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[7ページ]RFC3336ppp
6.2 PPP Over AAL2 Encapsulation
6.2 AAL2カプセル化の上のppp
PPP encapsulation over AAL2 uses the AAL2 CPS with no change.
AAL2の上のPPPカプセル化は変化なしでAAL2 CPSを使用します。
Some PPP encapsulated protocols such as RTP header compression require that the link layer provide packet error detection. Because of this, PPP over AAL2 defines a 16-bit CRC that is used along with the SSSAR sub-layer of I.366.1 to provide packet error detection. The encapsulation format is described below.
いくらかのPPPがリンクレイヤがパケット誤り検出を提供する圧縮が必要とするRTPヘッダーなどのプロトコルを要約しました。 これのために、AAL2の上のPPPはパケット誤り検出を提供するのにI.366.1のSSSAR副層と共に使用される16ビットのCRCを定義します。 カプセル化形式は以下で説明されます。
6.2.1 PPP Payload Encapsulation Over AAL2 with 16-bit CRC (CRC-16).
6.2.1 16ビットのCRC(CRC-16)とAAL2の上のppp有効搭載量カプセル化。
The payload encapsulation of PPP appends a two byte CRC to each PPP frame before using the SSSAR layer to send the PPP packet as a series of AAL2 frames.
一連のAAL2フレームとしてPPPパケットを送るのにSSSAR層を使用する前に、PPPのペイロードカプセル化は2バイトのCRCをそれぞれのPPPフレームに追加します。
The format of a PPP over AAL2 packet is shown in the diagram below. Note that the diagram below shows the payload encapsulation when the packet is not segmented (UUI=26). When the PPP packet is segmented, the PPP Protocol ID, Information field, and CRC-16 fields will be split across multiple SSSAR frames. In this case, the UUI field will be set to 27 for all frames except the last frame. In the last frame, the UUI field will be set to 26.
AAL2パケットの上のPPPの書式は以下のダイヤグラムで示されます。 以下のダイヤグラムが、パケットがいつ区分されないかを(UUI=26)ペイロードカプセル化に示すことに注意してください。 PPPパケットが区分されるとき、PPP Protocol ID、情報分野、およびCRC-16分野は複数のSSSARフレームの向こう側に分けられるでしょう。 この場合、UUI分野は最後のフレーム以外のすべてのフレームのために27に設定されるでしょう。 最後のフレームでは、UUI分野は26に設定されるでしょう。
Payload Encapsulation +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + + + | | CID + LI + UUI + HEC + Protocol + + | | + + + + ID + Information + CRC-16 | | + + + + + + | | (8) + (6) + (5) + (5) + (8/16) + + (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
有効搭載量カプセル化++++++++++++++++++++++++++++++++++++| + + + + + + | | Cid+LI+UUI+HEC+プロトコル++| | + + + + ID+情報+CRC-16| | + + + + + + | | (8) + (6) + (5) + (5) + (8/16) + + (16) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The size of the fields denote bit-width
以下に注意してください。 分野のサイズはビット-幅を指示します。
The algorithms used for computing and verifying the CRC-16 field are identical to the algorithms specified for the Frame Check Sequence (FCS) field in Q.921 [13]. The algorithms from Q.921 are included in this section for ease of access.
CRC-16分野を計算して、確かめるのに使用されるアルゴリズムはQ.921[13]のFrame Check Sequence(FCS)分野に指定されたアルゴリズムと同じです。 Q.921からのアルゴリズムはアクセサリーの容易さのためのこのセクションに含まれています。
The CRC-16 field is filled with the value of a CRC calculation which is performed over the contents of the PPP packet, including the PPP Protocol ID and the information field. The CRC field shall contain the ones complement of the sum (modulo 2) of:
CRC-16分野はPPPパケットのコンテンツの上で実行されるCRC計算の値で満たされます、PPP Protocol IDと情報フィールドを含んでいて。 CRC分野は以下の合計(法2)のもの補数を含むものとします。
1) the remainder of x^k (x^15 + x^14 + ... + x + 1) divided (modulo
2) by the generator polynomial, where k is the number of bits of
the information over which the CRC is calculated; and
1) x^kの残り、(x^15+x^14+… (法2)をジェネレータ多項式に割ります。+x+1) (そこでは、kがCRCが計算される情報のビットの数です)。 そして
Thompson, et. al. Standards Track [Page 8] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[8ページ]RFC3336ppp
2) the remainder of the division (modulo 2) by the generator
polynomial of the product of x^16 by the information over which
the CRC is calculated.
2) CRCが計算される情報によるx^16の製品のジェネレータ多項式による分割(法2)の残り。
The CRC-16 generator polynomial is:
CRC-16ジェネレータ多項式は以下の通りです。
G(x) = x^16 + x^12 + x^5 + 1
G(x)はx^16+x^12+x^5+1と等しいです。
The result of the CRC calculation is placed with the least significant bit right justified in the CRC field.
CRC計算の結果はCRC分野で正当化される最下位ビット右に置かれます。
As a typical implementation at the transmitter, the initial content of the register of the device computing the remainder of the division is preset to all "1"s and is then modified by division by the generator polynomial (as described above) on the information over which the CRC is to be calculated; the ones complement of the resulting remainder is put into the CRC field.
送信機での典型的な実現として、分割の残りを計算する装置に関するレジスタの初期の内容がすべてにあらかじめセットされる、「1"s、ジェネレータによって分割によって変更されたその時がCRCが計算されることになっている情報に関する多項式(上で説明されるように)である、」、。 結果として起こる残りのもの補数をCRC分野に入れます。
As a typical implementation at the receiver, the initial content of the register of the device computing the remainder of the division is preset to all "1"s. The final remainder, after multiplication by x^16 and then division (modulo 2) by the generator polynomial of the serial incoming PPP packet (including the Protocol ID, the information and the CRC fields), will be 0001110100001111 (x^15 through x^0, respectively) in the absence of transmission errors.
受信機での典型的な実現として、分割の残りを計算する装置に関するレジスタの初期の内容はすべての"1"s"にあらかじめセットされます。 x^16の乗法の後の最終的な残りと次に、連続の入って来るPPPパケットのジェネレータ多項式による分割(法2)(Protocol ID、情報、およびCRC分野を含んでいる)は伝送エラーがないとき0001110100001111(それぞれx^0を通したx^15)でしょう。
6.3 Use of AAL2 CPS-PKT CIDs
6.3 AAL2 CPS-PKT CIDsの使用
An implementation of PPP over AAL2 MAY use a single AAL2 Channel Identifier (CID) or multiple CIDs for transport of all PPP packets. In order for the endpoints of a PPP session to work with AAL2, they MUST both agree on the number, SSCS mapping, and values of AAL2 CIDs that will be used for a PPP session. The values of AAL2 CIDs to be used for a PPP session MAY be obtained from either static provisioning in the case of a dedicated AAL2 connection (PVC) or from Q.2630.2 [7] signaling in the case of an AAL2 switched virtual circuit (SPVC or SVC).
AAL2 MAYの上のPPPの実現はすべてのPPPパケットの輸送に独身のAAL2 Channel Identifier(CID)か複数のCIDsを使用します。 AAL2と共に扱うPPPセッションの終点において整然とします、彼らはともにPPPセッションに使用されるAAL2 CIDsの数、SSCSマッピング、および値に同意しなければなりません。 専用AAL2の場合で接続(PVC)に食糧を供給する静電気、または、AAL2交換仮想回路の場合で合図するQ.2630.2[7]からPPPセッションに使用されるべきAAL2 CIDsの値を得るかもしれません(SPVCかSVC)。
Using this proposal it is possible to support the use of conventional AAL2 in CIDs that are not used to support PPP over AAL2. This proposal allows the co-existence of multiple types of SSCS function within the same AAL2 VCC.
この提案を使用して、AAL2の上でPPPを支持するのに使用されないCIDsにおける従来のAAL2の使用を支持するのは可能です。 この提案は同じAAL2 VCCの中に複数のタイプのSSCS関数の共存を許容します。
Thompson, et. al. Standards Track [Page 9] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[9ページ]RFC3336ppp
6.4 PPP over AAL2 Operation
6.4 AAL2操作の上のppp
PPP operation with AAL2 will perform basic PPP encapsulation with the PPP protocol ID. A 16-bit CRC is calculated as described above and appended to the payload. The SSSAR sub-layer of AAL2 is used for transport.
AAL2とのPPP操作はPPPプロトコルIDで基本的なPPPカプセル化を実行するでしょう。 16ビットのCRCは上で説明して、ペイロードに追加するように計算されます。 AAL2のSSSAR副層は輸送に使用されます。
Applications implementing PPP over AAL2 MUST meet all the requirements of PPP [1].
AAL2 MUSTの上でPPPを実行するアプリケーションがPPP[1]に関するすべての必要条件を満たします。
7. Example implementation of PPP/AAL2
7. PPP/AAL2の例の実現
This section describes an example implementation of how PPP can be encapsulated over AAL2. The example shows two application stacks generating IP packets that are sent to the same interface running PPP/AAL2. One Application stack is generating RTP packets and another application is generating IP Datagrams. The PPP/AAL2 interface shown in this example is running an RFC 2508 compliant version of RTP header compression.
このセクションはどうAAL2の上にPPPを要約できるかに関する例の実現について説明します。 例は、2個のアプリケーションスタックが同じインタフェース走行PPP/AAL2に送られるIPパケットを発生させるのを示します。 あるApplicationスタックがRTPパケットを発生させています、そして、別のアプリケーションはIPデータグラムを発生させています。この例に示されたPPP/AAL2インタフェースは2508年のRTPヘッダー圧縮のRFC対応バージョンを走らせています。
Thompson, et. al. Standards Track [Page 10] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[10ページ]RFC3336ppp
Here are the paths an Application packet can take in this implementation:
ここに、Applicationパケットがこの実現で取ることができる経路があります:
+---+---+---+---+--+ +
| Application A | |
+---+---+---+---+--+ |
| RTP | |
+---+---+---+---+--+ +---+---+---+---+---+ Application
| UDP | | Application B | |
+---+---+---+---+--+ +---+---+---+---+---+ |
| IP | | IP | |
+---+---+---+---+--+ +---+---+---+---+---+ +
| |
+---------------+------------+
|
|
+---+---+---+---+---+--+ +
| Compression Filter | |
+---+---+---+---+---+--+ |
| |
| |
+---------+-----------+ |
| | |
RTP | | Non-RTP |
Packets V | Packets |
+---+---+---+---+---+---+ | |
| CRTP | | |
+---+---+---+---+---+---+---+---+---+---+---+---+ Transport
| PPP | |
+---+---+---+---+---+---+---+---+---+---+---+---+ |
| |
+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |
| Segmentation (SSSAR) | |
+---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ |
+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |
| AAL2 CPS | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ |
| ATM Layer | |
+---+---+---+---+---+---+---+---+---+---+---+---+---+----+ +
+---+---+---+---+--+ + | アプリケーションA| | +---+---+---+---+--+ | | RTP| | +---+---+---+---+--+ +---+---+---+---+---+ アプリケーション| UDP| | アプリケーションB| | +---+---+---+---+--+ +---+---+---+---+---+ | | IP| | IP| | +---+---+---+---+--+ +---+---+---+---+---+ + | | +---------------+------------+ | | +---+---+---+---+---+--+ + | 圧縮フィルタ| | +---+---+---+---+---+--+ | | | | | +---------+-----------+ | | | | RTP| | 非RTP| パケットV| パケット| +---+---+---+---+---+---+ | | | CRTP| | | +---+---+---+---+---+---+---+---+---+---+---+---+ 輸送| ppp| | +---+---+---+---+---+---+---+---+---+---+---+---+ | | | +---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ | | 分割(SSSAR)| | +---+---+---+---+---+---+---+ +--+---+---+---+---+--+--+-+ | +---+---+---+---+---+---+---+---+---+---+---+---+---+----+ | | AAL2 CPS| | +---+---+---+---+---+---+---+---+---+---+---+---+---+----+ | | 気圧層| | +---+---+---+---+---+---+---+---+---+---+---+---+---+----+ +
In the picture above, application A is an RTP application generating RTP packets. Application B is an IP application generating IP datagrams. Application A gathers the RTP data and formats an RTP packet. Lower level layers of application A add UDP and IP headers to form a complete IP packet. Application B is generating datagrams to the IP layer. These datagrams may not have UDP or RTP headers.
絵では、アプリケーションAは上では、RTPパケットを発生させるRTPアプリケーションです。 アプリケーションBはIPデータグラムを発生させるIPアプリケーションです。アプリケーションAは、RTPデータを集めて、RTPパケットをフォーマットします。 アプリケーションAの下のレベル層は、完全なIPパケットを形成するためにUDPとIPヘッダーを加えます。 アプリケーションBはIP層にデータグラムを発生させています。 これらのデータグラムには、UDPかRTPヘッダーがないかもしれません。
Thompson, et. al. Standards Track [Page 11] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[11ページ]RFC3336ppp
In the above picture, a protocol stack is configured to apply CRTP/PPP/AAL2 compression on an interface to a destination host. All packets that are sent to this interface will be tested to see if they can be compressed using RTP header compression. As packets appear at the interface, they will be tested by a compression filter to determine if they are candidates for header compression. If the compression filter determines that the packet is a candidate for compression, the packet will be sent to the CRTP compressor. If the packet is not a candidate for compression, it will be sent directly to the PPP layer for encapsulation as an IP packet encapsulated in PPP.
上の画像では、プロトコル・スタックは、CRTP/PPP/AAL2圧縮をあて先ホストへのインタフェースに付けるために構成されます。 このインタフェースに送られるすべてのパケットが、RTPヘッダー圧縮を使用することでそれらを圧縮できるかどうか確認するためにテストされるでしょう。 パケットがインタフェースに現れるようにそれらは圧縮フィルタによってテストされて、彼らがヘッダー圧縮の候補であるかどうか決定するでしょう。 圧縮フィルタが、パケットが圧縮の候補であることを決定すると、CRTPコンプレッサーにパケットを送るでしょう。 パケットが圧縮の候補でないなら、IPパケットがPPPでカプセルに入れられたので、カプセル化のために直接PPP層にそれを送るでしょう。
The destination UDP port number and packet length are examples of criteria that may be used by the compression filter to select the interface.
目的地UDPポートナンバーとパケット長は圧縮フィルタによって使用される、インタフェースを選択するかもしれない評価基準に関する例です。
In this example, packets from application A will be passed to the CRTP compressor which then hands the compressed packet to the PPP layer for encapsulation as one of the compressed header types of CRTP. The PPP layer will add the appropriate CRTP payload type for the compressed packet.
この例では、アプリケーションAからのパケットは次に圧縮されたヘッダーのひとりがタイプするようにカプセル化のためにPPP層に圧縮されたパケットを手渡すCRTPのCRTPコンプレッサーに通過されるでしょう。 PPP層は圧縮されたパケットのための適切なCRTPペイロードタイプを加えるでしょう。
Packets from application B will be sent directly to the PPP layer for encapsulation as an IP/PPP packet. The PPP layer will add the PPP payload type for an IP packet encapsulated in PPP.
Bが直接送られるアプリケーションからPPPまでのパケットはカプセル化のためにIP/PPPパケットとして層にされます。 PPP層はPPPでカプセルに入れられたIPパケットのためにPPPペイロードタイプを加えるでしょう。
PPP packets are then segmented using I.366.1 segmentation with SSSAR.
そして、PPPパケットは、SSSARがあるI.366.1分割を使用することで区分されます。
The resulting AAL2 frame mode PDU is passed down as a CPS SDU to the CPS Layer for multiplexing accompanied by the CPS-UUI and the CPS- CID. The CPS Layer multiplexes the CPS-PKT onto a CPS-PDU. CPS-PDUs are passed to the ATM layer as ATM SDUs to be carried end-to-end across the ATM network.
マルチプレクシングのためのCPS LayerへのCPS SDUがCPS-UUIとCPS- CIDで伴走したので、結果として起こるAAL2フレーム方式PDUを伝えます。 CPS LayerはCPS-PKTをCPS-PDUに多重送信します。 CPS-PDUsは、運ばれたATMネットワークの向こう側の終わりから終わりになるようにATM SDUsとしてATM層に渡されます。
At the receiving end, the ATM SDU's arrive and are passed up to the AAL2 CPS. As the AAL2 CPS PDU is accumulated, complete CPS-PKT's are reassembled by the SSSAR SSCS. Reassembled packets are checked for errors using the CRC algorithm.
犠牲者に、ATM SDUのものは、到着して、AAL2 CPSまで渡されます。AAL2 CPS PDUが蓄積されるとき、完全なCPS-PKTのものはSSSAR SSCSによって組み立て直されます。 組み立て直されたパケットは、誤りがないかどうかCRCアルゴリズムを使用することでチェックされます。
At this point, the PPP layer on the receiving side uses the PPP payload type to deliver the packet to either the CRTP decompressor or the IP layer depending on the value of the PPP payload type.
ここに、受信側の上のPPP層は、PPPペイロードタイプの値に依存するCRTP減圧装置かIP層のどちらかにパケットを提供するのにPPPペイロードタイプを使用します。
Thompson, et. al. Standards Track [Page 12] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[12ページ]RFC3336ppp
8. LCP Configuration Options
8. LCP設定オプション
By default, PPP over AAL2 will use the 16 bit CRC encapsulation for all packets.
デフォルトで、AAL2の上のPPPはすべてのパケットに16ビットのCRCカプセル化を使用するでしょう。
The default Maximum-Receive-Unit (MRU) is 1500 bytes.
Maximumがユニットを受けているデフォルト(MRU)は1500バイトです。
9. Security Considerations
9. セキュリティ問題
This memo defines mechanisms for PPP encapsulation over ATM. There is an element of trust in any encapsulation protocol: a receiver should be able to trust that the sender has correctly identified the protocol being encapsulated and that the sender has not been spoofed or compromised. A receiver should also be able to trust that the transport network between sender and receiver has not been compromised.
このメモはATMの上のPPPカプセル化のためにメカニズムを定義します。 どんなカプセル化プロトコルにも信頼の要素があります: 受信機は送付者が送付者が正しくカプセル化されるプロトコルを特定して、偽造されるか、または感染されていないと信じるはずであることができます。 また、受信機は、送付者と受信機の間の転送ネットワークが感染されていないと信じるはずであることができます。
A PPP session that runs over an ATM Virtual Circuit must follow the PPP link operation state machine described in RFC 1661 [1]. This state machine includes the ability to enforce the use of an authentication phase using the PAP/CHAP authentication protocols before any network layer packets are exchanged. Using PPP level authentication, a PPP receiver can authenticate a PPP sender.
ATM Virtual CircuitをひくPPPセッションはRFC1661[1]で説明されたPPPリンク操作州のマシンに続かなければなりません。 この州のマシンはどんなネットワーク層パケットも交換する前にPAP/CHAP認証プロトコルを使用することで認証フェーズの使用を実施する能力を含んでいます。 PPPの平らな認証を使用して、PPP受信機はPPP送付者を認証できます。
System security may also be compromised by the attacks of the ATM transport network itself. The ATM Forum has published a security framework [11] and a security specification [12] that define procedures to guard against common threats to an ATM transport network.
また、ATM転送ネットワーク自体の攻撃でシステムセキュリティは感染されるかもしれません。 ATM ForumはATM転送ネットワークへの一般的な脅威に用心するために手順を定義するセキュリティフレームワーク[11]とセキュリティ仕様[12]を発表しました。
PPP level authentication does not guard against man in the middle attacks. These attacks could occur if an attacker was able to compromise the security infrastructure of an ATM switching network. Applications that require protection against threats to an ATM switching network are encouraged to use authentication headers, or encrypted payloads, and/or the ATM-layer security services described in [12].
PPPの平らな認証は中央攻撃で男性に用心しません。 攻撃者がATM切り換えネットワークのセキュリティインフラストラクチャに感染することができるなら、これらの攻撃は起こることができるでしょうに。 ATM切り換えネットワークへの脅威に対する保護を必要とするアプリケーションが認証ヘッダー、暗号化されたペイロード、そして/または、セキュリティー・サービスが[12]で説明したATM-層を使用するよう奨励されます。
When PPP over AAL2 is used on a set of CIDs in a virtual connection, there may be other non PPP encapsulated AAL2 CIDs running on the same virtual connection. Because of this, an end point cannot assume that the PPP session authentication and related security mechanisms also secure the non PPP encapsulated CIDs on that same virtual connection.
AAL2の上のPPPがCIDsの1セットで仮想接続に使用されるとき、同じ仮想接続で動くAAL2 CIDsであるとカプセル化された他の非PPPがあるかもしれません。 これのために、エンドポイントは、また、PPPセッション認証と関連するセキュリティー対策がそれのCIDsであるとカプセル化された非PPPの同じ仮想接続を保証すると仮定できません。
Thompson, et. al. Standards Track [Page 13] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[13ページ]RFC3336ppp
10. Acknowledgements
10. 承認
The authors would like to thank Rajesh Kumar, Mike Mclaughlin, Pietro Schicker, James Carlson and John O'Neil for their contributions to this proposal.
作者はこの提案への彼らの貢献についてラジェッシュ・クマー、マイクMclaughlin、ピエトロSchicker、ジェームス・カールソン、およびジョン・オニールに感謝したがっています。
11. References
11. 参照
[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
51, RFC 1661, July 1994.
[1] シンプソン、W.、エディタ、「二地点間プロトコル(ppp)」、STD51、RFC1661、1994年7月。
[2] Gross, G., Kaycee, M., Li, A., Malis, A. and J. Stephens, "PPP
over AAL5", STD 51, RFC 2364, July 1998.
[2] グロスとG.とKayceeとM.と李とA.とMalisとA.とJ.スティーブンズ、「AAL5"、STD51、RFC2364、1998年7月の間のppp。」
[3] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for
Low-Speed Serial Links", RFC 2508, February 1999.
[3]Casner、S.、およびRFC2508、1999年2月対「低速連続のリンクへのIP/UDP/RTPヘッダーを圧縮する」ジェーコブソン
[4] International Telecommunications Union, "BISDN ATM Adaptation
layer specification: Type 2 AAL(AAL2)", ITU-T Recommendation
I.363.2, September 1997.
[4] 国際Telecommunications Union、「BISDN ATM Adaptationは仕様を層にします」。 「タイプ2AAL(AAL2)」、ITU-T推薦I.363.2、1997年9月。
[5] International Telecommunications Union, "Segmentation and
Reassembly Service Specific Convergence Sublayer for the AAL
type 2", ITU-T Recommendation I.366.1, June 1998.
[5] 国際Telecommunications Union、「AALのための分割とReassembly Service Specific Convergence Sublayerは2インチをタイプします、ITU-T Recommendation I.366.1、1998年6月。」
[6] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[6] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[7] ITU-T, "ITU-T RECOMMENDATION Q.2630.2", December 2000.
[7] ITU-T、「ITU-T推薦Q.2630.2」2000年12月。
[8] Pazhyannur, R, Ali, I. and C. Fox, "PPP Multiplexing", RFC 3153,
August 2001.
[8]PazhyannurとRとアリとI.とC.フォックス、「pppマルチプレクシング」、RFC3153、2001年8月。
[9] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", RFC
1889, January 1996.
[9]Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、RFC1889、1996年1月。
[10] Thompson, B., Koren, T. and B. Buffam, "Class Extensions for PPP
over Asynchronous Transfer Mode Adaptation Layer 2", RFC 3337,
December 2002.
[10] トンプソン、B.、コーレン、T.とB.Buffam、「非同期通信モード適合の上のpppのためのクラス拡大は2インチを層にします、RFC3337、2002年12月。」
[11] The ATM Forum, "ATM Security Framework Version 1.0", af-sec-
0096.000, February 1998.
[11] 「気圧セキュリティフレームワークバージョン1インチと、af秒-0096.000と、1998年2月」ATM Forum。
[12] The ATM Forum, "ATM Security Specification v1.1", af-sec-
0100.002, March 2001.
[12] ATM Forum、「ATM Security Specification v1.1"、af秒-0100.002、2001年3月。」
Thompson, et. al. Standards Track [Page 14] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[14ページ]RFC3336ppp
[13] International Telecommunications Union, ISDN User-Network
Interface-Data Link Layer Specification, ITU-T Recommendation
Q.921, March 1993.
[13] 国際電気通信組合、ISDNユーザネットワーク・インターフェースデータ・リンク層仕様、ITU-T推薦Q.921、1993年3月。
12. Authors' Addresses
12. 作者のアドレス
Bruce Thompson Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・DriveブルーストンプソンシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
Phone: +1 408 527-0446 EMail: brucet@cisco.com
以下に電話をしてください。 +1 408 527-0446 メールしてください: brucet@cisco.com
Tmima Koren Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 USA
西タスマン・Drive TmimaコーレンシスコシステムズInc.170カリフォルニア95134サンノゼ(米国)
Phone: +1 408 527-6169 EMail: tmima@cisco.com
以下に電話をしてください。 +1 408 527-6169 メールしてください: tmima@cisco.com
Bruce Buffam Seaway Networks One Chrysalis Way, Suite 300, Ottawa, Canada K2G-6P9
オタワ(カナダ)K2G-6P9、ブルースBuffam Seawayは1つのサナギ道、スイート300をネットワークでつなぎます。
Phone: +1 613 723-9161 EMail: bruce@seawaynetworks.com
以下に電話をしてください。 +1 613 723-9161 メールしてください: bruce@seawaynetworks.com
Thompson, et. al. Standards Track [Page 15] RFC 3336 PPP Over AAL2 December 2002
etトンプソン、アル。 AAL2 December 2002の上の標準化過程[15ページ]RFC3336ppp
13. Full Copyright Statement
13. 完全な著作権宣言文
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機能のための基金は現在、インターネット協会によって提供されます。
Thompson, et. al. Standards Track [Page 16]
etトンプソン、アル。 標準化過程[16ページ]
一覧
スポンサーリンク
