RFC3194 日本語訳

Network Working Group                                          A. Durand
Request for Comments: 3194                              SUN Microsystems
Updates: 1715                                                 C. Huitema
Category: Informational                                        Microsoft
                                                           November 2001

コメントを求めるワーキンググループA.ジュランドの要求をネットワークでつないでください: 3194の太陽マイクロシステムズアップデート: 1715年のC.Huitemaカテゴリ: 情報のマイクロソフト2001年11月

       The Host-Density Ratio for Address Assignment Efficiency:
                        An update on the H ratio

アドレス課題効率のためのホスト密度比: H比に関する最新情報

Status of this Memo

このMemoの状態

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。

Copyright Notice

版権情報

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

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

Abstract

要約

   This document provides an update on the "H ratio" defined in RFC
   1715.  It defines a new ratio which the authors claim is easier to
   understand.

このドキュメントはRFC1715で定義された「H比」に関する最新情報を提供します。 それは新しいより理解しやすい作者が、主張する比率を定義します。

1. Evaluating the efficiency of address allocation

1. アドレス配分の効率を評価します。

   A naive observer might assume that the number of addressable objects
   in an addressing plan is a linear function of the size of the
   address.  If this were true, a telephone numbering plan based on 10
   digits would be able to number 10 billion telephones, and the IPv4 32
   bit addresses would be adequate for numbering 4 billion computers
   (using the American English definition of a billion, i.e. one
   thousand millions.) We all know that this is not correct: the 10
   digit plan is stressed today, and it handles only a few hundred
   million telephones in North America; the Internet registries have
   started to implement increasingly restrictive allocation policies
   when there were only a few tens of million computers on the Internet.

ナイーブな観察者は、アドレシングプランにおける、アドレス可能な物の数がアドレスのサイズの一次関数であると仮定するかもしれません。 これが本当であるなら、10ケタに基づく電話付番プランはNo.10 billion電話にできるでしょうに、そして、40億台のコンピュータに付番するのに、IPv4 32ビット・アドレスは適切でしょう(10億の米語定義(すなわち、1,000の数百万)を使用して)。 私たちは皆、これが正しくないのを知っています: 10ケタプランは今日強調されます、そして、北アメリカの数1億台の電話だけを扱います。 100万台のコンピュータのうちほんの数10がインターネットにあったとき、インターネット登録は、ますます制限している配分政策を実施し始めました。

   Addressing plans are typically organized as a hierarchy: in
   telephony, the first digits will designate a region, the next digits
   will designate an exchange, and the last digits will designate a
   subscriber within this exchange; in computer networks, the most
   significant bits will designate an address range allocated to a
   network provider, the next bits will designate the network of an
   organization served by that provider, and then the subnet to which
   the individual computers are connected.  At each level of the

アドレシングプランは階層構造として通常組織化されます: 電話では、最初のケタは領域を指定するでしょう、そして、次のケタは交換を指定するでしょう、そして、下ケタはこの交換の中で加入者を任命するでしょう。 次のビットは、コンピュータネットワークでは、最も重要なビットがネットワーク内の提供者に割り当てられたアドレスの範囲を指定して、そのプロバイダーによって役立たれる組織のネットワークを指定して、次に、個々のコンピュータが関連しているサブネットを指定するでしょう。 それぞれ平ら

Durand & Huitema             Informational                      [Page 1]

RFC 3194                An update on the H ratio           November 2001

Anが2001年11月にH比でアップデートするジュランドとHuitema Informational[1ページ]RFC3194

   hierarchy, one has to provide some margins:  one has to allocate more
   digits to the region code than the current number of regions would
   necessitate, and more bits in a subnet than strictly required by the
   number of computers.  The number of elements in any given level of
   the   hierarchy will change over time, due to growth and mobility.
   If the current allocation is exceeded, one has to engage in
   renumbering, which is painful and expensive.  In short, trying to
   squeeze too many objects into a hierarchical address space increases
   the level of pain endured by operators and subscribers.

