RFC3570 日本語訳
3570 Content Internetworking (CDI) Scenarios. P. Rzewski, M. Day, D.Gilletti. July 2003. (Format: TXT=42432 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group P. Rzewski
Request for Comments: 3570 Media Publisher, Inc.
Category: Informational M. Day
Cisco
D. Gilletti
July 2003
コメントを求めるワーキンググループP.ルゼフスキーの要求をネットワークでつないでください: 3570年のメディア出版社Inc.カテゴリ: 情報のM.コクチマスD.Gilletti2003年7月日
Content Internetworking (CDI) Scenarios
満足しているインターネットワーキング(CDI)シナリオ
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 (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 All rights reserved。
Abstract
要約
In describing content internetworking as a technology targeted for use in production networks, it is useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. The scenarios presented here seek to provide some concrete examples of what content internetworking is, and also to provide a basis for evaluating content internetworking proposals.
生産ネットワークにおける使用のために狙う技術として満足しているインターネットワーキングを記述する際に、2つの満足しているネットワークが、内部連絡すると決めると起こるかもしれないイベントの系列に関する例を提供するのは役に立ちます。 ここに提示されたシナリオは、満足しているインターネットワーキングが何であるかに関するいくつかの具体的な実例を提供して、また、満足しているインターネットワーキング提案を評価する基礎を提供しようとします。
Table of Contents
目次
1. Introduction...................................................2
1.1. Terminology..............................................3
2. Special Cases of Content Networks..............................3
2.1. Publishing Content Network...............................3
2.2. Brokering Content Network................................3
2.3. Local Request-Routing Content Network....................4
3. Content Internetworking Arrangements...........................5
4. Content Internetworking Scenarios..............................5
4.1. General Content Internetworking..........................6
4.2. BCN providing ACCOUNTING INTERNETWORKING and
REQUEST-ROUTING INTERNETWORKING..........................9
4.3. BCN providing ACCOUNTING INTERNETWORKING................11
4.4. PCN ENLISTS multiple CNs................................12
4.5. Multiple CNs ENLIST LCN.................................13
5. Security Considerations.......................................15
5.1. Threats to Content Internetworking......................15
5.1.1. Threats to the CLIENT.............................15
1. 序論…2 1.1. 用語…3 2. 満足しているネットワークの特別なケース…3 2.1. 満足しているネットワークを発表します…3 2.2. 満足しているネットワークを仲介します…3 2.3. ローカルの要求ルート設定満足しているネットワーク…4 3. 満足しているインターネットワーキングアレンジメント…5 4. 満足しているインターネットワーキングシナリオ…5 4.1. 一般満足しているインターネットワーキング…6 4.2. BCNの提供している会計インターネットワーキングと要求ルーティングインターネットワーキング…9 4.3. インターネットワーキングを説明するBCN提供…11 4.4. PCN ENLISTS倍数CNs…12 4.5. 複数のCNsがLCNの協力を得ます…13 5. セキュリティ問題…15 5.1. 満足しているインターネットワーキングへの脅威…15 5.1.1. クライアントへの脅威…15
Rzewski, et al. Informational [Page 1] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [1ページ]情報のRFC3570CDIシナリオ2003年7月
5.1.2. Threats to the PUBLISHER..........................17
5.1.3. Threats to a CN...................................17
6. Acknowledgements..............................................18
7. References....................................................18
8. Authors' Addresses............................................19
9. Full Copyright Statement......................................20
5.1.2. 出版社への脅威…17 5.1.3. CNへの脅威…17 6. 承認…18 7. 参照…18 8. 作者のアドレス…19 9. 完全な著作権宣言文…20
1. Introduction
1. 序論
In [1], the concept of a "content network" is introduced and described. In addition to describing some general types of content networks, it also describes motivations for allowing content networks to interconnect (defined as "content internetworking").
[1]では、「満足しているネットワーク」の概念は、紹介されて、説明されます。 また、何人かの一般型の満足しているネットワークについて説明することに加えて、それは満足しているネットワークが内部連絡されるのを(「満足しているインターネットワーキング」と定義されます)許容することに関する動機について説明します。
In describing content internetworking as a technology targeted for use in production networks, it's useful to provide examples of the sequence of events that may occur when two content networks decide to interconnect. Naturally, different types of content networks may be created due to different business motivations, and so many combinations are likely.
生産ネットワークにおける使用のために狙う技術として満足しているインターネットワーキングを記述する際に、2つの満足しているネットワークが、内部連絡すると決めると起こるかもしれないイベントの系列に関する例を提供するのは役に立ちます。 当然、異なったタイプの満足しているネットワークは異なったビジネス動機のため創設されるかもしれません、そして、とても多くの組み合わせがありそうです。
This document first provides detailed examples of special cases of content networks that are specifically designed to participate in content internetworking (Section 2). We then discuss the steps that would be taken in order to "bring up" or "tear down" a content internetworking arrangement (Section 3). Next we provide some detailed examples of how content networks (such as those from Section 2) could interconnect (Section 4). Finally, we describe any security considerations that arise specifically from the examples presented here (Section 5).
このドキュメントは最初に、満足しているインターネットワーキング(セクション2)に参加するように明確に設計されている満足しているネットワークの特別なケースの詳細な例を提供します。 そして、私たちは満足しているインターネットワーキングアレンジメント(セクション3)を「持って来る」か、または「取りこわす」ために取られる方法について議論します。 次に、私たちは満足しているネットワーク(セクション2からのそれらなどの)がどう内部連絡されることができたかに関する(セクション4)いくつかの詳細な例を提供します。 最終的に、私たちは特にここに提示された例(セクション5)から起こるどんなセキュリティ問題についても説明します。
The scenarios presented here answer two distinct needs:
シナリオはここに答えtwoに異なった必要性を提示しました:
1. To provide some concrete examples of what content internetworking
is, and
1. そしてどんな満足しているインターネットワーキングに関するいくつかの具体的な実例が提供するためには、そうであるか。
2. To provide a basis for evaluating content internetworking
proposals.
2. 満足しているインターネットワーキング提案を評価する基礎を提供するために。
A number of content internetworking systems have been implemented, but there are few published descriptions. One such description is [2].
多くの満足しているインターネットワーキングシステムが導入されましたが、発行された記述がわずかしかありません。 そのような記述の1つは[2]です。
1.1. Terminology
1.1. 用語
Terms in ALL CAPS are defined in [1] except for the following terms defined below in this document: PCN, BCN, and LCN. Additionally, the term SLA is used as an abbreviation for Service Level Agreement.
以下で本書では定義された次の用語を除いて、すべて大文字の用語は[1]で定義されます: PCN、BCN、およびLCN。 さらに、用語SLAはService Level Agreementに略語として使用されます。
Rzewski, et al. Informational [Page 2] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [2ページ]情報のRFC3570CDIシナリオ2003年7月
2. Special Cases of Content Networks
2. 満足しているネットワークの特別なケース
A CN may have REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING interfaces. However, some participating networks may gravitate toward particular subsets of the CONTENT INTERNETWORKING interfaces. Others may be seen differently in terms of how they relate to their CLIENT bases. This section describes these refined cases of the general CN case so they may be available for easier reference in the further development of CONTENT INTERNETWORKING scenarios. The special cases described are the Publishing Content Network, the Brokering Content Network, and the Local Request-Routing Content Network.
CNには、REQUEST-ルート設定、DISTRIBUTION、およびACCOUNTINGインタフェースがあるかもしれません。 しかしながら、CONTENT INTERNETWORKINGインタフェースの特定の部分集合に向かって引き寄せられる参加ネットワークもあるかもしれません。 彼らがどう自分達のCLIENTベースに関連するかに関して他のものは別の角度から見られるかもしれません。 このセクションは一般的なCNの洗練されたケースがCONTENT INTERNETWORKINGシナリオのさらなる開発における、より簡単な参照に利用可能であることができなるようにケースに入れるこれらについて説明します。 説明された特別なケースは、出版Content Networkと、Brokering Content Networkと、Local Request-ルート設定Content Networkです。
2.1. Publishing Content Network
2.1. 満足しているネットワークを発表します。
A Publishing Content Network (PCN), maintained by a PUBLISHER, contains an ORIGIN and has a NEGOTIATED RELATIONSHIP with two or more CNs. A PCN may contain SURROGATES for the benefit of serving some CONTENT REQUESTS locally, but does not intend to allow its SURROGATES to serve CONTENT on behalf of other PUBLISHERS.
PUBLISHERによって維持された出版Content Network(PCN)は2CNsと共にORIGINを含んでいて、NEGOTIATED RELATIONSHIPを持っています。 PCNは、局所的にいくつかのCONTENT REQUESTSに役立つ利益のためのSURROGATESを含むかもしれませんが、SURROGATESが他のPUBLISHERSを代表してCONTENTに役立つのを許容しないつもりです。
Several implications follow from knowing that a particular CN is a PCN. First, the PCN contains the AUTHORITATIVE REQUEST-ROUTING SYSTEM for the PUBLISHER's CONTENT. This arrangement allows the PUBLISHER to determine the distribution of CONTENT REQUESTS among ENLISTED CNs. Second, it implies that the PCN need only participate in a subset of CONTENT INTERNETWORKING. For example, a PCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to receive DISTRIBUTION ADVERTISEMENTS, it need not send them. Similarly, a PCN's REQUEST-ROUTING INTERNETWORKING SYSTEM has no reason to send AREA ADVERTISEMENTS. Finally, a PCN's ACCOUNTING INTERNETWORKING SYSTEM need only be able to receive ACCOUNTING data, it need not send it.
特定のCNがPCNであることを知るのからいくつかの含意が従います。 まず最初に、PCNはPUBLISHERのもののためのAUTHORITATIVE REQUEST-ROUTING SYSTEM CONTENTを含みます。 このアレンジメントで、PUBLISHERはENLISTED CNsの中でCONTENT REQUESTSの分配を決定できます。 2番目に、それは、PCNがCONTENT INTERNETWORKINGの部分集合に参加するだけでよいのを含意します。 例えば、PCNのDISTRIBUTION INTERNETWORKING SYSTEMがDISTRIBUTION ADVERTISEMENTSを受け取るだけでよいことができる、それは彼らを送る必要はありません。 同様に、PCNのREQUEST-ROUTING INTERNETWORKING SYSTEMには、AREA ADVERTISEMENTSを送る理由が全くありません。 最終的に、PCNのACCOUNTING INTERNETWORKING SYSTEMがACCOUNTINGデータを受け取るだけでよいことができる、それはそれを送る必要はありません。
2.2. Brokering Content Network
2.2. 満足しているネットワークを仲介します。
A Brokering Content Network (BCN) is a network that does not operate its own SURROGATES. Instead, a BCN operates only CIGs as a service on behalf other CNs. A BCN may therefore be regarded as a "clearinghouse" for CONTENT INTERNETWORKING information.
Brokering Content Network(BCN)はそれ自身のSURROGATESを運用しないネットワークです。 代わりに、BCNはサービスとして他の利益CNsでCIGsだけを操作します。 したがって、BCNはCONTENT INTERNETWORKING情報のための「情報センター」と見なされるかもしれません。
For example, a BCN may choose to participate in DISTRIBUTION INTERNETWORKING and/or REQUEST-ROUTING INTERNETWORKING in order to aggregate ADVERTISEMENTS from one set of CNs into a single update stream for the benefit of other CNs. To name a single specific example, a BCN could aggregate CONTENT SIGNALS from CNs that represent PUBLISHERS into a single update stream for the benefit of CNs that contain SURROGATES. A BCN may also choose to participate in
例えば、BCNは、他のCNsの利益のためにただ一つのアップデートストリームへのCNsの1セットからADVERTISEMENTSに集めるためにDISTRIBUTION INTERNETWORKING、そして/または、REQUEST-ROUTING INTERNETWORKINGに参加するのを選ぶかもしれません。 ただ一つの特定の例を命名するために、BCNはSURROGATESを含むCNsの利益のためにただ一つのアップデートストリームにPUBLISHERSを表すCNsからCONTENT SIGNALSに集めることができました。 また、BCNは、中で参加するのを選ぶかもしれません。
Rzewski, et al. Informational [Page 3] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [3ページ]情報のRFC3570CDIシナリオ2003年7月
ACCOUNTING INTERNETWORKING in order to aggregate utilization data from several CNs into combined reports for CNs that represent PUBLISHERS.
ACCOUNTING INTERNETWORKING、集めるために、結合されることへの数個のCNsからの利用データはPUBLISHERSを表すCNsを届け出ます。
This definition of a BCN implies that a BCN's CIGs would implement the sending and/or receiving of any combination of ADVERTISEMENTS and ACCOUNTING data as is necessary to provide desired services to other CONTENT NETWORKS. For example, if a BCN is only interested in aggregating ACCOUNTING data on behalf of other CNs, it would only need to have an ACCOUNTING INTERNETWORKING interface on its CIGs.
BCNのこの定義は、BCNのCIGsがそのままで他のCONTENT NETWORKSに対する必要なサービスを提供するのに必要な状態でADVERTISEMENTSとACCOUNTINGデータのどんな組み合わせの発信、そして/または、受信も実装するのを含意します。 例えば、BCNが他のCNsを代表してACCOUNTINGデータに集めるだけでありたい場合にだけ、それはCIGsでACCOUNTING INTERNETWORKINGインタフェースを必要とするでしょう。
2.3. Local Request-Routing Content Network
2.3. ローカルの要求ルート設定満足しているネットワーク
Another type of CN is the Local Request-Routing CONTENT NETWORK (LCN). An LCN is defined as a type of network where CLIENTS' CONTENT REQUESTS are always handled by some local SERVER (such as a caching proxy [1]). In this context, "local" is taken to mean that both the CLIENT and SERVER are within the same administrative domain, and there is an administrative motivation for forcing the local mapping. This type of arrangement is common in enterprises where all CONTENT REQUESTS must be directed through a local SERVER for access control purposes.
CNの別のタイプはLocal Request-ルート設定CONTENT NETWORK(LCN)です。 いくらかの地方のSERVERによって扱われて、LCNはいつもCLIENTSのCONTENT REQUESTSがそうである一種のネットワークと定義されます。(キャッシュしているプロキシ[1])のように。 このような関係においては、「地方」であることは、CLIENTとSERVERの両方が同じ管理ドメイン、以内とそこにあることを意味するために取っているのが、ローカルのマッピングを強制することに関する管理動機であるということです。 このタイプのアレンジメントはアクセス管理目的のために地方のSERVERを通してすべてのCONTENT REQUESTSを向けなければならないところで企業で一般的です。
As implied by the name, the LCN creates an exception to the rule that there is a single AUTHORITATIVE REQUEST-ROUTING SYSTEM for a particular item of CONTENT. By directing CONTENT REQUESTS through the local SERVER, CONTENT RESPONSES may be given to CLIENTS without first referring to the AUTHORITATIVE REQUEST-ROUTING SYSTEM. Knowing this to be true, other CNs may seek a NEGOTIATED RELATIONSHIP with an LCN in order to perform DISTRIBUTION into the LCN and receive ACCOUNTING data from it. Note that once SERVERS participate in DISTRIBUTION INTERNETWORKING and ACCOUNTING INTERNETWORKING, they effectively take on the role of SURROGATES. However, an LCN would not intend to allow its SURROGATES to be accessed by non-local CLIENTS.
その名の示すように、LCNはCONTENTの特定の項目のために独身のAUTHORITATIVE REQUEST-ROUTING SYSTEMがあるという規則への例外を作成します。 地方のSERVERを通してCONTENT REQUESTSを指示することによって、AUTHORITATIVE REQUEST-ROUTING SYSTEMへの最初に参照することのないCLIENTSにCONTENT RESPONSESを与えるかもしれません。 これが本当であることを知っていて、他のCNsは、LCNにDISTRIBUTIONを実行して、それからACCOUNTINGデータを受け取るためにLCNと共にNEGOTIATED RELATIONSHIPを探すかもしれません。 SERVERSがいったんDISTRIBUTION INTERNETWORKINGとACCOUNTING INTERNETWORKINGに参加する後、事実上、彼らがSURROGATESの役割を引き受けることに注意してください。 しかしながら、LCNは、SURROGATESが非地方のCLIENTSによってアクセスされるのを許容しないつもりでしょう。
This set of assumptions implies multiple things about the LCN's CONTENT INTERNETWORKING relationships. First, it is implied that the LCN's DISTRIBUTION INTERNETWORKING SYSTEM need only be able to send DISTRIBUTION ADVERTISEMENTS, it need not receive them. Second, it is implied that an LCN's ACCOUNTING INTERNETWORKING SYSTEM need only be able to send ACCOUNTING data, it need not receive it. Finally, due to the locally defined REQUEST-ROUTING, the LCN would not participate in REQUEST-ROUTING INTERNETWORKING.
このセットの仮定はLCNのCONTENT INTERNETWORKING関係に関して複数のことを含意します。 まず最初にLCNのDISTRIBUTION INTERNETWORKING SYSTEMがDISTRIBUTION ADVERTISEMENTSを送るだけでよいことができるのが含意されて、それは彼らを受ける必要はありません。 2番目に、LCNのACCOUNTING INTERNETWORKING SYSTEMがデータをACCOUNTINGに送るだけでよいことができるのが含意されて、それはそれを受ける必要はありません。 最終的に、局所的に定義されたREQUEST-ルート設定のため、LCNはREQUEST-ROUTING INTERNETWORKINGに参加しないでしょう。
Rzewski, et al. Informational [Page 4] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [4ページ]情報のRFC3570CDIシナリオ2003年7月
3. Content Internetworking Arrangements
3. 満足しているインターネットワーキングアレンジメント
When the controlling interests of two CNs decide to interconnect their respective networks (such as for business reasons), it is expected that multiple steps would need to occur.
2CNsの制御関心が、彼らのそれぞれのネットワーク(ビジネス目的などの)とインタコネクトすると決めると、複数のステップが、起こる必要であると予想されます。
The first step would be the creation of a NEGOTIATED RELATIONSHIP. This relationship would most likely take the form of a legal document that describes the services to be provided, cost of services, SLAs, and other stipulations. For example, if an ORIGINATING CN wished to leverage another CN's reach into a particular country, this would be laid out in the NEGOTIATED RELATIONSHIP.
第一歩はNEGOTIATED RELATIONSHIPの作成でしょう。 この関係はたぶん提供するためにサービスについて説明する法律関係書類のフォーム、サービスの費用、SLA、および他の約款を取るでしょう。 例えば、ORIGINATING CNが別のCNの範囲を特定の国に利用したいなら、これはNEGOTIATED RELATIONSHIPで広げられるでしょうに。
The next step would be to configure CONTENT INTERNETWORKING protocols on the CIGs of the respective CNs in order to technically support the terms of the NEGOTIATED RELATIONSHIP. To follow our previous example, this could include the configuration of the ENLISTED CN's CIGs in a particular country to send DISTRIBUTION ADVERTISEMENTS to the CIGs of the ORIGINATING CN. In order to configure these protocols, technical details (such as CIG addresses/hostnames and authentication information) would be exchanged by administrators of the respective CNs.
次のステップはNEGOTIATED RELATIONSHIPの用語を技術的にサポートするためにそれぞれのCNsのCIGsでCONTENT INTERNETWORKINGプロトコルを構成するだろうことです。 私たちの前の例に倣うなら、これは、ORIGINATING CNのCIGsにDISTRIBUTION ADVERTISEMENTSを送るために特定の国でのENLISTED CNのCIGsの構成を含むかもしれません。 これらのプロトコルを構成するために、技術的詳細(CIGアドレス/ホスト名や認証情報などの)はそれぞれのCNsの管理者によって交換されるでしょう。
Note also that some terms of the NEGOTIATED RELATIONSHIP would be upheld through means outside the scope of CDI protocols. These could include non-technical terms (such as financial settlement) or other technical terms (such as SLAs).
また、NEGOTIATED RELATIONSHIPのいくつかの用語がCDIプロトコルの範囲の外の手段で是認されることに注意してください。 これらは非技術系の用語(金銭的解決などの)か他の専門用語(SLAなどの)を含むかもしれません。
In the event that the controlling interests of two CNs no longer wish to have their networks interconnected, it is expected that these tasks would be undone. That is, the protocol configurations would be changed to cease the movement of ADVERTISEMENTS and/or ACCOUNTING data between the networks, and the NEGOTIATED RELATIONSHIP would be legally terminated.
CNsがもう願っていない2の制御関心がそうした場合、彼らのネットワークは内部連絡されて、これらのタスクが元に戻されると予想されます。 ネットワークの間のADVERTISEMENTS、そして/または、ACCOUNTINGデータの動きをやめるためにすなわち、プロトコル構成を変えるでしょう、そして、NEGOTIATED RELATIONSHIPを法的に終えるでしょう。
4. Content Internetworking Scenarios
4. 満足しているインターネットワーキングシナリオ
This section provides several scenarios that may arise in CONTENT INTERNETWORKING implementations.
このセクションはCONTENT INTERNETWORKING実装で起こるかもしれないいくつかのシナリオを提供します。
Note that we obviously cannot examine every single permutation. Specifically, it should be noted that:
私たちが明らかにあらゆる順列を調べることができるというわけではないことに注意してください。 明確に、以下のことに注意されるべきです。
o Any one of the interconnected CNs may have other CONTENT
INTERNETWORKING arrangements that may or may not be transitive to
the relationships being described in the diagram.
o インタコネクトされたCNsのいずれにはも、他のダイヤグラムで説明される関係に遷移的であるかもしれないCONTENT INTERNETWORKINGアレンジメントがあるかもしれません。
Rzewski, et al. Informational [Page 5] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [5ページ]情報のRFC3570CDIシナリオ2003年7月
o The graphical figures do not illustrate the CONTENT REQUEST paths.
It is assumed that a REQUEST-ROUTING SYSTEM eventually returns to
the CLIENT the IP address of the SURROGATE deemed appropriate to
honor the CLIENT's CONTENT REQUEST.
o グラフィカルな数字はCONTENT REQUEST経路を例証しません。 REQUEST-ROUTING SYSTEMが結局CLIENTのCONTENT REQUESTを尊敬するのが適切であると考えられたSURROGATEのIPアドレスをCLIENTに返すと思われます。
The scenarios described include a general case, two cases in which BCNs provide limited interfaces, a case in which a PCN enlists the services of multiple CNs, and a case in which multiple CNs enlist the services of an LCN.
説明されたシナリオは一般的なケース(BCNsが限られたインタフェース、PCNが複数のCNsのサービスを得る場合、および複数のCNsがLCNのサービスを得る場合を提供する2つの場合)を含んでいます。
4.1. General Content Internetworking
4.1. 一般満足しているインターネットワーキング
This scenario considers the general case where two or more existing CNs wish to establish a CONTENT INTERNETWORKING relationship in order to provide increased scale and reach for their existing customers. It assumes that all of these CNs already provide REQUEST-ROUTING, DISTRIBUTION, and ACCOUNTING services and that they will continue to provide these services to existing customers as well as offering them to other CNs.
このシナリオは、2既存のCNsが提供するためにCONTENT INTERNETWORKING関係を確立したがっている一般的なケースが彼らの既存の顧客のためにスケールと範囲を増強したと考えます。 それはこれらのCNsのすべてが既にREQUEST-ルート設定、DISTRIBUTION、およびACCOUNTINGにサービスを供給して、他のCNsに彼らを提供することと同様に既存の顧客に対するこれらのサービスを提供し続けると仮定します。
In this scenario, these CNs would interconnect with others via a CIG that provides a REQUEST-ROUTING INTERNETWORKING SYSTEM, a DISTRIBUTION INTERNETWORKING SYSTEM, and an ACCOUNTING INTERNETWORKING SYSTEM. The net result of this interconnection would be that a larger set of SURROGATES will now be available to the CLIENTS.
このシナリオでは、これらのCNsは他のものと共にREQUEST-ROUTING INTERNETWORKING SYSTEM、DISTRIBUTION INTERNETWORKING SYSTEM、およびACCOUNTING INTERNETWORKING SYSTEMを提供するCIGを通して内部連絡するでしょう。 このインタコネクトの最終結果は現在SURROGATESの、より大きいセットがCLIENTSに利用可能になるということでしょう。
Figure 1 shows three CNs which have interconnected to provide greater scale and reach to their existing customers. They are all participating in DISTRIBUTION INTERNETWORKING, REQUEST-ROUTING INTERNETWORKING, and ACCOUNTING INTERNETWORKING.
図1は、より大きいスケールを提供して、彼らの存在に達するように内部連絡した3CNsに顧客を示しています。 それらは、DISTRIBUTION INTERNETWORKINGへのすべての参加と、REQUEST-ROUTING INTERNETWORKINGと、ACCOUNTING INTERNETWORKINGです。
As a result of the NEGOTIATED RELATIONSHIPS it is assumed that:
NEGOTIATED RELATIONSHIPSの結果、以下のことと思われます。
1. CONTENT that has been INJECTED into any one of these ORIGINATING
CNs may be distributed into any other ENLISTED CN.
1. INJECTEDであるこれらのORIGINATING CNsのどんなもCONTENTはいかなる他のENLISTED CNにも分配されるかもしれません。
2. Commands affecting the DISTRIBUTION of CONTENT may be issued
within the ORIGINATING CN, or may also be issued within the
ENLISTED CN. The latter case allows local decisions to be made
about DISTRIBUTION within the ENLISTED CN, but such commands would
not control DISTRIBUTION within the ORIGINATING CN.
2. CONTENTのDISTRIBUTIONに影響するコマンドを、ORIGINATING CNの中で発行するか、またはまた、ENLISTED CNの中で発行するかもしれません。 後者のケースはENLISTED CNの中でDISTRIBUTIONの周りで作られているというローカルの決定を許しますが、そのようなコマンドはORIGINATING CNの中でDISTRIBUTIONを制御しないでしょう。
3. ACCOUNTING information regarding CLIENT access and/or DISTRIBUTION
actions will be made available to the ORIGINATING CN by the
ENLISTED CN.
3. CLIENTアクセス、そして/または、DISTRIBUTION動作のACCOUNTING情報をENLISTED CNでORIGINATING CNに利用可能にするでしょう。
Rzewski, et al. Informational [Page 6] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [6ページ]情報のRFC3570CDIシナリオ2003年7月
4. The ORIGINATING CN would provide this ACCOUNTING information to
the PUBLISHER based on existing Service Level Agreements (SLAs).
4. ORIGINATING CNは既存のサービス・レベル・アグリーメント(SLA)に基づくPUBLISHERにこのACCOUNTING情報を供給するでしょう。
5. CONTENT REQUESTS by CLIENTS may be directed to SURROGATES within
any of the ENLISTED CNs.
5. CLIENTSによるCONTENT REQUESTSはENLISTED CNsのどれかの中のSURROGATESに向けられるかもしれません。
The decision of where to direct an individual CONTENT REQUEST may be dependent upon the DISTRIBUTION and REQUEST-ROUTING policies associated with the CONTENT being requested as well as the specific algorithms and methods used for directing these requests. For example, a REQUEST-ROUTING policy for a piece of CONTENT may indicate multiple versions exist based on the spoken language of a CLIENT. Therefore, the REQUEST-ROUTING SYSTEM of an ENLISTED CN would likely direct a CONTENT REQUEST to a SURROGATE known to be holding a version of CONTENT of a language that matches that of a CLIENT.
どこで個々のCONTENT REQUESTを指示するかに関する決定は要求されているCONTENTと特定のアルゴリズムとこれらの要求を指示するのに使用されるメソッドに関連しているDISTRIBUTIONとREQUEST-ルート設定方針に依存しているかもしれません。 例えば、CONTENTの1つの断片のためのREQUEST-ルート設定方針は、複数のバージョンがCLIENTの話し言葉に基づいて存在するのを示すかもしれません。 したがって、ENLISTED CNのREQUEST-ROUTING SYSTEMはおそらくCLIENTのものに合っている言語のCONTENTのバージョンを保持しているのが知られているSURROGATEにCONTENT REQUESTを向けるでしょう。
Rzewski, et al. Informational [Page 7] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [7ページ]情報のRFC3570CDIシナリオ2003年7月
Figure 1 - General CONTENT INTERNETWORKING
図1--一般満足しているインターネットワーキング
+--------------+ +--------------+
| CN A | | CN B |
|..............| +---------+ +---------+ |..............+
| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
|..............| | CONTENT | | CONTENT | |..............|
| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
+--------------+ +---------+ +---------+ +--------------+
| ^ \^ \ \ ^/ ^/ ^/ | ^
v | \\ \\ \\ // // // v |
+--------------+ \\ \\ \\ // // // +--------------+
| SURROGATES | \\ v\ v\ /v /v // | SURROGATES |
+--------------+ \\+---------+// +--------------+
^ | v| |v ^ |
| | | CONTENT | | |
| | |INTWRKING| | |
| | | GATEWAY | | |
| | | | | |
| | +---------+ | |
| | ^| ^| ^| | |
| | || || || | |
| | |v |v |v | |
| | +--------------+ | |
| | | CN C | | |
| | |..............| | |
| | | REQ-ROUTING | | |
| | |..............| | |
\ \ | DISTRIBUTION | / /
\ \ |..............| / /
\ \ | ACCOUNTING | / /
\ \ |--------------| / /
\ \ | ^ / /
\ \ v | / /
\ \ +--------------+ / /
\ \ | SURROGATES | / /
\ \ +--------------+ / /
\ \ | ^ / /
\ \ | | / /
\ \ v | / /
\ \ +---------+ / /
\ \-->| CLIENTS |---/ /
\----| |<---/
+---------+
+--------------+ +--------------+ | CN A| | CN B| |..............| +---------+ +---------+ |..............+ | REQ-ルーティング|<=>| |<=>| |<=>| REQ-ルーティング| |..............| | 内容| | 内容| |..............| | 分配|<=>|INTWRKING|<=>|INTWRKING|<=>| 分配| |..............| | ゲートウェイ| | ゲートウェイ| |..............| | 会計|<=>| |<=>| |<=>| 会計| +--------------+ +---------+ +---------+ +--------------+ | ^ \^ \ \ ^/ ^/ ^/ | ^v| \\\\\\//////v| +--------------+ \\ \\ \\ // // // +--------------+ | 代理| \\v\v\/v /v //| 代理| +--------------+ \\+---------+// +--------------+ ^ | v| |^に対して| | | | 内容| | | | | |INTWRKING| | | | | | ゲートウェイ| | | | | | | | | | | +---------+ | | | | ^| ^| ^| | | | | || || || | | | | |v|v|v| | | | +--------------+ | | | | | CN C| | | | | |..............| | | | | | REQ-ルーティング| | | | | |..............| | | \ \ | 分配| / / \ \ |..............| / / \ \ | 会計| / / \ \ |--------------| / / \ \ | ^//\\v| / / \ \ +--------------+ / / \ \ | 代理| / / \ \ +--------------+ / / \ \ | ^ / / \ \ | | //\\v| / / \ \ +---------+ / / \ \-->| クライアント|---/ / \----| | <、-、--/ +---------+
Rzewski, et al. Informational [Page 8] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [8ページ]情報のRFC3570CDIシナリオ2003年7月
4.2. BCN providing ACCOUNTING INTERNETWORKING and REQUEST-ROUTING
INTERNETWORKING
4.2. BCNの提供している会計インターネットワーキングと要求ルーティングインターネットワーキング
This scenario describes the case where a single entity (BCN A) performs ACCOUNTING INTERNETWORKING and REQUEST-ROUTING INTERNETWORKING functions, but has no inherent DISTRIBUTION or DELIVERY capabilities. A potential configuration which illustrates this concept is given in Figure 2.
このシナリオは単一体(BCN A)がACCOUNTING INTERNETWORKINGとREQUEST-ROUTING INTERNETWORKING機能を実行しますが、固有のDISTRIBUTIONかDELIVERY能力を全く持っていないケースについて説明します。 図2でこの概念を例証する潜在的構成を与えます。
In the scenario shown in Figure 2, BCN A is responsible for collecting ACCOUNTING information from multiple CONTENT NETWORKS (CN A and CN B) to provide a clearinghouse/settlement function, as well as providing a REQUEST-ROUTING service for CN A and CN B.
図2のシナリオでは、BCN AはREQUEST-ルート設定サービスをCN AとCN Bに供給することと同様に情報センター/決済機能を提供するために複数のCONTENT NETWORKS(CN AとCN B)からACCOUNTING情報を集めるのに責任があります。
In this scenario, CONTENT is injected into either CN A or CN B and its DISTRIBUTION between these CNs is controlled via the DISTRIBUTION INTERNETWORKING SYSTEMS within the CIGs. The REQUEST-ROUTING SYSTEM provided by BCN A is informed of the ability to serve a piece of CONTENT from a particular CONTENT NETWORK by the REQUEST-ROUTING SYSTEMS within the interconnected CIGs.
このシナリオでは、CONTENTはCN AかCN Bのどちらかに注がれます、そして、これらのCNsの間のDISTRIBUTIONはCIGsの中のDISTRIBUTION INTERNETWORKING SYSTEMSを通して制御されます。 BCN Aによって提供されたREQUEST-ROUTING SYSTEMはインタコネクトの中のREQUEST-ROUTING SYSTEMS CIGsで特定のCONTENT NETWORKからCONTENTの1つの断片に役立つ能力において知識があります。
BCN A collects statistics and usage information via the ACCOUNTING INTERNETWORKING SYSTEM and disseminates that information to CN A and CN B as appropriate.
BCN AはACCOUNTING INTERNETWORKING SYSTEMを通して統計と用法情報を集めて、適宜CN AとCN Bにその情報を広めます。
As illustrated in Figure 2, there are separate REQUEST-ROUTING SYSTEMS employed within CN A and CN B. If the REQUEST-ROUTING SYSTEM provided by BCN A is the AUTHORITATIVE REQUEST-ROUTING SYSTEM for a given piece of CONTENT this is not a problem. However, each individual CN may also provide the AUTHORITATIVE REQUEST-ROUTING SYSTEM for some portion of its PUBLISHER customers. In this case care must be taken to ensure that the there is one and only one AUTHORITATIVE REQUEST-ROUTING SYSTEM identified for each given CONTENT object.
別々の採用しているREQUEST-ROUTING SYSTEMSは図2で例証して、あるとき、AがBCNによるCONTENTの与えられた断片のためのAUTHORITATIVE REQUEST-ROUTING SYSTEMであるなら、これはCN AとCN B.If REQUEST-ROUTING SYSTEMの中では、問題ではありません。 しかしながら、また、それぞれの個々のCNはPUBLISHER顧客の何らかの一部にAUTHORITATIVE REQUEST-ROUTING SYSTEMを提供するかもしれません。 この場合それを確実にするために注意しなければならない、それぞれの与えられたCONTENTオブジェクトのために特定された唯一無二の1AUTHORITATIVE REQUEST-ROUTING SYSTEMがあります。
Rzewski, et al. Informational [Page 9] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [9ページ]情報のRFC3570CDIシナリオ2003年7月
Figure 2 - BCN providing ACCOUNTING INTERNETWORKING and
REQUEST-ROUTING INTERNETWORKING
図2--BCNの提供している会計インターネットワーキングと要求ルーティングインターネットワーキング
+--------------+
| BCN A |
|..............| +-----------+
| REQ-ROUTING |<===>| |
|..............| | CONTENT |
| ACCOUNTING |<===>| INTWRKING |
+--------------+ | GATEWAY |
| |
+-----------+
^| ^| ^| ^|
+--------------+ // // \\ \\ +--------------+
| CN A | |v |v |v |v | CN B |
|..............| +---------+ +---------+ |..............|
| REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING |
|..............| | CONTENT | | CONTENT | |..............|
| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
+--------------+ +---------+ +---------+ +--------------+
| ^ | ^
v | v |
+--------------+ +--------------+
| SURROGATES | | SURROGATES |
+--------------+ +--------------+
^ \ ^ /
\ \ / /
\ \ / /
\ \ / /
\ \ +---------+ / /
\ \---->| CLIENTS |-----/ /
\------| |<-----/
+---------+
+--------------+ | BCN A| |..............| +-----------+ | REQ-ルーティング|<==>|、| |..............| | 内容| | 会計|<==>| INTWRKING| +--------------+ | ゲートウェイ| | | +-----------+ ^| ^| ^| ^| +--------------+ // // \\ \\ +--------------+ | CN A| |v|v|v|v| CN B| |..............| +---------+ +---------+ |..............| | REQ-ルーティング|<=>|、|、| |<=>| REQ-ルーティング| |..............| | 内容| | 内容| |..............| | 分配|<=>|INTWRKING|<=>|INTWRKING|<=>| 分配| |..............| | ゲートウェイ| | ゲートウェイ| |..............| | 会計|<=>|、|、| |<=>| 会計| +--------------+ +---------+ +---------+ +--------------+ | ^ | ^v| v| +--------------+ +--------------+ | 代理| | 代理| +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| クライアント|-----/ / \------| | <、-、-、-、--/ +---------+
Rzewski, et al. Informational [Page 10] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [10ページ]情報のRFC3570CDIシナリオ2003年7月
4.3. BCN providing ACCOUNTING INTERNETWORKING
4.3. 会計インターネットワーキングを提供するBCN
This scenario describes the case where a single entity (BCN A) performs ACCOUNTING INTERNETWORKING to provide a clearinghouse/ settlement function only. In this scenario, BCN A would enter into NEGOTIATED RELATIONSHIPS with multiple CNs that each perform their own DISTRIBUTION INTERNETOWRKING and REQUEST-ROUTING INTERNETWORKING as shown in FIGURE 3.
このシナリオは単一体(BCN A)が情報センター/決済機能だけを提供するためにACCOUNTING INTERNETWORKINGを実行するケースについて説明します。 このシナリオでは、BCN Aは図3に示されるようにそれぞれそれら自身のDISTRIBUTION INTERNETOWRKINGを実行する複数のCNsとREQUEST-ROUTING INTERNETWORKINGとNEGOTIATED RELATIONSHIPSに入るでしょう。
Figure 3 - BCN providing ACCOUNTING INTERNETWORKING
図3--会計インターネットワーキングを提供するBCN
+--------------+
| BCN A |
|..............| +-----------+
| ACCOUNTING |<===>| |
+--------------+ | CONTENT |
| INTWRKING |
| GATEWAY |
| |
+-----------+
^| ^|
+--------------+ // \\ +--------------+
| CN A | |v |v | CN B |
|..............| +---------+ +---------+ |..............|
| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
|..............| | CONTENT | | CONTENT | |..............|
| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
+--------------+ +---------+ +---------+ +--------------+
| ^ | ^
v | v |
+--------------+ +--------------+
| SURROGATES | | SURROGATES |
+--------------+ +--------------+
^ \ ^ /
\ \ / /
\ \ / /
\ \ / /
\ \ +---------+ / /
\ \---->| CLIENTS |-----/ /
\------| |<-----/
+---------+
+--------------+ | BCN A| |..............| +-----------+ | 会計|<==>|、| +--------------+ | 内容| | INTWRKING| | ゲートウェイ| | | +-----------+ ^| ^| +--------------+ // \\ +--------------+ | CN A| |v|v| CN B| |..............| +---------+ +---------+ |..............| | REQ-ルーティング|<=>| |<=>| |<=>| REQ-ルーティング| |..............| | 内容| | 内容| |..............| | 分配|<=>|INTWRKING|<=>|INTWRKING|<=>| 分配| |..............| | ゲートウェイ| | ゲートウェイ| |..............| | 会計|<=>|、|、| |<=>| 会計| +--------------+ +---------+ +---------+ +--------------+ | ^ | ^v| v| +--------------+ +--------------+ | 代理| | 代理| +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| クライアント|-----/ / \------| | <、-、-、-、--/ +---------+
Rzewski, et al. Informational [Page 11] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [11ページ]情報のRFC3570CDIシナリオ2003年7月
4.4. PCN ENLISTS multiple CNs
4.4. PCN ENLISTS倍数CNs
In the previously enumerated scenarios, PUBLISHERS have not been discussed. Much of the time, it is assumed that the PUBLISHERS will allow CNs to act on their behalf. For example, a PUBLISHER may designate a particular CN to be the AUTHORITATIVE REQUEST-ROUTING SYSTEM for its CONTENT. Similarly, a PUBLISHER may rely on a particular CN to aggregate all its ACCOUNTING data, even though that data may originate at SURROGATES in multiple distant CNs. Finally, a PUBLISHER may INJECT content only into a single CN and rely on that CN to ENLIST other CNs to obtain scale and reach.
以前に列挙されたシナリオでは、PUBLISHERSについて議論していません。 よく、PUBLISHERSがCNsを彼らの代理に影響させると思われます。 例えば、PUBLISHERは、CONTENTのためのAUTHORITATIVE REQUEST-ROUTING SYSTEMになるように特定のCNを指定するかもしれません。 同様に、PUBLISHERはすべてのACCOUNTINGデータに集めるために特定のCNを当てにするかもしれません、そのデータが複数の遠方のCNsのSURROGATESで起因するかもしれませんが。 最終的にPUBLISHERは当てにするかもしれません。INJECTは、スケールを得て、達するようにENLISTもう一方CNsへのそのCNを独身のCNだけに満足して、当てにします。
However, a PUBLISHER may wish to maintain more control and take on the task of ENLISTING CNs itself, therefore acting as a PCN (Section 2.1). This scenario, shown in Figure 4, describes the case where a PCN wishes to directly enter into NEGOTIATED RELATIONSHIPS with multiple CNs. In this scenario, the PCN would operate its own CIG and enter into DISTRIBUTION INTERNETWORKING, ACCOUNTING INTERNETWORKING, and REQUEST-ROUTING INTERNETWORKING relationships with two or more CNs.
しかしながら、PUBLISHERは、より多くのコントロールを維持して、ENLISTING CNs自身に関するタスクを引き受けたがっているかもしれません、したがって、PCN(セクション2.1)として、機能します。 図4に示されたこのシナリオはPCNが直接複数のCNsとNEGOTIATED RELATIONSHIPSに入りたがっているケースについて説明します。 このシナリオでは、PCNはそれ自身のCIGを操作して、DISTRIBUTION INTERNETWORKING、ACCOUNTING INTERNETWORKING、および2CNsとのREQUEST-ROUTING INTERNETWORKING関係に入るでしょう。
Rzewski, et al. Informational [Page 12] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [12ページ]情報のRFC3570CDIシナリオ2003年7月
Figure 4 - PCN ENLISTS multiple CNs
図4--PCN ENLISTS倍数CNs
+--------------+
| PCN |
|..............| +-----------+
| REQ-ROUTING |<=>| |<---\
|..............| | CONTENT |----\\
| DISTRIBUTION |<=>| INTWRKING | \\
|..............| | GATEWAY |--\ \\
| ACCOUNTING |<=>| |<-\\ \\
+--------------+ +-----------+ \\ \\
^| ^| ^| ^| \\ ||
+--------------+ || || || \\ || || +--------------+
| CN A | |v |v |v \v |v |v | CN B |
|..............| +---------+ +---------+ |..............|
| REQ-ROUTING |<=>| | | |<=>| REQ-ROUTING |
|..............| | CONTENT | | CONTENT | |..............|
| DISTRIBUTION |<=>|INTWRKING| |INTWRKING|<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| | | |<=>| ACCOUNTING |
+--------------+ +---------+ +---------+ +--------------+
| ^ | ^
v | v |
+--------------+ +--------------+
| SURROGATES | | SURROGATES |
+--------------+ +--------------+
^ \ ^ /
\ \ / /
\ \ / /
\ \ / /
\ \ +---------+ / /
\ \---->| CLIENTS |-----/ /
\------| |<-----/
+---------+
+--------------+ | PCN| |..............| +-----------+ | REQ-ルーティング|<=>| | <、-、--\ |..............| | 内容|----\\ | 分配|<=>| INTWRKING| \\ |..............| | ゲートウェイ|--\ \\ | 会計|<=>| | <、-\\ \\ +--------------+ +-----------+ \\ \\ ^| ^| ^| ^| \\ || +--------------+ || || || \\ || || +--------------+ | CN A| |v|v|\vに対して|v|v| CN B| |..............| +---------+ +---------+ |..............| | REQ-ルーティング|<=>|、|、| |<=>| REQ-ルーティング| |..............| | 内容| | 内容| |..............| | 分配|<=>|INTWRKING| |INTWRKING|<=>| 分配| |..............| | ゲートウェイ| | ゲートウェイ| |..............| | 会計|<=>|、|、| |<=>| 会計| +--------------+ +---------+ +---------+ +--------------+ | ^ | ^v| v| +--------------+ +--------------+ | 代理| | 代理| +--------------+ +--------------+ ^ \ ^ / \ \ / / \ \ / / \ \ / / \ \ +---------+ / / \ \---->| クライアント|-----/ / \------| | <、-、-、-、--/ +---------+
4.5. Multiple CNs ENLIST LCN
4.5. 複数のCNsがLCNの協力を得ます。
A type of CN described in Section 2.3 is the LCN. In this scenario, we imagine a tightly administered CN (such as within an enterprise) has determined that all CONTENT REQUESTS from CLIENTS must be serviced locally. Likely due to a large CLIENT base in the LCN, multiple CNs determine they would like to engage in DISTRIBUTION INTERNETWORKING with the LCN in order to extend control over CONTENT objects held in the LCN's SURROGATES. Similarly, the CNs would like to engage in ACCOUNTING INTERNETWORKING with the LCN in order to receive ACCOUNTING data regarding the usage of the content in the local SURROGATES. This scenario is shown in Figure 5. Although this diagram shows a DISTRIBUTION INTERNETWORKING connection between CN A
セクション2.3で説明された一種のCNがLCNです。 このシナリオでは、私たちは、しっかり管理されたCN(企業などの)が、局所的にCLIENTSからのすべてのCONTENT REQUESTSを調整しなければならないことを決定したと想像します。 LCNの大きいCLIENTベースのためにありそうです、複数のCNsが彼らがLCNのSURROGATESで持たれていたCONTENTオブジェクトのコントロールを広げるためにLCNと共にDISTRIBUTION INTERNETWORKINGに従事したがっていることを決定します。 同様に、CNsは、地方のSURROGATESの内容の用法に関するACCOUNTINGデータを受け取るためにLCNと共にACCOUNTING INTERNETWORKINGに従事したがっています。 このシナリオは図5に示されます。 このダイヤグラムはCN Aの間のDISTRIBUTION INTERNETWORKING接続を示していますが
Rzewski, et al. Informational [Page 13] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [13ページ]情報のRFC3570CDIシナリオ2003年7月
and CN B, it should be recognized that this connection is optional and not a requirement in this scenario.
CN B、そして、この接続が任意であると認められるべきですが、このシナリオの要件は認められるべきではありません。
Figure 5 - Multiple CNs ENLIST LCN
図5--複数のCNsがLCNの協力を得ます。
+--------------+ +--------------+
| CN A | | CN B |
+..............| +---------+ +---------+ |..............+
| REQ-ROUTING |<=>| |<=>| |<=>| REQ-ROUTING |
|..............| | CONTENT | | CONTENT | |..............|
| DISTRIBUTION |<=>|INTWRKING|<=>|INTWRKING|<=>| DISTRIBUTION |
|..............| | GATEWAY | | GATEWAY | |..............|
| ACCOUNTING |<=>| |<=>| |<=>| ACCOUNTING |
+--------------+ +---------+ +---------+ +--------------+
| ^ \^ \^ ^/ ^/ | ^
v | \\ \\ // // v |
+--------------+ \\ \\ // // +--------------+
| SURROGATES | v\ v\ /v /v | SURROGATES |
+--------------+ +---------+ +--------------+
| |
| CONTENT |
|INTWRKING|
| GATEWAY |
| |
+---------+
^| ^|
|| ||
|v |v
+--------------+
| LCN A |
|..............|
| DISTRIBUTION |
|..............|
| ACCOUNTING |
|--------------|
| ^
v |
+--------------+
| SURROGATES |
+--------------+
| ^
| |
v |
+---------+
| CLIENTS |
| |
+---------+
+--------------+ +--------------+ | CN A| | CN B| +..............| +---------+ +---------+ |..............+ | REQ-ルーティング|<=>| |<=>| |<=>| REQ-ルーティング| |..............| | 内容| | 内容| |..............| | 分配|<=>|INTWRKING|<=>|INTWRKING|<=>| 分配| |..............| | ゲートウェイ| | ゲートウェイ| |..............| | 会計|<=>| |<=>| |<=>| 会計| +--------------+ +---------+ +---------+ +--------------+ | ^ \^ \^ ^/ ^/ | ^v| \\\\////v| +--------------+ \\ \\ // // +--------------+ | 代理| \対\/v /vに| 代理| +--------------+ +---------+ +--------------+ | | | 内容| |INTWRKING| | ゲートウェイ| | | +---------+ ^| ^| || || |v|+に対して--------------+ | LCN A| |..............| | 分配| |..............| | 会計| |--------------| | ^v| +--------------+ | 代理| +--------------+ | ^ | | v| +---------+ | クライアント| | | +---------+
Rzewski, et al. Informational [Page 14] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [14ページ]情報のRFC3570CDIシナリオ2003年7月
5. Security Considerations
5. セキュリティ問題
Security concerns with respect to Content Internetworking can be generally categorized into trust within the system and protection of the system from threats. The trust model utilized with Content Internetworking is predicated largely on transitive trust between the ORIGIN, REQUEST-ROUTING INTERNETWORKING SYSTEM, DISTRIBUTION INTERNETWORKING SYSTEM, ACCOUNTING INTERNETWORING SYSTEM, and SURROGATES. Network elements within the Content Internetworking system are considered to be "insiders" and therefore trusted.
一般に、システムのシステムと保護の中でContent Internetworkingに関する安全上の配慮を脅威から信頼に分類できます。 Content Internetworkingと共に利用された信頼モデルは主にORIGINと、REQUEST-ROUTING INTERNETWORKING SYSTEMと、DISTRIBUTION INTERNETWORKING SYSTEMと、ACCOUNTING INTERNETWORING SYSTEMと、SURROGATESの間の遷移的な信頼で叙述されます。 Content Internetworkingシステムの中のネットワーク要素は、「インサイダー」であると考えられて、したがって、信じられます。
5.1. Threats to Content Internetworking
5.1. 満足しているインターネットワーキングへの脅威
The following sections document key threats to CLIENTs, PUBLISHERs, and CNs. The threats are classified according to the party that they most directly harm, but, of course, a threat to any party is ultimately a threat to all. (For example, having a credit card number stolen may most directly affect a CLIENT; however, the resulting dissatisfaction and publicity will almost certainly cause some harm to the PUBLISHER and CN, even if the harm is only to those organizations' reputations.)
以下のセクションはCLIENTs、PUBLISHERs、およびCNsへの主要な脅威を記録します。 もちろん、それらが最も直接危害を加えるパーティーによると、脅威は分類されますが、結局、どんなパーティーへの脅威もすべてへの脅威です。 (例えば、クレジットカード番号が盗まれると、CLIENTは最も直接影響されるかもしれません; しかしながら、結果として起こる不満と宣伝はほぼ確実にPUBLISHERとCNに何らかの害を引き起こすでしょう、それらの組織の評判だけに害があっても。)
5.1.1. Threats to the CLIENT
5.1.1. クライアントへの脅威
5.1.1.1. Defeat of CLIENT's Security Settings
5.1.1.1. クライアントのセキュリティー設定の敗北
Because the SURROGATE's location may differ from that of the ORIGIN, the use of a SURROGATE may inadvertently or maliciously defeat any location-based security settings employed by the CLIENT. And since the SURROGATE's location is generally transparent to the CLIENT, the CLIENT may be unaware that its protections are no longer in force. For example, a CN may relocate CONTENT from a Internet Explorer user's "Internet Web Content Zone" to that user's "Local Intranet Web Content Zone". If the relocation is visible to the Internet Explorer browser but otherwise invisible to the user, the browser may be employing less stringent security protections than the user is expecting for that CONTENT. (Note that this threat differs, at least in degree, from the substitution of security parameters threat below, as Web Content Zones can control whether or not, for example, the browser executes unsigned active content.)
SURROGATEの位置がORIGINのものと異なるかもしれないので、SURROGATEの使用はうっかりか陰湿にCLIENTによって使われたどんな位置のベースのセキュリティー設定も破るかもしれません。 そして、SURROGATEの位置が一般にCLIENTに透明であるので、CLIENTは保護がもう有効でないことを気づかないかもしれません。 例えば、CNはCONTENTをインターネット・エクスプローラーユーザの「インターネットウェブ内容ゾーン」からそのユーザの「ウェブのローカルのイントラネット内容ゾーン」まで移動させるかもしれません。 再配置がインターネット・エクスプローラーブラウザにおいて目に見えますが、ユーザにとって、そうでなければ、目に見えないなら、ブラウザはユーザがそのCONTENTのために予想しているより少ない厳しい機密保持を使っているかもしれません。 (以下でのセキュリティパラメタの脅威の代替からこの脅威が少なくとも度合いにおいて異なることに注意してください、ウェブContent Zonesが、例えば、ブラウザが未署名のアクティブな内容を実行するかどうかを制御できるとき。)
5.1.1.2. Delivery of Bad Accounting Information
5.1.1.2. 悪い課金情報の配送
In the case of CONTENT with value, CLIENTs may be inappropriately charged for viewing content that they did not successfully access. Conversely, some PUBLISHERs may reward CLIENTs for viewing certain
値があるCONTENTの場合では、彼らが首尾よくなくアクセサリーをした内容を見ながら、不適当にCLIENTsに課金するかもしれません。 逆に、いくつかのPUBLISHERsが見るためにCLIENTsの確かな状態で報酬を与えるかもしれません。
Rzewski, et al. Informational [Page 15] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [15ページ]情報のRFC3570CDIシナリオ2003年7月
CONTENT (e.g., programs that "pay" users to surf the Web). Should a CN fail to deliver appropriate accounting information, the CLIENT may not receive appropriate credit for viewing the required CONTENT.
CONTENT(例えば、ユーザがウェブをサーフィンするのを「支払う」プログラム)。 適切な課金情報、CLIENTを提供するCNやり損ないが受信されないかもしれないなら、必要なCONTENTを見るためにクレジットを当ててください。
5.1.1.3. Delivery of Bad CONTENT
5.1.1.3. 悪い内容の配送
A CN that does not deliver the appropriate CONTENT may provide the user misleading information (either maliciously or inadvertently). This threat can be manifested as a failure of either the DISTRIBUTION SYSTEM (inappropriate content delivered to appropriate SURROGATEs) or REQUEST-ROUTING SYSTEM (request routing to inappropriate SURROGATEs, even though they may have appropriate CONTENT), or both. A REQUEST- ROUTING SYSTEM may also fail by forwarding the CLIENT request when no forwarding is appropriate, or by failing to forward the CLIENT request when forwarding is appropriate.
適切なCONTENTを提供しないCNはユーザ偽情報(陰湿かうっかり)を提供するかもしれません。 DISTRIBUTION SYSTEM(SURROGATEsを当てるために提供された不適当な内容)かREQUEST-ROUTING SYSTEM(不適当なSURROGATEsにルーティングを要求してください、彼らは適切なCONTENTを持っているかもしれませんが)か両方のどちらかの失敗としてこの脅威を表すことができます。 また、REQUEST ROUTING SYSTEMは、推進が適切であるときに進めないのが適切でありCLIENTが要求する推進、またはCLIENT要求を転送しないことによって、失敗するかもしれません。
5.1.1.4. Denial of Service
5.1.1.4. サービス妨害
A CN that does not forward the CLIENT appropriately may deny the CLIENT access to CONTENT.
適切にCLIENTを進めないCNはCONTENTへのCLIENTアクセスを拒絶するかもしれません。
5.1.1.5. Exposure of Private Information
5.1.1.5. 個人情報の暴露
CNs may inadvertently or maliciously expose private information (passwords, buying patterns, page views, credit card numbers) as it transmits from SURROGATEs to ORIGINs and/or PUBLISHERs.
CNsはSURROGATEsからORIGINs、そして/または、PUBLISHERsまで伝わるようにうっかりか陰湿に、個人情報(パスワード、購入は型に基づいて作ります、ページ・ビュー、クレジットカード番号)を暴露するかもしれません。
5.1.1.6. Substitution of Security Parameters
5.1.1.6. セキュリティパラメタの代替
If a SURROGATE does not duplicate completely the security facilities of the ORIGIN (e.g., encryption algorithms, key lengths, certificate authorities) CONTENT delivered through the SURROGATE may be less secure than the CLIENT expects.
SURROGATEが完全にORIGINのセキュリティ施設をコピーするというわけではないなら(例えば、暗号化アルゴリズム(キー長)は当局を証明します)、SURROGATEを通して提供されたCONTENTはCLIENTが予想するほど安全でないかもしれません。
5.1.1.7. Substitution of Security Policies
5.1.1.7. 安全保障政策の代替
If a SURROGATE does not employ the same security policies and procedures as the ORIGIN, the CLIENT's private information may be treated with less care than the CLIENT expects. For example, the operator of a SURROGATE may not have as rigorous protection for the CLIENT's password as does the operator of the ORIGIN server. This threat may also manifest itself if the legal jurisdiction of the SURROGATE differs from that of the ORIGIN, should, for example, legal differences between the jurisdictions require or permit different treatment of the CLIENT's private information.
SURROGATEがORIGINとして同じ安全保障政策と手順を使わないなら、CLIENTの個人情報はCLIENTが予想するより少ない注意で扱われるかもしれません。 例えば、SURROGATEのオペレータには、CLIENTのパスワードのためのORIGINサーバのオペレータと同じくらい厳しい保護がないかもしれません。また、SURROGATEの法的な管轄がORIGINのものと異なっているなら、この脅威は現れるかもしれません、管内の例えば、法的な違いがCLIENTの個人情報の異なった処理を必要である、または可能にするなら。
Rzewski, et al. Informational [Page 16] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [16ページ]情報のRFC3570CDIシナリオ2003年7月
5.1.2. Threats to the PUBLISHER
5.1.2. 出版社への脅威
5.1.2.1. Delivery of Bad Accounting Information
5.1.2.1. 悪い課金情報の配送
If a CN does not deliver accurate accounting information, the PUBLISHER may be unable to charge CLIENTs for accessing CONTENT or it may reward CLIENTs inappropriately. Inaccurate accounting information may also cause a PUBLISHER to pay for services (e.g., content distribution) that were not actually rendered. Invalid accounting information may also effect PUBLISHERs indirectly by, for example, undercounting the number of site visitors (and, thus, reducing the PUBLISHER's advertising revenue).
CNが正確な課金情報を提供しないなら、PUBLISHERがCONTENTにアクセスするためにCLIENTsを請求できないかもしれませんか、またはそれは不適当にCLIENTsの報酬を与えるかもしれません。 また、不正確な課金情報で、PUBLISHERは実際にレンダリングされなかったサービス(例えば、満足している分配)の代価を払うかもしれません。 また、間接的に例えば、サイト訪問者の数をundercountingすることによって、無効の課金情報はPUBLISHERsに作用するかもしれません(その結果、PUBLISHERの広告収入を下げて)。
5.1.2.2. Denial of Service
5.1.2.2. サービス妨害
A CN that does not distribute CONTENT appropriately may deny CLIENTs access to CONTENT.
適切にCONTENTを分配しないCNはCONTENTへのアクセスをCLIENTsに拒絶するかもしれません。
5.1.2.3. Substitution of Security Parameters
5.1.2.3. セキュリティパラメタの代替
If a SURROGATE does not duplicate completely the security services of the ORIGIN (e.g., encryption algorithms, key lengths, certificate authorities, client authentication) CONTENT stored on the SURROGATE may be less secure than the PUBLISHER prefers.
SURROGATEが完全にORIGINのセキュリティー・サービスをコピーするというわけではないなら(例えば、暗号化アルゴリズム(キー長)は当局を証明します、クライアント認証)、SURROGATEに保存されたCONTENTはPUBLISHERが好むほど安全でないかもしれません。
5.1.2.4. Substitution of Security Policies
5.1.2.4. 安全保障政策の代替
If a SURROGATE does not employ the same security policies and procedures as the ORIGIN, the CONTENT may be treated with less care than the PUBLISHER expects. This threat may also manifest itself if the legal jurisdiction of the SURROGATE differs from that of the ORIGIN, should, for example, legal differences between the jurisdictions require or permit different treatment of the CONTENT.
SURROGATEがORIGINとして同じ安全保障政策と手順を使わないなら、CONTENTはPUBLISHERが予想するより少ない注意で扱われるかもしれません。 また、SURROGATEの法的な管轄がORIGINのものと異なっているなら、この脅威は現れるかもしれません、管内の例えば、法的な違いがCONTENTの異なった処理を必要である、または可能にするなら。
5.1.3. Threats to a CN
5.1.3. CNへの脅威
5.1.3.1. Bad Accounting Information
5.1.3.1. 悪い課金情報
If a CN is unable to collect or receive accurate accounting information, it may be unable to collect compensation for its services from PUBLISHERs.
CNが正確な課金情報を集めるか、または受け取ることができないなら、PUBLISHERsからサービスの補償を集めることができないかもしれません。
Rzewski, et al. Informational [Page 17] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [17ページ]情報のRFC3570CDIシナリオ2003年7月
5.1.3.2. Denial of Service
5.1.3.2. サービス妨害
Misuse of a CN may make that CN's facilities unavailable, or available only at reduced functionality, to legitimate customers or the CN provider itself. Denial of service attacks can be targeted at a CN's ACCOUNTING SYSTEM, DISTRIBUTION SYSTEM, or REQUEST-ROUTING SYSTEM.
CNの誤用はそれをCNの入手できないか、単に減少している機能性で利用可能な施設にするかもしれません、正統の顧客かCNプロバイダー自体に。 サービス不能攻撃はCNのACCOUNTING SYSTEM、DISTRIBUTION SYSTEM、またはREQUEST-ROUTING SYSTEMをターゲットにすることができます。
5.1.3.3. Transitive Threats
5.1.3.3. 遷移的な脅威
To the extent that a CN acts as either a CLIENT or a PUBLISHER (such as, for example, in transitive implementations) such a CN may be exposed to any or all of the threats described above for both roles.
CNがCLIENTかPUBLISHER(例えば遷移的な実装などの)を活動させるという範囲に、そのようなCNは両方の役割のために上で説明された脅威のいずれかすべてにさらされるかもしれません。
6. Acknowledgements
6. 承認
The authors acknowledge the contributions and comments of Fred Douglis (AT&T), Raj Nair (Cisco), Gary Tomlinson (CacheFlow), John Scharber (CacheFlow), Nalin Mistry (Nortel), Steve Rudkin (BT), Christian Hoertnagl (IBM), Christian Langkamp (Oxford University), and Don Estberg (Activate).
作者はフレッドDouglis(AT&T)、Rajナイア(シスコ)、ゲーリー・トムリンスン(CacheFlow)、ジョンScharber(CacheFlow)、Nalinミストリ(ノーテル)、スティーブ・ラドキン(BT)、クリスチャンのHoertnagl(IBM)、クリスチャンのLangkamp(オックスフォード大学)、およびドンEstberg(動かす)の貢献とコメントを承諾します。
7. References
7. 参照
[1] Day, M., Cain, B., Tomlinson, G. and P. Rzewski, "A Model for
Content Internetworking (CDI)", RFC 3466, February 2003.
[1] 日、M.とカインとB.とトムリンスンとG.とP.ルゼフスキー、「満足しているインターネットワーキング(CDI)のためのモデル」、RFC3466、2003年2月。
[2] Biliris, A., Cranor, C., Douglis, F., Rabinovich, M., Sibal, S.,
Spatscheck, O. and W. Sturm, "CDN Brokering", Proceedings of the
6th International Workshop on Web Caching and Content
Distribution, Boston, MA, June 2001.
ウェブのキャッシュしていて満足している分配(ボストン(MA)2001年6月)の[2]BilirisとA.とCranorとC.とDouglisとF.とラビノビチとM.とSibalとS.とSpatscheckとO.とW.スターム、「CDN仲介」、第6国際ワークショップの議事。
Rzewski, et al. Informational [Page 18] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [18ページ]情報のRFC3570CDIシナリオ2003年7月
8. Authors' Addresses
8. 作者のアドレス
Mark S. Day Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 US
シスコシステムズ1414年のS.日マサチューセッツ通りBoxborough、MA 01719が米国であるとマークしてください。
Phone: +1 978 936 1089 EMail: mday@alum.mit.edu
以下に電話をしてください。 +1 1089年の978 936メール: mday@alum.mit.edu
Don Gilletti 21 22nd Ave. San Mateo, CA 94403 US
Gilletti21第22Aveを身につけてください。 サン・マテオ、カリフォルニア94403米国
Phone +1 408 569 6813 EMail: dgilletti@yahoo.com
+1に、6813がメールする408 569に電話をしてください: dgilletti@yahoo.com
Phil Rzewski 30 Jennifer Place San Francisco, CA 94107 US
フィルルゼフスキー30ジェニファーPlaceカリフォルニア94107サンフランシスコ(米国)
Phone: +1 650 303 3790 EMail: philrz@yahoo.com
以下に電話をしてください。 +1 3790年の650 303メール: philrz@yahoo.com
Rzewski, et al. Informational [Page 19] RFC 3570 CDI Scenarios July 2003
ルゼフスキー、他 [19ページ]情報のRFC3570CDIシナリオ2003年7月
9. Full Copyright Statement
9. 完全な著作権宣言文
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright(C)インターネット協会(2003)。 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 assignees.
上に承諾された限られた許容は、永久であり、そのインターネット協会、後継者または指定代理人によって取り消されないでしょう。
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機能のための基金は現在、インターネット協会によって提供されます。
Rzewski, et al. Informational [Page 20]
ルゼフスキー、他 情報[20ページ]
一覧
スポンサーリンク
