RFC3337 日本語訳

3337 Class Extensions for PPP over Asynchronous Transfer ModeAdaptation Layer 2. B. Thompson, T. Koren, B. Buffam. December 2002. (Format: TXT=14911 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                        B. Thompson
Request for Comments: 3337                                      T. Koren
Category: Standards Track                                  Cisco Systems
                                                               B. Buffam
                                                         Seaway Networks
                                                           December 2002

コメントを求めるワーキンググループB.トンプソン要求をネットワークでつないでください: 3337年のT.コーレンカテゴリ: 規格は2002年12月にシスコシステムズB.Buffam海路ネットワークを追跡します。

                     Class Extensions for 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) over Asynchronous Transfer Mode
   (ATM) Adaptation Layer 2 defines the encapsulation that allows a PPP
   session to be transported over an ATM virtual circuit using the ATM
   Adaptation Layer 2 (AAL2) adaptation layer.  This document defines a
   set of class extensions to PPP over AAL2 that implement equivalent
   functionality to Multi Class Multi Link PPP over a single ATM virtual
   circuit.  Instead of using Multi Link PPP as the basis for
   fragmentation functionality, this document uses the functionality of
   the Segmentation and Reassembly Service Specific Convergence Sublayer
   that is already required as the basic encapsulation format of PPP
   over AAL2.

Asynchronous Transfer Mode(ATM)適合Layer2の上のPointからポイントへのプロトコル(PPP)はPPPセッションがATMの仮想の回路の上に輸送されるのをATM Adaptation Layer2(AAL2)適合層を使用することで許容するカプセル化を定義します。 このドキュメントはただ一つのATM仮想の回路にわたって同等な機能性をMulti Class Multi Link PPPに実装するAAL2の上で1セットのクラス拡大をPPPと定義します。 断片化の機能性の基礎としてMulti Link PPPを使用することの代わりに、このドキュメントはPPPの基本的なカプセル化形式としてAAL2の上で既に必要であるSegmentationとReassembly Service Specific Convergence Sublayerの機能性を使用します。

1. Introduction

1. 序論

   Using AAL2 as an adaptation layer for PPP transport over ATM provides
   a bandwidth efficient transport for IP applications that generate
   small packets.  An example IP application that generates small
   packets is RTP encapsulated voice (Voice over IP).

ATMの上のPPP輸送に適合層としてAAL2を使用すると、小型小包を生成するIPアプリケーションのための帯域幅の効率的な輸送は提供されます。 小型小包を生成する例のIPアプリケーションは声(ボイス・オーバー IP)であるとカプセル化されたRTPです。

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

RFC 3337           Class Extensions for PPP over AAL2      December 2002

etトンプソン、アル。 AAL2 December 2002の上のpppのための標準化過程[1ページ]RFC3337クラス拡張子

   In addition to bandwidth efficiency, real-time applications such as
   voice require low latency.  RFC 2689 [2] describes an architecture
   for providing transport services for real time applications on low
   bit rate links.  The main components of the architecture are: a
   real-time encapsulation format for asynchronous and synchronous low-
   bitrate links, a header compression architecture optimized for real-
   time flows, elements of negotiation protocols used between routers
   (or between hosts and routers), and announcement protocols used by
   applications to allow this negotiation to take place.

帯域幅効率に加えて、声などのリアルタイムのアプリケーションは低遅延を必要とします。 RFC2689[2]は、低いビット伝送速度リンクの上にリアルタイムのアプリケーションのための輸送サービスを提供するためにアーキテクチャについて説明します。 アーキテクチャの主な成分は以下の通りです。 非同期で同期の低いbitrateリンクのためのリアルタイムのカプセル化形式、ヘッダー圧縮アーキテクチャは本当の時間流れ、ルータ(またはホストとルータの間で)の間で使用される、交渉プロトコルの原理、およびこの交渉が行われるのを許容するのにアプリケーションで使用される発表プロトコルのために最適化されました。

   Multi Class Multi Link PPP [3] defines a fragment-oriented solution
   for the real-time encapsulation format part of the architecture
   defined in [2], i.e., for the queues-of-fragments type sender.  As
   described in more detail in the architecture document, a real-time
   encapsulation format is required to guarantee low latency in the
   presence of large non real time packets. For example, a 1500 byte
   packet on a 128 kbit/s ATM virtual circuit makes this link
   unavailable for the transmission of real-time information for about
   100 ms.  This adds a worst-case delay that causes real-time
   applications to operate with round-trip delays that are too high for
   many interactive tasks.  Multi Class Multi Link PPP defines a set of
   extensions of Multi Link PPP [4] that enable the sender to fragment
   the packets of various priorities into multiple classes of fragments,
   allowing high-priority packets to be sent between fragments of lower
   priorities.