階層構造、ものはいくつかのマージンを提供しなければなりません: 1つは領域の最新号が必要とするだろうより多くのケタ、リージョン・コードにおよびサブネットにおけるコンピュータの数によって厳密に必要とされるより多くのビットを割り当てなければなりません。 階層構造のどんな与えられたレベルの要素の数も時間がたつにつれて、成長と移動性のため変化するでしょう。 現在の配分が超えられているなら、人は番号を付け替えることに従事しなければなりません。(それは、苦痛であって、高価です)。 要するに、あまりに多くの物を階層的なアドレス空間に絞ろうとするなら、オペレータと加入者によって我慢された痛みのレベルは増加します。

   Back in 1993, when we were debating the revision of the Internet
   Protocol, we wondered what the acceptable ratio of utilization was of
   a given addressing plan.  Coming out with such a ratio was useful to
   assess how many computers could be connected to the Internet with the
   current 32-bit addresses, as well as to decide the size of the next
   generation addresses.  The second point is now decided, with 128-bits
   addresses for IPv6, but the first question is still relevant:
   knowing the capacity of the current address plan will help us predict
   the date at which this capacity will be exceeded.

1993年に戻ります、私たちは利用の許容できる比率が与えられたアドレシングプランのどのくらいであるかと思いました。(その時、私たちはインターネットプロトコルの改正について討論していました)。 現在の32ビットのアドレスで何コンピュータを評価しに比率が役に立ったそのようなものによる外に来るのをインターネットに関連づけることができました、次世代アドレスのサイズについて決めるほど噴出するように。 2番目のポイントは現在、IPv6のための128ビットのアドレスで決められますが、最初の質問はまだ関連しています: 現在のアドレスプランの容量を知っているのは、私たちがこの容量が超えられている日付を予測するのを助けるでしょう。

   Participants in the IPNG debates initially measured the efficiency of
   address allocation by simply dividing the number of allocated
   addresses by the size of the address space.  This is a simple
   measure, but it is largely dependent on the size of the address
   space.  Loss of efficiency at each level of a hierarchical plan has a
   multiplicative effect; for example, 50% efficiency at each stage of a
   three level hierarchy results in a overall efficiency of 12.5%.  If
   we want a "pain level indicator", we have to use a ratio that takes
   into account these multiplicative effects.

IPNG討論の関係者は、初めは、単に割り当てられたアドレスの数をアドレス空間のサイズに割ることによって、アドレス配分の効率を測定しました。 これは簡単な測定ですが、それはアドレス空間のサイズに主に依存しています。 階層的なプランの各レベルにおける効率の減退には、乗法的な効果があります。 例えば、3の平らな階層構造の各段階の50%の効率は12.5%の全体的効率をもたらします。 「痛みレベル指示語」が欲しいと思うなら、私たちはこれらの乗法的な効果を考慮に入れる比率を使用しなければなりません。

   The "H-Ratio" defined in RFC 1715 proposed to measure the efficiency
   of address allocation as the ratio of the base 10 logarithm of the
   number of allocated addresses to the size of the address in bits.
   This provides an address size independent ratio, but the definition
   of the H ratio results in values in the range of 0.0 to 0.30103, with
   typical values ranging from 0.20 to 0.28.  Experience has shown that
   these numbers are difficult to explain to others; it would be easier
   to say that "your address bits are used to 83% of their H-Density",
   and then explain what the H-Density is, than to say "you are hitting
   a H ratio of 0.25" and then explain what exactly the range is.

RFC1715で定義された「H-比率」は、割り当てられたアドレスの数のベース10対数対ビットのアドレスのサイズの比率としてアドレス配分の効率を測定するよう提案しました。 これはアドレスサイズ独立者比を提供しますが、H比の定義は0.0〜0.30103の範囲で値をもたらします、典型的な値が0.20〜0.28まで及んでいて。 経験は、これらの数は他のものに説明するのが難しいのを示しました。 「あなたは、0.25インチのH比に当たりであり、次に、範囲がいったい何であるかを説明します」と言うより「あなたのアドレスビットはそれらのH-密度の83%まで使用されます」と言って、次に、H-密度がどのくらいであるかを説明するのは簡単でしょう、。

   This memo introduces the Host Density ratio or "HD-Ratio", a proposed
   replacement for the H-Ratio defined in RFC 1715.  The HD values range
   from 0 to 1, and are generally expressed as percentage points; the
   authors believe that this new formulation is easier to understand and
   more expressive than the H-Ratio.

このメモはHost Density比か「HD-比率」、RFC1715で定義されたH-比率への提案された交換品を導入します。 HD値は、0〜1まで及んで、一般に、パーセントとして言い表されます。 作者は、この新しい定式化がH-比率よりさらに理解しやすくて表現していると信じています。

Durand & Huitema             Informational                      [Page 2]

RFC 3194                An update on the H ratio           November 2001

Anが2001年11月にH比でアップデートするジュランドとHuitema Informational[2ページ]RFC3194

2. Definition of the HD-ratio

2. HD-比率の定義

   When considering an addressing plan to allocate objects, the host
   density ratio HD is defined as follow:

アドレシングプランを考えるときには、物、比率HDが定義されるホスト密度を割り当てるために、続いてください:

              log(number of allocated objects)
   HD = ------------------------------------------
         log(maximum number of allocatable objects)

ログ(割り当てられた物の数)HD=------------------------------------------ ログ(最大数の「割り当て-可能」物)

   This ratio is defined for any number of allocatable objects greater
   than 1 and any number of allocated objects greater or equal than 1
   and less than or equal the maximum number of allocatable objects.
   The ratio is usually presented as a percentage, e.g. 70%.  It varies
   between 0 (0%), when there is just one allocation, and 1 (100%), when
   there is one object allocated to each available address.  Note that
   for the calculation of the HD-ratio, one can use any base for the
   logarithm as long as it is the same for both the numerator and the
   denominator.

この比率はいろいろな「割り当て-可能」物に1と1から、よりすばらしいか等しいいろいろな割り当てられた物よりすばらしくて、以下か等しい状態で定義されて、「割り当て-可能」の最大数が反対するということです。 通常、比率は割合、例えば、70%として提示されます。 それは0(0%)と、1(100%)の間異なります、それぞれの利用可能なアドレスに割り当てられた1個の物があるとき。その時、ちょうど1つの配分があります。 分子と分母の両方に、それが同じである限り、HD-比率の計算に、1つが対数のためのどんなベースも使用できることに注意してください。

   The HD-ratio can, in most cases, be derived from the H ratio by the
   formula:

多くの場合、公式でH比からHD-比率を得ることができます:

           H
   HD = --------
        log10(2)

H HD=-------- log10(2)

3. Using the HD-ratio as an indicator of the pain level

3. 痛みレベルのインディケータとしてHD-比率を使用します。

   In order to assess whether the H-Ratio was a good predictor of the
   "pain level" caused by a specific efficiency, RFC1715 used several
   examples of networks that had reached their capacity limit.  These
   could be for example telephone networks at the point when they
   decided to add digits to their numbering plans, or computer networks
   at the point when their addressing capabilities were perceived as
   stretched beyond practical limits.  The idea behind these examples is
   that network managers would delay renumbering or changing the network
   protocol until it became just too painful; the ratio just before the
   change is thus a good predictor of what can be achieved in practice.
   The examples were the following:

評価、H-比率が特定の効率によって引き起こされた「痛みレベル」の良い予言者であったか否かに関係なく、RFC1715は彼らの容量限界に達したネットワークに関するいくつかの例を使用しました。 彼らのアドレス指定能力が実用的な限界を超えて伸ばされるように知覚されたときのポイントでプラン、またはコンピュータネットワークに付番するのにケタを加えると決めたとき、例えば、これらはポイントの電話網であるかもしれません。 これらの例の後ろの考えはネットワークマネージャが、ただ苦痛になり過ぎるまでネットワーク・プロトコルを番号を付け替えるか、または変えるのを遅らせるだろうということです。 その結果、変化のすぐ前の比率は実際には達成できることに関する良い予言者です。 例は以下でした:

   * Adding one digit to all French telephone numbers, moving from 8
   digits to 9, when the number of phones reached a threshold of 1.0
   E+7.

* 電話の数が1.0E+7の敷居に達したとき、8ケタから9まで動いて、すべてのフランスの電話番号への1ケタを加えます。

Durand & Huitema             Informational                      [Page 3]

RFC 3194                An update on the H ratio           November 2001

Anが2001年11月にH比でアップデートするジュランドとHuitema Informational[3ページ]RFC3194

                                  log(1.0E+7)
      HD(FrenchTelephone8digit) = ----------- = 0.8750 = 87.5%
                                  log(1.0E+8)

ログ(1.0E+7)HD(FrenchTelephone8digit)=----------- = 0.8750 = 87.5 %ログ(1.0E+8)

                                  log(1.0E+7)
      HD(FrenchTelephone9digit) = ----------- = 0.7778 = 77.8%
                                  log(1.0E+9)

ログ(1.0E+7)HD(FrenchTelephone9digit)=----------- = 0.7778 = 77.8 %ログ(1.0E+9)

   * Expanding the number of areas in the US telephone system, making
   the phone number effectively 10 digits long instead of "9.2" (the
   second digit of area codes used to be limited to 0 or 1) for about
   1.0 E+8 subscribers.