マルチClass Multi Link PPP[3]は[2]で定義されたアーキテクチャのリアルタイムのカプセル化形式部分と断片指向のソリューションを定義します、すなわち、断片の待ち行列タイプ送付者のために。 さらに詳細にアーキテクチャドキュメントで説明されるように、リアルタイムのカプセル化形式が大きい非リアルタイムパケットがあるとき低遅延を保証するのに必要です。 例えば、ATMの仮想の回路がおよそ100原稿Thisのためのリアルタイムの情報の伝達を入手できないこのリンクをする128kbit/sの1500年のバイトのパケットはリアルタイムのアプリケーションが多くの会話型タスクには、高過ぎる往復の遅れで作動する最悪の場合遅れを加えます。 マルチClass Multi Link PPPは送付者が様々なプライオリティのパケットを複数のクラスの断片に断片化するのを可能にするMulti Link PPP[4]の拡大のセットを定義します、高優先度パケットが下側のプライオリティの断片の間に送られるのを許容して。

   This document defines a set of class extensions to PPP over AAL2 [1]
   that implement equivalent functionality to Multi Class Multi Link PPP
   over a single ATM virtual circuit.  Instead of using Multi Link PPP
   as the basis for fragmentation functionality, this document uses the
   functionality of the Service Specific Segmentation and Reassembly
   Sublayer (SSSAR) [5] that is already required as the basic
   encapsulation format of PPP over AAL2.

このドキュメントはただ一つのATM仮想の回路にわたって同等な機能性をMulti Class Multi Link PPPに実装するAAL2[1]の上で1セットのクラス拡大をPPPと定義します。 断片化の機能性の基礎としてMulti Link PPPを使用することの代わりに、このドキュメントはPPPの基本的なカプセル化形式としてAAL2の上で既に必要であるService Specific SegmentationとReassembly Sublayer(SSSAR)[5]の機能性を使用します。

   In addition to providing fragmentation, the real time transport
   service must allow high priority fragments to be sent between
   fragments of lower priorities.  This can be accomplished in PPP over
   AAL2 by allowing a single PPP session to span multiple AAL2 CPS [6]
   Channel Identifiers.  Once a PPP session spans multiple AAL2 Channel
   IDs, the Channel ID can be used to identify the class that a fragment
   belongs to.  Fragments belonging to a high priority class can be sent
   using a particular AAL2 Channel ID.  Fragments of lower priority
   classes can be sent using different AAL2 Channel IDs.  Once multiple
   fragment classes are identified using different AAL2 Channel IDs, the
   AAL2 CPS layer can be used to send fragments belonging to a high
   priority class between fragments of lower priorities.

断片化を提供することに加えて、リアルタイムの輸送サービスは、高い優先権断片が下側のプライオリティの断片の間に送られるのを許容しなければなりません。 ただ一つのPPPセッションが複数のAAL2 CPS[6]チャンネルIdentifiersにかかるのを許容することによって、AAL2の上のPPPでこれを達成できます。 PPPセッションがいったん複数のAAL2 Channel IDにかかっていると、断片がものクラスを特定するのにthe Channel IDを使用できます。 高い優先権のクラスのもの断片に特定のAAL2 Channel IDを使用させることができます。 低優先度のクラスの断片に異なったAAL2 Channel IDを使用させることができます。 複数の断片のクラスが異なったAAL2 Channel IDを使用することでいったん特定されると、断片に高い優先権のクラスの下側のプライオリティの断片の間のものせるのにAAL2 CPS層を使用できます。

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

RFC 3337           Class Extensions for PPP over AAL2      December 2002

etトンプソン、アル。 AAL2 December 2002の上のpppのための標準化過程[2ページ]RFC3337クラス拡張子

   The class based extensions to PPP over AAL2 use existing services of
   the AAL2 SSCS and CPS layers already specified in PPP over AAL2.
   Because of this, the extensions described in this document may be
   viewed as a desirable alternative to Multi Class Multi Link PPP in
   providing a class based transport service with PPP over AAL2.

クラスはAAL2 SSCSとCPS層の既存のサービスがAAL2の上のPPPで既に指定したAAL2使用の上で拡大をPPPに基礎づけました。 これのために、クラスが基礎づけた提供におけるMulti Class Multi Link PPPへの望ましい代替手段がAAL2の上のPPPと共にサービスを輸送するとき、本書では説明された拡大は見られるかもしれません。

1.1. Specification Language

1.1. 仕様言語

   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 [7].

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

2. Requirements

2. 要件

   This document assumes the same service requirements as defined in
   Multi Class Multi Link PPP [3].  The reader is referred to section 2
   of Multi Class Multi Link PPP for the general requirements of a multi
   class fragmentation / preemption service.

このドキュメントは、Multi Class Multi Link PPP[3]で定義されるように同じサービスが要件であると仮定します。 読者は一般的なマルチクラス断片化/先取りサービスの要件についてMulti Class Multi Link PPPのセクション2を参照されます。

3. Class Extensions for PPP over AAL2

3. AAL2の上のpppのためのクラス拡大

   PPP over AAL2 uses the Service Specific Segmentation and Reassembly
   Sublayer (SSSAR) [5] for the 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.
   SSSAR provides basic fragmentation functionality for all packets
   encapsulated using PPP over AAL2.  The SSSAR layer fragments all
   packets into 64 byte fragments.

AAL2の上のPPPはService Specific Segmentationを使用します、そして、AALのためのReassembly Sublayer(SSSAR)[5]は2をタイプします。 SSSAR副層はAAL2 CPSを使用することで輸送できるフレームへのセグメントPPPパケットに使用されます。SSSAR副層は、セグメントがパケットの最後のセグメントであるかどうかを示すのに異なったAAL2 UUIコード・ポイントを使用します。 SSSARはAAL2の上でPPPを使用することでカプセルに入れられたすべてのパケットのための基本の断片化の機能性を提供します。 SSSAR層は64バイトの断片にすべてのパケットを断片化します。

   The AAL2 CPS layer defines a Channel ID that is used to identify
   multiple streams of packets within a single ATM Virtual Circuit.  In
   this document, the AAL2 CPS Channel ID is used to identify the
   preemption class that a packet fragment belongs to.  Since the
   Channel ID is used to identify different preemption classes, packet
   fragments from each class of traffic MUST be assigned to different
   Channel IDs.  In addition, each PPP session MUST have at least as
   many Channel IDs assigned as there are different classes of
   preemptible traffic.

AAL2 CPS層は独身のATM Virtual Circuitの中でパケットの複数の流れを特定するのに使用されるChannel IDを定義します。 本書では、AAL2 CPS Channel IDは、パケット断片がもの先取りのクラスを特定するのに使用されます。 the Channel IDが異なった先取りのクラスを特定するのに使用されるので、それぞれのクラスのトラフィックからのパケット断片を異なったChannel IDに割り当てなければなりません。 さらに、異なったクラスのpreemptibleトラフィックがあるので、それぞれのPPPセッションは少なくとも同じくらい多くのChannel IDを割り当てなければなりません。

   To allow PPP packets to be assigned to different preemption classes,
   PPP packets must be classified into multiple preemption classes as
   they are fragmented using SSSAR.  Many classification methods may be
   used to determine the class that a particular PPP packet belongs to.
   The architecture document [2] describes possible alternatives that
   MAY be used to implement a real time classification scheme.

PPPパケットが異なった先取りのクラスに配属されるのを許容するために、それらがSSSARを使用することで断片化されるとき、PPPパケットを複数の先取りのクラスに分類しなければなりません。 多くの分類メソッドが、特定のPPPパケットがものクラスを決定するのに使用されるかもしれません。 アーキテクチャドキュメント[2]はリアルタイムの分類体系を実装するのに使用されるかもしれない可能な代替手段を説明します。

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

RFC 3337           Class Extensions for PPP over AAL2      December 2002

etトンプソン、アル。 AAL2 December 2002の上のpppのための標準化過程[3ページ]RFC3337クラス拡張子

   Once packets have been classified into different preemption classes,
   each class of traffic is then assigned a different Channel ID.  Since
   fragments from each traffic class are now transmitted using separate
   Channel ID, the AAL2 CPS layer can be used to schedule fragments from
   the different classes.  The AAL2 CPS specification [6] does not
   specify a method for scheduling AAL2 CPS payloads from different
   Channel IDs.  The scheduling method required at the AAL2 CPS layer
   depends upon the real time requirements of applications using this
   service.  Some real-time applications MAY require the use of a
   priority based CID scheduler.  Other applications MAY only require a
   fair or weighted fair CID scheduler.  Implementations of PPP over
   AAL2 real time transport extensions SHOULD implement AAL2 CPS CID
   schedulers that meet the requirements of multi-class real time
   applications.