* 「およそ1.0E+8の加入者のための9.2インチ(市外局番の2番目のケタは以前はよく0か1に制限されていた)」の代わりに長い間電話番号を事実上10ケタにして、米国電話の領域の数を広げます。

                                log(1.0E+8)
      HD(USTelephone9.2digit) = ------------ = 0.8696 = 87.0 %
                                log(9.5E+9)

ログ(1.0E+8)HD(USTelephone9.2digit)=------------ = 0.8696 = 87.0 %ログ(9.5E+9)

                                log(1.0E+8)
      HD(USTelephone10digit)  = ------------ = 0.8000 = 80.0 %
                                log(1E+10)

ログ(1.0E+8)HD(USTelephone10digit)=------------ = 0.8000 = 80.0 %ログ(1E+10)

   * The globally-connected physics/space science DECnet (Phase IV)
   stopped growing at about 15K nodes (i.e. new nodes were hidden) in a
   16 bit address space.

* グローバルに接続された物理学/宇宙科学DECnet(フェーズIV)はおよそ15Kのノード(すなわち、新しいノードは隠された)に16ビットのアドレス空間で成長が止まりました。

                      log(15000)
      HD(DecNET IV) = ---------- = 0.8670 = 86.7 %
                      log(2^16)

ログ(15000)HD(DecNET IV)=---------- = 0.8670 = 86.7 %ログ(2^16)

   From those examples, we can note that these addressing systems
   reached their limits for very close values of the HD-ratio.  We can
   use the same examples to confirm that the definition of the HD-ratio
   as a quotient of logarithms results in better prediction than the
   direct quotient of allocated objects over size of the address space.
   In our three examples, the direct quotients were 10%, 3.2% and 22.8%,
   three very different numbers that don't lead to any obvious
   generalization.  The examples suggest an HD-ratio value on the order
   of 85% and above correspond to a high pain level, at which operators
   are ready to make drastic decisions.

それらの例から、私たちは、これらのアドレス指定方式がHD-比率の非常に近い値のための彼らの限界に達したことに注意できます。 私たちは、対数に関する商としてのHD-比率の定義がアドレス空間における特の割り当てられた物のダイレクト商より良い予測をもたらすと確認するのに同じ例を使用できます。 私たちの3つの例では、ダイレクト商は10%、3.2%であり、22.8%、3はどんな明白な一般化にもつながらない非常に異なった番号でした。 例は、85%以上の注文のHD-比率値が高い痛みレベルに対応するのを示します。(そこでは、オペレータが抜本的な決定をする準備ができています)。

   We can also examine our examples and hypothesize that the operators
   who renumbered their networks tried to reach, after the renumbering,
   a pain level that was easily supported.  The HD-ratio of the French
   or US network immediately after renumbering was 78% and 80%,
   respectively.  This suggests that values of 80% or less corresponds
   to comfortable trade-offs between pain and efficiency.

私たちは、また、私たちの例を調べて、彼らのネットワークに番号を付け替えさせたオペレータが達しようとしたのを仮定できます、番号を付け替えることの後に、容易に支持された痛みレベル。 番号を付け替える直後フランスの、または、米国のネットワークのHD-比率は%と80%と、それぞれ78でした。 これは、80%以下の値が痛みと効率の間の快適なトレードオフに対応するのを示します。

Durand & Huitema             Informational                      [Page 4]

RFC 3194                An update on the H ratio           November 2001

Anが2001年11月にH比でアップデートするジュランドとHuitema Informational[4ページ]RFC3194

4. Using the HD-ratio to evaluate the capacity of addressing plans

4. アドレシングプランの容量を評価するのにHD-比率を使用します。

   Directly using the HD-ratio makes it easy to evaluate the density of
   allocated objects.  Evaluating how well an addressing plan will scale
   requires the reverse calculation.  We have seen in section 3.1 that
   an HD-ratio lower than 80% is manageable, and that HD-ratios higher
   than 87% are hard to sustain.  This should enable us to compute the
   acceptable and "practical maximum" number of objects that can be
   allocated given a specific address size, using the formula:

直接HD-比率を使用するのに、割り当てられた物の密度を評価するのは簡単になります。 アドレシングプランがどれくらいよく比例するかを評価するのが逆の計算を必要とします。 私たちは、80%より低HD-比率に処理しやすいセクション3.1、およびそれで87%より高いHD-比率を支えにくいのを見ました。 これは、私たちが許容できるのと特定のアドレスサイズを考えて、割り当てることができる物の「実用的な最大」番号を計算するのを可能にするべきです、公式を使用して:

   number allocatable of objects
               = exp( HD x log(maximum number allocatable of objects))
               = (maximum number allocatable of objects)^HD

物の数の「割り当て-可能」は^exp(HD xは(最大数「割り当て-可能」の物)を登録する)=(最大数「割り当て-可能」の物)HDと等しいです。

   The following table provides example values for a 9-digit telephone
   plan, a 10-digit telephone plan, and the 32-bit IPv4 Internet:

以下のテーブルは9ケタの電話プラン、10ケタの電話プラン、および32ビットのIPv4インターネットに例の値を提供します:

                                             Very  Practical
                     Reasonable  Painful  Painful    Maximum
                         HD=80%   HD=85%   HD=86%     HD=87%
   ---------------------------------------------------------
   9-digits plan           16 M     45 M     55 M       68 M
   10-digits plan         100 M    316 M    400 M      500 M
   32-bits addresses       51 M    154 M    192 M      240 M

非常に実用的な妥当な苦痛な苦痛な最大のHD=80%HD=85%HD=86%HD=87、%--------------------------------------------------------- 9ケタは100M316M400M500Mの32ビットが51M154M192M240M記述する16M45M55M68Mの10ケタのプランを計画しています。

   Note: 1M = 1,000,000

以下に注意してください。 1M=100万

   Indeed, the practical maximum depends on the level of pain that the
   users and providers are willing to accept.  We may very well end up
   with more than 154M allocated IPv4 addresses in the next years, if we
   are willing to accept the pain.

本当に、実用的な最大はユーザとプロバイダーが受け入れても構わないと思っている痛みのレベルに依存します。 私たちは次の数年間IPv4アドレスを割り当てる154M以上で非常によく終わるかもしれません、私たちが痛みを受け入れるなら。

5. Security considerations

5. セキュリティ問題

   This document has no security implications.

このドキュメントには、セキュリティ意味が全くありません。

6. IANA Considerations

6. IANA問題

   This memo does not request any IANA action.

このメモは少しのIANA動作も要求しません。

Durand & Huitema             Informational                      [Page 5]

RFC 3194                An update on the H ratio           November 2001

Anが2001年11月にH比でアップデートするジュランドとHuitema Informational[5ページ]RFC3194

7. Author addresses

7. 作者アドレス

   Alain Durand
   SUN Microsystems, Inc
   901 San Antonio Road MPK17-202
   Palo Alto, CA 94303-4900
   USA

アラン・ジュランド太陽マイクロシステムズ、Inc901サンアントニオ道路MPK17-202パロアルト、カリフォルニア94303-4900米国

   EMail: Alain.Durand@sun.com

メール: Alain.Durand@sun.com

   Christian Huitema
   Microsoft Corporation
   One Microsoft Way Redmond, WA 98052-6399
   USA

クリスチャンのHuitemaマイクロソフト社1マイクロソフト道ワシントン98052-6399レッドモンド(米国)

   EMail: huitema@microsoft.com

メール: huitema@microsoft.com

8. Acknowledgment

8. 承認

   The authors would like to thank Jean Daniau for his kind support
   during the elaboration of the HD formula.

作者はHD公式の労作の間、彼の親切なサポートについてジーンDaniauに感謝したがっています。

9. References

9. 参照

   [RFC1715] Huitema, C., "The H Ratio for Address Assignment
             Efficiency", RFC 1715, November 1994.

[RFC1715] Huitema、C.、「アドレス課題効率のためのH比」、RFC1715、1994年11月。

   [IANAV4]  INTERNET PROTOCOL V4 ADDRESS SPACE, maintained by the IANA,
             http://www.iana.org/assignments/ipv4-address-space

IANA、 http://www.iana.org/assignments/ipv4-address-space によって維持された[IANAV4]INTERNET PROTOCOL V4 ADDRESS SPACE

   [DMNSRV]  Internet Domain Survey, Internet Software Consortium,
             http://www.isc.org/ds/

[DMNSRV]インターネットドメイン調査、インターネットソフトウェア共同体、 http://www.isc.org/ds/

   [NETSZR]  Netsizer, Telcordia Technologies, http://www.netsizer.com/

[NETSZR]Netsizer、Telcordia技術、 http://www.netsizer.com/

Durand & Huitema             Informational                      [Page 6]

RFC 3194                An update on the H ratio           November 2001

Anが2001年11月にH比でアップデートするジュランドとHuitema Informational[6ページ]RFC3194

10. Full Copyright Statement

10. 完全な著作権宣言文

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

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

Durand & Huitema             Informational                      [Page 7]

ジュランドとHuitema情報です。[7ページ]