一度、パケットは異なった先取りのクラスに分類されたことがあって、次に、異なったChannel IDはそれぞれのクラスのトラフィックに割り当てられます。 それぞれのトラフィックのクラスからの断片が現在別々のChannel IDを使用することで伝えられるので、異なったクラスから断片の計画をするのにAAL2 CPS層を使用できます。 AAL2 CPS仕様[6]は異なったChannel IDからスケジューリングAAL2 CPSペイロードにメソッドを指定しません。 AAL2 CPS層で必要であるスケジューリング法は、このサービスを利用することでアプリケーションのリアルタイムの要件によります。 いくつかのリアルタイムのアプリケーションが優先権に基づいているCIDスケジューラの使用を必要とするかもしれません。 他のアプリケーションは公正であるか荷重している公正なCIDスケジューラを必要とするだけであるかもしれません。 AAL2リアルタイム輸送拡大SHOULDの上のPPPの実装はマルチのクラスリアルタイムに関する必要条件を満たすAAL2 CPS CIDスケジューラにアプリケーションを実装します。

4. Example Implementation: Class Based Extensions for Voice Service

4. 例の実装: クラスは声のサービスのための拡大を基礎づけました。

   When PPP over AAL2 is used to transport both voice and non-voice
   packets over low bandwidth ATM virtual circuits, it may be necessary
   to preempt the transmission of a large data packet in order to
   transmit a voice packet with minimal delay.  The example
   implementation described below shows an example of how the class
   extensions for PPP over AAL2 can be used to support a real time voice
   transport service over low bandwidth AAL2 virtual circuits.  To
   guarantee low latency and loss for voice transport, the ATM virtual
   circuit in this example must be provisioned using a real time traffic
   class such as VBRnrt or VBRrt.

AAL2の上のPPPが低い帯域幅ATM仮想の回路にわたって声と非音声パケットの両方を輸送するのに使用されるとき、大きいデータ・パケットのトランスミッションを先取りするのが、最小量の遅れで音声パケットを伝えるのに必要であるかもしれません。 例の実装はショーの下でリアルタイムの声の輸送サービスオーバーが低い帯域幅AAL2仮想の回路であるとサポートするのにどうAAL2の上のPPPのためのクラス拡張子を使用できるかに関する例について説明しました。 声の輸送のための低遅延と損失を保証するために、VBRnrtかVBRrtなどのリアルタイムのトラフィックのクラスを使用することでこの例のATMの仮想の回路に食糧を供給しなければなりません。

   For the simple voice service described above, 2 classes are
   sufficient to guarantee low latency for voice packets.  The PPP over
   AAL2 session in this case can be configured to run across 2 AAL2 CPS
   Channel IDs.  One channel ID is used to transport large data packets
   while the other channel ID is used to transport real time voice
   packets.

上で説明された簡単なボイスサービスでは、2つのクラスが、音声パケットのために低遅延を保証するために十分です。 2AAL2 CPS Channel IDに出くわすためにこの場合、AAL2セッションの間のPPPを構成できます。 1個のチャンネルのIDは、もう片方のチャンネルIDがリアルタイムの音声パケットを輸送するのに使用されている間、大きいデータ・パケットを輸送するのに使用されます。

   Packets that arrive at the PPP interface must first be classified as
   either belonging to the real time class or belonging to the data
   class.  A simple classifier that can be used to classify packets at
   this layer is packet size.

最初に、リアルタイムのクラスに属すか、またはデータのクラスに属すとしてPPPインタフェースに到着するパケットを分類しなければなりません。 この層でパケットを分類するのに使用できる純真なクラシファイアはパケットサイズです。

   Large packets are assigned to the non-real time (or data) traffic
   class and small packets are assigned to the real time traffic class.
   The packet size used to discriminate between real time and non-real
   time packets may vary based on the application and transmission rate
   of the virtual circuit.

大きいパケットは非リアルタイム(または、データ)トラフィックのクラスに配属されます、そして、小型小包はリアルタイムのトラフィックのクラスに配属されます。 パケットサイズは以前はよくリアルタイムを区別していました、そして、非リアルタイムパケットは仮想の回路のアプリケーションと通信速度に基づいて異なるかもしれません。

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

RFC 3337           Class Extensions for PPP over AAL2      December 2002

etトンプソン、アル。 AAL2 December 2002の上のpppのための標準化過程[4ページ]RFC3337クラス拡張子

   Once packets have been classified, they are now fragmented using the
   SSSAR layer of PPP over AAL2.  Separate instances of the SSSAR
   fragmentation function run on each of the 2 Channel IDs assigned to
   the PPP session.

パケットがいったん分類されると、それらは、現在、AAL2の上でPPPのSSSAR層を使用することで断片化されます。 SSSAR断片化機能の別々のインスタンスはPPPセッションまで割り当てられたIDをそれぞれの2Channelに実行します。

   Fragments coming from the SSSAR functions are now scheduled into the
   AAL2 virtual circuit using the AAL2 CPS layer.  Most AAL2 SAR
   implementations currently implement fair scheduling across multiple
   AAL2 Channel IDs.  Since the AAL2 CPS scheduler implements fair
   scheduling, real time fragments will wait for at most one non-real
   time fragment to be transmitted on the AAL2 virtual circuit before
   being scheduled.

SSSAR機能から来る断片は、現在、AAL2 CPS層を使用することでAAL2の仮想の回路に予定されています。 ほとんどのAAL2 SAR実装が現在、複数のAAL2 Channel IDの向こう側に公正なスケジューリングを実装します。 AAL2 CPSスケジューラが公正なスケジューリングを実装するので、リアルタイムの断片は、予定される前に高々1個の非リアルタイム断片しかAAL2の仮想の回路の上に伝えられないのを待つでしょう。

5.  Security Considerations

5. セキュリティ問題

   Operation of this protocol is believed to be no more and no less
   secure than operation of PPP over AAL2 [1].

AAL2[1]の上でPPPの操作ほど多くでなくてまたこのプロトコルの操作が、より安全でないというわけではないと信じられています。

6. Acknowledgements

6. 承認

   The authors would like to thank James Carlson for his contributions
   to this proposal.

作者はこの提案への彼の貢献についてジェームス・カールソンに感謝したがっています。

7. References

7. 参照

   [1] Thompson, B., Koren, T. and B. Buffam, "PPP Over Asynchronous
       Transfer Mode Adaptation Layer 2", RFC 3336, December 2002.

[1] トンプソン、B.、コーレン、T.、およびB.Buffam、「非同期通信モード適合の上のpppは2002年12月に2インチ、RFC3336を層にします」。

   [2] Bormann, C., "Providing Integrated Services over Low-bitrate
       Links", RFC 2689, September 1999.

[2] C. ボルマン、1999年9月、「低いbitrateリンクの上に統合サービスを供給すること」でのRFC2689。

   [3] Bormann, C., "The Multi-Class Extension to Multi-Link PPP", RFC
       2686 September 1999.

[3] ボルマン、C.、「マルチリンクpppへのマルチのクラス拡大」RFC2686 1999年9月。

   [4] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
       "The PPP Multilink Protocol (MP)", RFC 1990, August 1996.

[4] Sklower、K.、ロイド、B.、マクレガー、G.、カー、D.、およびT.Coradetti、「pppマルチリンクは(MP)について議定書の中で述べます」、RFC1990、1996年8月。

   [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] International Telecommunications Union, "BISDN ATM Adaptation
       layer specification: Type 2 AAL(AAL2)", ITU-T Recommendation
       I.363.2, September 1997.

[6] 国際Telecommunications Union、「BISDN ATM Adaptationは仕様を層にします」。 「タイプ2AAL(AAL2)」、ITU-T推薦I.363.2、1997年9月。

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

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

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

RFC 3337           Class Extensions for PPP over AAL2      December 2002

etトンプソン、アル。 AAL2 December 2002の上のpppのための標準化過程[5ページ]RFC3337クラス拡張子

8. Authors' Addresses

8. 作者のアドレス

   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

   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

   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

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

RFC 3337           Class Extensions for PPP over AAL2      December 2002

etトンプソン、アル。 AAL2 December 2002の上のpppのための標準化過程[6ページ]RFC3337クラス拡張子

9.  Full Copyright Statement

9. 完全な著作権宣言文

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

etトンプソン、アル。 標準化過程[7ページ]

一覧

 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 

スポンサーリンク

Windows から Git を使う方法

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

上に戻る