[要約] RFC 6983は、HTTP適応ストリーミング対応のコンテンツ配信ネットワーク（CDN）の相互接続に関するモデルを提供しています。このRFCの目的は、異なるCDN間でのコンテンツの効率的な配信を実現するためのガイドラインを提供することです。
Independent Submission R. van Brandenburg
Request for Comments: 6983 O. van Deventer
Category: Informational TNO
ISSN: 2070-1721 F. Le Faucheur
K. Leung
Cisco Systems
July 2013
Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI)
HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection（CDNI）のモデル
Abstract
概要
This document presents thoughts on the potential impact of supporting HTTP Adaptive Streaming (HAS) technologies in Content Distribution Network Interconnection (CDNI) scenarios. The intent is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. This document has been used as input information during the CDNI working group process for making a decision regarding support for HAS.
このドキュメントでは、コンテンツ配信ネットワーク相互接続（CDNI）シナリオでHTTPアダプティブストリーミング（HAS）テクノロジをサポートすることの潜在的な影響についての考えを示します。 CDNI-HAS問題空間の著者の分析を提示し、CDNIのコンテキストでHASを処理する方法について著者（および非公式の議論中に他の人）が提示したさまざまなオプションについて議論することを意図しています。このドキュメントは、HASのサポートに関する決定を行うためのCDNIワーキンググループプロセス中に入力情報として使用されました。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6983.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6983で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................4
1.1. Terminology ................................................5
2. HTTP Adaptive Streaming Aspects Relevant to CDNI ................6
2.1. Segmentation versus Fragmentation ..........................6
2.2. Addressing Chunks ..........................................7
2.2.1. Relative URLs .......................................8
2.2.2. Absolute URLs with Redirection ......................9
2.2.3. Absolute URLs without Redirection ..................10
2.3. Live Content versus VoD Content ...........................11
2.4. Stream Splicing ...........................................12
3. Possible HAS Optimizations .....................................12
3.1. File Management and Content Collections ...................13
3.1.1. General Remarks ....................................13
3.1.2. Candidate Approaches ...............................13
3.1.2.1. Option 1.1: Do Nothing ....................13
3.1.2.2. Option 1.2: Allow Single-File
Storage of Fragmented Content .............14
3.1.2.3. Option 1.3: Access Correlation Hint .......14
3.1.3. Recommendations ....................................15
3.2. Content Acquisition of Content Collections ................15
3.2.1. General Remarks ....................................15
3.2.2. Candidate Approaches ...............................16
3.2.2.1. Option 2.1: No HAS Awareness ..............16
3.2.2.2. Option 2.2: Allow Single-File
Acquisition of Fragmented Content .........17
3.2.3. Recommendations ....................................17
3.3. Request Routing of HAS Content ............................17
3.3.1. General Remarks ....................................17
3.3.2. Candidate Approaches ...............................18
3.3.2.1. Option 3.1: No HAS Awareness ..............18
3.3.2.2. Option 3.2: Manifest File Rewriting
by uCDN ...................................20
3.3.2.3. Option 3.3: Two-Step Manifest File
Rewriting .................................21
3.3.3. Recommendations ....................................22
3.4. Logging ...................................................23
3.4.1. General Remarks ....................................23
3.4.2. Candidate Approaches ...............................24
3.4.2.1. Option 4.1: Do Nothing ....................24
3.4.2.2. Option 4.2: CDNI Metadata Content
Collection ID .............................26
3.4.2.3. Option 4.3: CDNI Logging Interface
Compression ...............................28
3.4.2.4. Option 4.4: Full HAS
Awareness/Per-Session Logs ................29
3.4.3. Recommendations ....................................30
3.5. URL Signing ...............................................32
3.5.1. HAS Implications ...................................32
3.5.2. CDNI Considerations ................................33
3.5.3. Option 5.1: Do Nothing .............................34
3.5.4. Option 5.2: Flexible URL Signing by CSP ............34
3.5.5. Option 5.3: Flexible URL Signing by uCDN ...........37
3.5.6. Option 5.4: Authorization Group ID and HTTP
Cookie .............................................37
3.5.7. Option 5.5: HAS Awareness with HTTP Cookie in CDN ..38
3.5.8. Option 5.6: HAS Awareness with Manifest
File in CDN ........................................40
3.5.9. Recommendations ....................................41
3.6. Content Purge .............................................41
3.6.1. Option 6.1: No HAS Awareness .......................42
3.6.2. Option 6.2: Purge Identifiers ......................42
3.6.3. Recommendations ....................................43
3.7. Other Issues ..............................................43
4. Security Considerations ........................................43
5. Acknowledgements ...............................................44
6. References .....................................................44
6.1. Normative References ......................................44
6.2. Informative References ....................................44
[RFC6707] defines the problem space for Content Distribution Network Interconnection (CDNI) and the associated CDNI interfaces. This includes support, through interconnected Content Delivery Networks (CDNs), of content delivery to End Users using HTTP progressive download and HTTP Adaptive Streaming (HAS).
[RFC6707]は、コンテンツ配布ネットワーク相互接続（CDNI）および関連するCDNIインターフェースの問題空間を定義しています。これには、相互接続されたコンテンツ配信ネットワーク（CDN）による、HTTPプログレッシブダウンロードとHTTPアダプティブストリーミング（HAS）を使用したエンドユーザーへのコンテンツ配信のサポートが含まれます。
HTTP Adaptive Streaming is an umbrella term for various HTTP-based streaming technologies that allow a client to adaptively switch between multiple bitrates, depending on current network conditions. A defining aspect of HAS is that, since it is based on HTTP, it is a pull-based mechanism, with a client actively requesting content segments instead of the content being pushed to the client by a server. Due to this pull-based nature, media servers delivering content using HAS often show different characteristics when compared with media servers delivering content using traditional streaming methods such as the Real-time Transport Protocol / Real Time Streaming Protocol (RTP/RTSP), the Real Time Messaging Protocol (RTMP), and the Multimedia Messaging Service (MMS).
HTTPアダプティブストリーミングは、クライアントが現在のネットワーク状態に応じて複数のビットレートを適応的に切り替えることを可能にする、さまざまなHTTPベースのストリーミングテクノロジーの包括的な用語です。 HASの特徴的な側面は、HTTPに基づいているため、プルベースのメカニズムであり、サーバーからクライアントにコンテンツがプッシュされるのではなく、クライアントがコンテンツセグメントをアクティブに要求することです。このプルベースの性質により、HASを使用してコンテンツを配信するメディアサーバーは、リアルタイムトランスポートプロトコル/リアルタイムストリーミングプロトコル（RTP / RTSP）などの従来のストリーミング方法を使用してコンテンツを配信するメディアサーバーと比較すると、多くの場合異なる特性を示します。タイムメッセージングプロトコル（RTMP）、およびマルチメディアメッセージングサービス（MMS）。
This document presents a discussion of the impact of the HAS operation on the CDNI interfaces, and what HAS-specific optimizations may be required or may be desirable. The scope of this document is to present the authors' analysis of the CDNI-HAS problem space and discuss different options put forward by the authors (and by others during informal discussions) on how to deal with HAS in the context of CDNI. The document concludes by presenting the authors' recommendations on how the CDNI WG should deal with HAS in its initial charter, with a focus on 'making it work' instead of including 'nice-to-have' optimizations that might delay the development of the CDNI WG deliverables identified in its initial charter.
このドキュメントでは、CDNIインターフェイスでのHAS操作の影響と、HAS固有の最適化が必要な場合と望ましい場合があることについて説明します。このドキュメントの範囲は、CDNI-HAS問題空間の著者の分析を示し、CDNIのコンテキストでHASを処理する方法について著者（および非公式の議論中に他の人）が提示したさまざまなオプションについて議論することです。このドキュメントは、CDNI WGがHASをどのように扱うべきかについての著者の推奨事項を最初の憲章で提示することで締めくくり、開発を遅らせる可能性のある「すてきな」最適化を含めるのではなく、「機能させる」ことに焦点を当てています。最初の憲章で特定されたCDNI WGの成果物。
It should be noted that the document is not a WG document but has been used as input during the WG process for making its decision regarding support for HAS. We expect the analysis presented in the document to be useful in the future if and when the WG recharters and wants to reassess the level of HAS optimizations to be supported in CDNI scenarios.
このドキュメントはWGドキュメントではなく、HASのサポートに関する決定を行うためのWGプロセス中に入力として使用されたことに注意してください。 WGが再チャーターし、CDNIシナリオでサポートされるHAS最適化のレベルを再評価したい場合は、このドキュメントに示されている分析が将来役立つことを期待しています。
This document uses the terminology defined in [RFC6707] and [CDNI-FRAMEWORK].
このドキュメントでは、[RFC6707]と[CDNI-FRAMEWORK]で定義されている用語を使用しています。
For convenience, the definitions of HAS-related terms are restated here:
便宜上、HAS関連の用語の定義をここに再記載します。
Content Item: A uniquely addressable content element in a CDN. A content item is defined by the fact that it has its own Content Metadata associated with it. An example of a content item is a video file/stream, an audio file/stream, or an image file.
コンテンツアイテム：CDNで一意にアドレス指定可能なコンテンツ要素。コンテンツアイテムは、独自のコンテンツメタデータが関連付けられているという事実によって定義されます。コンテンツアイテムの例は、ビデオファイル/ストリーム、オーディオファイル/ストリーム、または画像ファイルです。
Chunk: A fixed-length element that is the result of a segmentation or fragmentation operation and that is independently addressable.
チャンク：セグメンテーションまたはフラグメンテーション操作の結果であり、個別にアドレス可能な固定長の要素。
Fragment: A specific form of chunk (see Section 2.1). A fragment is stored as part of a larger file that includes all chunks that are part of the chunk collection.
フラグメント：特定の形式のチャンク（セクション2.1を参照）。フラグメントは、チャンクコレクションの一部であるすべてのチャンクを含むより大きなファイルの一部として格納されます。
Segment: A specific form of chunk (see Section 2.1). A segment is stored as a single file from a file-system perspective.
セグメント：特定の形式のチャンク（セクション2.1を参照）。セグメントは、ファイルシステムの観点から単一のファイルとして格納されます。
Original Content: Non-chunked content that is the basis for a segmentation or fragmentation operation. Based on Original Content, multiple alternative representations (using different encoding methods, supporting different resolutions, and/or targeting different bitrates) may be derived, each of which may be fragmented or segmented.
元のコンテンツ：分割または断片化操作の基礎となるチャンクされていないコンテンツ。元のコンテンツに基づいて、複数の代替表現（さまざまなエンコーディング方法を使用し、さまざまな解像度をサポートし、および/またはさまざまなビットレートをターゲットにする）が導出され、それぞれが断片化またはセグメント化されます。
Chunk Collection: The set of all chunks that are the result of a single segmentation or fragmentation operation being performed on a single representation of the Original Content. A chunk collection is described in a Manifest File.
チャンクコレクション：元のコンテンツの単一の表現に対して実行された単一のセグメンテーションまたはフラグメント化操作の結果であるすべてのチャンクのセット。チャンクコレクションは、マニフェストファイルに記述されています。
Content Collection: The set of all chunk collections that are derived from the same Original Content. A content collection may consist of multiple chunk collections, each corresponding to a single representation of the Original Content. A content collection may be described by one or more Manifest Files.
コンテンツコレクション：同じオリジナルコンテンツから派生したすべてのチャンクコレクションのセット。コンテンツコレクションは、それぞれがオリジナルコンテンツの単一の表現に対応する複数のチャンクコレクションで構成されます。コンテンツコレクションは、1つまたは複数のマニフェストファイルで記述できます。
Manifest File: A Manifest File, also referred to as a Media Presentation Description (MPD) file, is a file that lists the way the content has been chunked (possibly for multiple encodings), as well as where the various chunks are located (in the case of segments) or how they can be addressed (in the case of fragments).
マニフェストファイル：マニフェストファイルは、メディアプレゼンテーション記述（MPD）ファイルとも呼ばれ、コンテンツがチャンクされた方法（おそらく複数のエンコーディング）と、さまざまなチャンクが配置されている場所（セグメントの場合）またはそれらに対処する方法（フラグメントの場合）。
In the last couple of years, a wide variety of HAS-like protocols have emerged. Among them are proprietary solutions such as Apple's HTTP Live Streaming (HLS), Microsoft's HTTP Smooth Streaming (HSS), and Adobe's HTTP Dynamic Streaming (HDS), as well as various standardized solutions such as 3GPP Adaptive HTTP Streaming (AHS) and MPEG Dynamic Adaptive Streaming over HTTP (DASH). While all of these technologies share a common set of features, each has its own defining elements. This section looks at some of the common characteristics and some of the differences between these technologies and how those might be relevant to CDNI. In particular, Section 2.1 describes the various methods to store HAS content, and Section 2.2 lists three methods that are used to address HAS content in a CDN. After these generic HAS aspects are discussed, two special situations that need to be taken into account when discussing HAS are addressed: Section 2.3 discusses the differences between live content and Video on Demand (VoD) content, while Section 2.4 discusses the scenario where multiple streams are combined in a single Manifest File (e.g., for ad insertion purposes).
ここ数年で、さまざまなHASのようなプロトコルが登場しました。その中には、AppleのHTTPライブストリーミング（HLS）、MicrosoftのHTTP Smooth Streaming（HSS）、AdobeのHTTP Dynamic Streaming（HDS）などの独自のソリューション、および3GPP Adaptive HTTP Streaming（AHS）やMPEG Dynamicなどのさまざまな標準化されたソリューションがあります。 HTTP経由のアダプティブストリーミング（DASH）。これらのテクノロジーはすべて共通の機能セットを共有していますが、それぞれに独自の定義要素があります。このセクションでは、いくつかの一般的な特性と、これらのテクノロジー間のいくつかの違いと、それらがCDNIにどのように関連するかについて説明します。特に、2.1節ではHASコンテンツを保存するさまざまな方法について説明し、2.2節ではCDNのHASコンテンツに対処するために使用される3つの方法を示します。これらの一般的なHASの側面について説明した後、HASについて説明する際に考慮が必要な2つの特別な状況について説明します。セクション2.3ではライブコンテンツとビデオオンデマンド（VoD）コンテンツの違いについて説明し、セクション2.4では複数のストリームを使用するシナリオについて説明します。単一のマニフェストファイルに結合されます（広告挿入の目的など）。
All HAS implementations are based on a concept referred to as "chunking": the concept of having a server split content up in numerous fixed-duration chunks that are independently decodable. By sequentially requesting and receiving chunks, a client can recreate and play out the content. An advantage of this mechanism is that it allows a client to seamlessly switch between different encodings of the same Original Content at chunk boundaries. Before requesting a particular chunk, a client can choose between multiple alternative encodings of the same chunk, irrespective of the encoding of the chunks it has requested earlier.
すべてのHAS実装は、「チャンキング」と呼ばれる概念に基づいています。サーバーが、独立してデコード可能な多数の固定期間のチャンクにコンテンツを分割するという概念です。チャンクを順次要求して受信することにより、クライアントはコンテンツを再作成して再生できます。このメカニズムの利点は、クライアントがチャンク境界で同じオリジナルコンテンツの異なるエンコーディング間をシームレスに切り替えることができることです。特定のチャンクを要求する前に、クライアントは、以前に要求したチャンクのエンコーディングに関係なく、同じチャンクの複数の代替エンコーディングから選択できます。
While every HAS implementation uses some form of chunking, not all implementations store the resulting chunks in the same way. In general, there are two distinct methods of performing chunking and storing the results: segmentation and fragmentation.
すべてのHAS実装は何らかの形式のチャンクを使用しますが、すべての実装が結果のチャンクを同じ方法で格納するわけではありません。一般に、チャンクを実行して結果を保存するには、セグメンテーションとフラグメント化という2つの異なる方法があります。
- With segmentation -- which is, for example, mandatory in all versions of Apple's HLS prior to version 7 -- the chunks, in this case also referred to as segments, are stored completely independently from each other, with each segment being stored as a separate file from a file-system perspective. This means that each segment has its own unique URL with which it can be retrieved.
- セグメンテーション（たとえば、バージョン7より前のすべてのバージョンのApple HLSでは必須）では、チャンク（この場合はセグメントとも呼ばれます）は互いに完全に独立して格納され、各セグメントはファイルシステムの観点からファイルを分離します。つまり、各セグメントには、取得できる独自のURLがあります。
- With fragmentation (or virtual segmentation) -- which is, for example, used in Microsoft's HTTP Smooth Streaming -- all chunks, or fragments, belonging to the same chunk collection are stored together as part of a single file. While there are a number of container formats that allow for storing this type of chunked content, fragmented MP4 is most commonly used. With fragmentation, a specific chunk is addressable by suffixing, to the common file URL, an identifier uniquely identifying the chunk that one is interested in, either by timestamp, by byte range, or in some other way.
- たとえばMicrosoftのHTTP Smooth Streamingで使用される断片化（または仮想セグメンテーション）では、同じチャンクコレクションに属するすべてのチャンクまたはフラグメントが、単一のファイルの一部として一緒に格納されます。このタイプのチャンクされたコンテンツを格納できるコンテナ形式は多数ありますが、フラグメント化されたMP4が最も一般的に使用されます。フラグメンテーションを使用すると、特定のチャンクは、タイムスタンプ、バイト範囲、またはその他の方法で、関心のあるチャンクを一意に識別する識別子を共通ファイルURLに接尾辞を付けることでアドレス指定できます。
While one can argue about the merits of each of these two different methods of handling chunks, both have their advantages and drawbacks in a CDN environment. For example, fragmentation is often regarded as a method that introduces less overhead, from both a storage and processing perspective. Segmentation, on the other hand, is regarded as being more flexible and easier to cache. In practice, current HAS implementations increasingly support both methods.
チャンクを処理するこれらの2つの異なる方法のそれぞれの利点について議論することはできますが、どちらもCDN環境には長所と短所があります。たとえば、断片化は、ストレージと処理の両方の観点から、オーバーヘッドが少ない方法と見なされることがよくあります。一方、セグメンテーションは、より柔軟でキャッシュしやすいと見なされています。実際には、現在のHAS実装は両方の方法をますますサポートしています。
In order for a client to request chunks, in the form of either segments or fragments, it needs to know how the content has been chunked and where to find the chunks. For this purpose, most HAS protocols use a concept that is often referred to as a Manifest File (also known as a Media Presentation Description, or MPD), i.e., a file that lists the way the content has been chunked and where the various chunks are located (in the case of segments) or how they can be addressed (in the case of fragments). A Manifest File or set of Manifest Files may also identify the different representations, and thus chunk collections, available for the content.
クライアントがセグメントまたはフラグメントのいずれかの形式でチャンクを要求するには、コンテンツがどのようにチャンクされているか、およびチャンクを見つける場所を知る必要があります。この目的のために、ほとんどのHASプロトコルは、マニフェストファイル（Media Presentation Description、またはMPDとも呼ばれます）と呼ばれる概念、つまりコンテンツがチャンクされた方法とさまざまなチャンクの場所をリストするファイルを使用します配置されているか（セグメントの場合）、またはそれらにどのように対処できるか（フラグメントの場合）。マニフェストファイルまたはマニフェストファイルのセットは、コンテンツで使用できるさまざまな表現、つまりチャンクコレクションも識別します。
In general, a HAS client will first request and receive a Manifest File, and then, after parsing the information in the Manifest File, proceed with sequentially requesting the chunks listed in the Manifest File. Each HAS implementation has its own Manifest File format, and even within a particular format there are different methods available to specify the location of a chunk.
一般に、HASクライアントは最初にマニフェストファイルを要求して受信し、次にマニフェストファイルの情報を解析した後、マニフェストファイルにリストされているチャンクを順次要求します。各HAS実装には独自のマニフェストファイル形式があり、特定の形式内でも、チャンクの場所を指定するために使用できるさまざまな方法があります。
Of course, managing the location of files is a core aspect of every CDN, and each CDN will have its own method of doing so. Some CDNs may be purely cache-based, with no higher-level knowledge of where each file resides at each instant in time. Other CDNs may have dedicated management nodes that, at each instant in time, do know at which servers each file resides. The CDNI interfaces designed by the CDNI WG will probably need to be agnostic to these kinds of CDN-internal architecture decisions. In the case of HAS, there is a strict relationship between the location of the content in the CDN (in this case chunks) and the content itself (the locations specified in the Manifest File). It is therefore useful to have an understanding of the different methods in use in CDNs today for specifying chunk locations in Manifest Files. The different methods for doing so are described in Sections 2.2.1 to 2.2.3.
もちろん、ファイルの場所を管理することはすべてのCDNの中核的な側面であり、各CDNには独自の方法があります。一部のCDNは純粋にキャッシュベースであり、各ファイルがいつどこに存在するかについての高レベルの知識がありません。他のCDNには、各ファイルが存在するサーバーを常に認識する専用の管理ノードがある場合があります。 CDNI WGによって設計されたCDNIインターフェースは、おそらくこれらの種類のCDN内部アーキテクチャの決定にとらわれない必要があるでしょう。 HASの場合、CDN内のコンテンツの場所（この場合はチャンク）とコンテンツ自体（マニフェストファイルで指定された場所）の間には厳密な関係があります。したがって、マニフェストファイルでチャンクの場所を指定するために、現在CDNで使用されているさまざまな方法を理解しておくと役立ちます。そのためのさまざまな方法については、セクション2.2.1から2.2.3で説明します。
Although these sections are especially relevant for segmented content due to its inherent distributed nature, the discussed methods are also applicable to fragmented content. Furthermore, it should be noted that the methods detailed below for specifying locations of content items in Manifest Files do not relate only to temporally segmented content (e.g., segments and fragments) but are also relevant in situations where content is made available in multiple representations (e.g., in different qualities, encoding methods, resolutions, and/or bitrates). In this case, the content consists of multiple chunk collections, which may be described by either a single Manifest File or multiple interrelated Manifest Files. In the latter case, there may be a high-level Manifest File describing the various available bitrates, with URLs pointing to separate Manifest Files describing the details of each specific bitrate. For specifying the locations of the other Manifest Files, the same methods that are used for specifying chunk locations also apply.
これらのセクションは、固有の分散性により、セグメント化されたコンテンツに特に関連していますが、説明されている方法は断片化されたコンテンツにも適用できます。さらに、マニフェストファイル内のコンテンツアイテムの場所を指定するための以下で詳細に説明する方法は、時間的にセグメント化されたコンテンツ（セグメントやフラグメントなど）だけに関連するのではなく、コンテンツが複数の表現で利用可能になる状況にも関連することに注意してください（たとえば、さまざまな品質、エンコード方法、解像度、ビットレートなど）。この場合、コンテンツは複数のチャンクコレクションで構成され、単一のマニフェストファイルまたは相互に関連する複数のマニフェストファイルのいずれかで記述されます。後者の場合、使用可能なさまざまなビットレートを説明する高レベルのマニフェストファイルがあり、URLはそれぞれの特定のビットレートの詳細を説明する個別のマニフェストファイルを指しています。他のマニフェストファイルの場所を指定するには、チャンクの場所を指定するために使用されるのと同じ方法が適用されます。
One final note relates to the delivery of the Manifest Files themselves. While in most situations the delivery of both the Manifest File and the chunks is handled by the CDN, there are scenarios imaginable in which the Manifest File is delivered by, for example, the Content Service Provider (CSP), and the Manifest File is therefore not visible to the CDN.
最後の注意点の1つは、マニフェストファイル自体の配信に関するものです。ほとんどの状況では、マニフェストファイルとチャンクの両方の配信がCDNによって処理されますが、マニフェストファイルがコンテンツサービスプロバイダー（CSP）などによって配信され、マニフェストファイルが配信されるシナリオが考えられます。 CDNからは見えません。
One method for specifying chunk locations in a Manifest File is through the use of relative URLs. A relative URL is a URL that does not include the HOST part of a URL but only includes (part of) the PATH part of a URL. In practice, a relative URL is used by the client as being relative to the location from which the Manifest File has been acquired. In these cases, a relative URL will take the form of a string that has to be appended to the location of the Manifest File to get the location of a specific chunk. This means that in the case where a Manifest File with relative URLs is used, all chunks will be delivered by the same Surrogate that delivered the Manifest File. A relative URL will therefore not include a hostname.
マニフェストファイルでチャンクの場所を指定する1つの方法は、相対URLを使用することです。相対URLは、URLのHOST部分を含まず、URLのPATH部分（の一部）のみを含むURLです。実際には、相対URLは、マニフェストファイルが取得された場所からの相対としてクライアントによって使用されます。これらの場合、相対URLは、特定のチャンクの場所を取得するためにマニフェストファイルの場所に追加する必要がある文字列の形式を取ります。これは、相対URLを持つマニフェストファイルが使用される場合、すべてのチャンクがマニフェストファイルを配信したのと同じサロゲートによって配信されることを意味します。したがって、相対URLにはホスト名は含まれません。
For example, in the case where a Manifest File has been requested (and received) from:
たとえば、マニフェストファイルが次の場所から要求（および受信）された場合：
http://surrogate.server.cdn.example.com/content_1/manifest.xml
a relative URL pointing to a specific segment referenced in the Manifest File might be:
マニフェストファイルで参照される特定のセグメントを指す相対URLは次のようになります。
segments/segment1_1.ts
segment / segment1_1.ts
which means that the client should take the location of the Manifest File and append the relative URL. In this case, the segment would then be requested from http://surrogate.server.cdn.example.com/ content_1/segments/segment1_1.ts.
つまり、クライアントはマニフェストファイルの場所を取得し、相対URLを追加する必要があります。この場合、セグメントはhttp://surrogate.server.cdn.example.com/ content_1 / segments / segment1_1.tsからリクエストされます。
One drawback of using relative URLs is that it forces a CDN relying on HTTP-based request routing to deliver all segments belonging to a given content item with the same Surrogate that delivered the Manifest File for that content item, which results in limited flexibility. Another drawback is that relative URLs do not allow for fallback URLs; should the Surrogate that delivered the Manifest File break down, the client is no longer able to request chunks. The advantage of relative URLs is that it is very easy to transfer content between different Surrogates and even CDNs.
相対URLを使用する場合の1つの欠点は、CDNがHTTPベースのリクエストルーティングに依存して、特定のコンテンツアイテムに属するすべてのセグメントを、そのコンテンツアイテムのマニフェストファイルを配信したのと同じサロゲートで配信しなければならず、柔軟性が制限されることです。別の欠点は、相対URLではフォールバックURLが許可されないことです。マニフェストファイルを配信したサロゲートが故障した場合、クライアントはチャンクを要求できなくなります。相対URLの利点は、さまざまなサロゲート間、さらにはCDN間でコンテンツを転送するのが非常に簡単なことです。
Another method for specifying locations of chunks (or other Manifest Files) in a Manifest File is through the use of an absolute URL. An absolute URL contains a fully formed URL (i.e., the client does not have to calculate the URL as in the case of the relative URL but can use the URL from the Manifest File directly).
マニフェストファイル内のチャンク（または他のマニフェストファイル）の場所を指定する別の方法は、絶対URLを使用する方法です。絶対URLには完全な形式のURLが含まれます（つまり、クライアントは相対URLの場合のようにURLを計算する必要はありませんが、マニフェストファイルのURLを直接使用できます）。
In the context of Manifest Files, there are two types of absolute URLs imaginable: absolute URLs with redirection and absolute URLs without redirection. The two methods differ in whether the URL points to a request routing node that will redirect the client to a Surrogate (absolute URLs with redirection) or point directly to a Surrogate hosting the requested content (absolute URLs without redirection).
マニフェストファイルのコンテキストでは、考えられる2種類の絶対URLがあります。リダイレクトを伴う絶対URLと、リダイレクトを伴わない絶対URLです。 2つの方法は、URLがクライアントをサロゲートにリダイレクトする要求ルーティングノードを指すか（リダイレクト付きの絶対URL）、または要求されたコンテンツをホストするサロゲートを直接指すか（リダイレクトなしの絶対URL）が異なります。
In the case of absolute URLs with redirection, a request for a chunk is handled by the Request Routing system of a CDN just as if it were a standalone (non-HAS) content request, which might include looking up the Surrogate (and/or CDN) best suited for delivering the requested chunk to the particular user and sending an HTTP redirect to the user with the URL pointing to the requested chunk on the specified Surrogate (and/or CDN), or a DNS response pointing to the specific Surrogate.
リダイレクトを伴う絶対URLの場合、チャンクの要求は、スタンドアロンの（非HAS）コンテンツ要求であるかのように、CDNの要求ルーティングシステムによって処理されます。これには、サロゲート（および/またはCDN）要求されたチャンクを特定のユーザーに配信し、指定されたサロゲート（またはCDN）上の要求されたチャンクを指すURL、または特定のサロゲートを指すDNS応答でHTTPリダイレクトをユーザーに送信するのに最適です。
An example of an absolute URL with redirection might look as follows:
リダイレクション付きの絶対URLの例は次のようになります。
http://requestrouting.cdn.example.com/
content_request?content=content_1&segment=segment1_1.ts
As can be seen from this example URL, the URL includes a pointer to a general CDN Request Routing function and some arguments identifying the requested segment.
このURLの例からわかるように、URLには、一般的なCDN要求ルーティング関数へのポインターと、要求されたセグメントを識別するいくつかの引数が含まれています。
The advantage of using absolute URLs with redirection is that they allow for maximum flexibility (since chunks can be distributed across Surrogates and CDNs in any imaginable way) without having to modify the Manifest File every time one or more chunks are moved (as is the case when absolute URLs without redirection are used). The downside of this method is that it can add significant load to a CDN Request Routing system, since it has to perform a redirect every time a client requests a new chunk.
リダイレクションで絶対URLを使用する利点は、1つ以上のチャンクが移動されるたびにマニフェストファイルを変更する必要なく（チャンクをサロゲートおよびCDNに想像可能な方法で分散できるため）、最大限の柔軟性が得られることです。リダイレクトのない絶対URLが使用されている場合）。この方法の欠点は、クライアントが新しいチャンクを要求するたびにリダイレクトを実行する必要があるため、CDNリクエストルーティングシステムに大きな負荷がかかる可能性があることです。
In the case of absolute URLs without redirection, the URL points directly to the specific chunk on the actual Surrogate that will deliver the requested chunk to the client. In other words, there will be no HTTP redirection operation taking place between the client requesting the chunk and the chunk being delivered to the client by the Surrogate.
リダイレクトのない絶対URLの場合、URLは、要求されたチャンクをクライアントに配信する実際のサロゲートの特定のチャンクを直接指します。つまり、チャンクを要求しているクライアントと、サロゲートによってクライアントに配信されているチャンクとの間で行われるHTTPリダイレクト操作はありません。
An example of an absolute URL without redirection is the following:
リダイレクトのない絶対URLの例は次のとおりです。
http://surrogate1.cdn.example.com/content_1/segments/segment1_1.ts
As can be seen from this example URL, the URL includes both the identifier of the requested segment (in this case segment1_1.ts) and the server that is expected to deliver the segment (in this case surrogate1.cdn.example.com). With this, the client has enough information to directly request the specific segment from the specified Surrogate.
このサンプルURLからわかるように、URLには、要求されたセグメントの識別子（この場合は、segment1_1.ts）と、セグメントの配信が予想されるサーバー（この場合は、surrogate1.cdn.example.com）の両方が含まれています。これにより、指定されたサロゲートから特定のセグメントを直接要求するのに十分な情報がクライアントにあります。
The advantage of using absolute URLs without redirection is that it allows more flexibility compared to using relative URLs (since segments do not necessarily have to be delivered by the same server) while not requiring per-segment redirection (which would add significant load to the node doing the redirection). The drawback of this method is that it requires a modification of the Manifest File every time content is moved to a different location (either within a CDN or across CDNs).
リダイレクトなしで絶対URLを使用する利点は、セグメントごとのリダイレクトを必要とせずに（ノードにかなりの負荷がかかるため）相対URLを使用する場合よりも柔軟性が高い（セグメントは必ずしも同じサーバーで配信する必要がないため）ことです。リダイレクトを行う）。この方法の欠点は、コンテンツが別の場所（CDN内またはCDN全体）に移動されるたびにマニフェストファイルを変更する必要があることです。
Though the formats and addresses of Manifest Files and chunk files do not typically differ significantly between live and Video-on-Demand (VoD) content, the time at which the Manifest Files and chunk files become available does differ significantly. For live content, chunk files and their corresponding Manifest Files are created and delivered in real time. This poses a number of potential issues for HAS optimization:
マニフェストファイルとチャンクファイルの形式とアドレスは、通常、ライブコンテンツとビデオオンデマンド（VoD）コンテンツ間で大きな違いはありませんが、マニフェストファイルとチャンクファイルが利用可能になる時間は大きく異なります。ライブコンテンツの場合、チャンクファイルとそれに対応するマニフェストファイルがリアルタイムで作成および配信されます。これにより、HAS最適化の潜在的な問題がいくつか発生します。
- With live content, chunk files are made available in real time. This limits the applicability of bundling for content acquisition purposes. Pre-positioning may still be employed; however, any significant latency in the pre-positioning may diminish the value of pre-positioning if a client requests the chunk prior to pre-positioning or if the pre-positioning request is serviced after the chunk playout time has passed.
- ライブコンテンツでは、チャンクファイルをリアルタイムで利用できます。これにより、コンテンツ取得の目的でのバンドルの適用性が制限されます。事前配置を引き続き使用できます。ただし、クライアントが事前配置の前にチャンクを要求した場合、または事前配置要求がチャンクの再生時間の経過後に処理された場合、事前配置に大きな遅延があると事前配置の値が低下する可能性があります。
- In the case of live content, Manifest Files must be updated for each chunk and therefore must be retrieved by the client prior to each chunk request. Any optimization schemes based on Manifest Files must therefore be prepared to optimize on a per-segment request basis. Manifest Files may also be polled multiple times prior to the actual availability of the next chunk.
- ライブコンテンツの場合、マニフェストファイルはチャンクごとに更新する必要があるため、各チャンクリクエストの前にクライアントが取得する必要があります。したがって、マニフェストファイルに基づく最適化スキームは、セグメントごとの要求に基づいて最適化するように準備する必要があります。マニフェストファイルは、次のチャンクが実際に使用可能になる前に、複数回ポーリングされる場合もあります。
- Since live Manifest Files are updated as new chunks become available, the cacheability of Manifest Files is limited. Though timestamping and reasonable Time-to-Live (TTL) settings can improve delivery performance, timely replication and delivery of updated Manifest Files are critical to ensuring uninterrupted playback.
- 新しいチャンクが利用可能になるとライブマニフェストファイルが更新されるため、マニフェストファイルのキャッシュ機能は制限されます。タイムスタンプと妥当な存続可能時間（TTL）設定は配信パフォーマンスを向上させることができますが、中断のない再生を確保するには、タイムリーなレプリケーションと更新されたマニフェストファイルの配信が重要です。
- Manifest Files are typically updated after the corresponding chunk is available for delivery, to prevent premature requests for chunks that are not yet available. HAS optimization approaches that employ dynamic Manifest File generation must be synchronized with chunk creation to prevent playback errors.
- マニフェストファイルは通常、対応するチャンクが配信可能になった後に更新され、まだ利用できないチャンクに対する時期尚早なリクエストを防ぎます。動的なマニフェストファイルの生成を使用するHAS最適化アプローチは、チャンクの作成と同期して、再生エラーを防止する必要があります。
Stream splicing is used to create media mashups, combining content from multiple sources. A common example in which content resides outside the CDNs is with advertisement insertion, for both VoD and live streams. Manifest Files that contain absolute URLs with redirection may contain chunk or nested Manifest File URLs that point to content not delivered via any of the interconnected CDNs.
ストリームスプライシングは、複数のソースからのコンテンツを組み合わせて、メディアマッシュアップを作成するために使用されます。コンテンツがCDNの外部に存在する一般的な例は、VoDとライブストリームの両方の広告挿入です。リダイレクション付きの絶対URLを含むマニフェストファイルには、相互接続されたCDNを介して配信されないコンテンツを指すチャンクまたはネストされたマニフェストファイルURLが含まれる場合があります。
Furthermore, client and downstream proxy devices may depend on non-URL information provided in the Manifest File (e.g., comments or custom tags) for performing stream splicing. This often occurs outside the scope of the interconnected CDNs. HAS optimization schemes that employ dynamic Manifest File generation or rewriting must be cognizant of chunk URLs, nested Manifest File URLs, and other metadata that should not be modified or removed. Improper modification of these URLs or other metadata may cause playback interruptions and in the case of unplayed advertisements may result in loss of revenue for CSPs.
さらに、クライアントおよびダウンストリームプロキシデバイスは、ストリームスプライシングを実行するために、マニフェストファイルで提供される非URL情報（コメントやカスタムタグなど）に依存する場合があります。これは、相互接続されたCDNの範囲外で発生することがよくあります。動的なマニフェストファイルの生成または書き換えを使用するHAS最適化スキームは、チャンクURL、ネストされたマニフェストファイルURL、および変更または削除してはならないその他のメタデータを認識する必要があります。これらのURLまたはその他のメタデータの不適切な変更は、再生の中断を引き起こす可能性があり、未再生の広告の場合は、CSPの収益の損失をもたらす可能性があります。
In the previous section, some of the unique properties of HAS were discussed. Furthermore, some of the CDN-specific design decisions with regards to addressing chunks have been detailed. In this section, the impact of supporting HAS in CDNI scenarios is discussed.
前のセクションでは、HASのいくつかの固有の特性について説明しました。さらに、チャンクのアドレス指定に関するCDN固有の設計決定の一部が詳細に説明されています。このセクションでは、CDNIシナリオでHASをサポートすることの影響について説明します。
There are a number of topics, or problem areas, that are of particular interest when considering the combination of HAS and CDNI. For each of these problem areas, it holds that there are a number of different ways in which the CDNI interfaces can deal with them. In general, it can be said that each problem area can either be solved in a way that minimizes the amount of HAS-specific changes to the CDNI interfaces or maximizes the flexibility and efficiency with which the CDNI interfaces can deliver HAS content. The goal for the CDNI WG should probably be to try to find the middle ground between these two extremes and try to come up with solutions that optimize the balance between efficiency and additional complexity.
HASとCDNIの組み合わせを検討する場合に特に興味深いトピックまたは問題領域がいくつかあります。これらの問題領域のそれぞれについて、CDNIインターフェースがそれらを処理する方法にはいくつかの異なる方法があると考えられます。一般に、各問題領域は、CDNIインターフェースへのHAS固有の変更の量を最小限にするか、CDNIインターフェースがHASコンテンツを配信できる柔軟性と効率を最大化する方法で解決できると言えます。 CDNI WGの目標は、これら2つの極端な中間点を見つけ、効率と複雑さのバランスを最適化するソリューションを考え出すことです。
In order to allow the WG to make this decision, this section briefly describes each of the following problem areas, together with a number of different options for dealing with them. Section 3.1 discusses the problem of how to deal with file management of groups of files, or content collections. Section 3.2 deals with a related topic: how to do content acquisition of content collections between the Upstream CDN (uCDN) and Downstream CDN (dCDN). After that, Section 3.3 describes the various options for the request routing of HAS content, particularly related to Manifest Files. Section 3.4 talks about a
WGがこの決定を行えるようにするために、このセクションでは、以下の各問題領域について簡単に説明し、それらを処理するためのさまざまなオプションをいくつか示します。セクション3.1では、ファイルのグループまたはコンテンツコレクションのファイル管理を処理する方法の問題について説明します。セクション3.2では、関連するトピックを扱います。アップストリームCDN（uCDN）とダウンストリームCDN（dCDN）の間でコンテンツコレクションのコンテンツを取得する方法です。その後、セクション3.3では、特にマニフェストファイルに関連する、HASコンテンツのリクエストルーティングのさまざまなオプションについて説明します。セクション3.4は、
number of possible optimizations for the logging of HAS content, while Section 3.5 discusses the options regarding URL signing. Finally, Section 3.6 describes different scenarios for dealing with the removal of HAS content from CDNs.
HASコンテンツのロギングの可能な最適化の数。セクション3.5では、URL署名に関するオプションについて説明します。最後に、セクション3.6では、CDNからのHASコンテンツの削除を処理するためのさまざまなシナリオについて説明します。
One of the unique properties of HAS content is that it does not consist of a single file or stream but of multiple interrelated files (segments, fragments, and/or Manifest Files). In this document, this group of files is also referred to as a content collection. Another important aspect is the difference between segments and fragments (see Section 2.1).
HASコンテンツの固有のプロパティの1つは、単一のファイルまたはストリームではなく、相互に関連する複数のファイル（セグメント、フラグメント、マニフェストファイル）で構成されることです。このドキュメントでは、このファイルのグループはコンテンツコレクションとも呼ばれます。もう1つの重要な側面は、セグメントとフラグメントの違いです（セクション2.1を参照）。
Irrespective of whether segments or fragments are used, different CDNs might handle content collections differently from a file management perspective. For example, some CDNs might handle all files belonging to a content collection as individual files that are stored independently from each other. An advantage of this approach is that it makes it easy to cache individual chunks. Other CDNs might store all fragments belonging to a content collection in a bundle, as if they were a single file (e.g., by using a fragmented MP4 container). The advantage of this approach is that it reduces file management overhead.
セグメントまたはフラグメントのどちらが使用されているかに関係なく、ファイル管理の観点から、異なるCDNはコンテンツコレクションを異なる方法で処理する場合があります。たとえば、一部のCDNは、コンテンツコレクションに属するすべてのファイルを、互いに独立して格納される個別のファイルとして処理する場合があります。このアプローチの利点は、個々のチャンクのキャッシュが容易になることです。他のCDNは、コンテンツコレクションに属するすべてのフラグメントを1つのファイルであるかのように（たとえば、フラグメント化されたMP4コンテナーを使用して）バンドルに格納する場合があります。このアプローチの利点は、ファイル管理のオーバーヘッドが減少することです。
The following subsections look at the various ways with which the CDNI interfaces might deal with these differences in handling content collections from a file management perspective. The different options can be distinguished based on the level of HAS awareness they require on the part of the different CDNs and the CDNI interfaces.
以下のサブセクションでは、ファイル管理の観点から、CDNIインターフェースがコンテンツコレクションの処理におけるこれらの違いを処理するさまざまな方法について説明します。さまざまなオプションは、さまざまなCDNとCDNIインターフェイスの一部で必要なHAS認識のレベルに基づいて区別できます。
This option assumes no HAS awareness in both the involved CDNs and the CDNI interfaces. This means that the uCDN uses individual files, and the dCDN is not explicitly made aware of the relationship between chunks and doesn't know which files are part of the same content collection. In practice, this scenario would mean that the file management method used by the uCDN is simply imposed on the dCDN as well.
このオプションは、関連するCDNとCDNIインターフェイスの両方でHAS認識がないことを前提としています。つまり、uCDNは個々のファイルを使用し、dCDNはチャンク間の関係を明示的に認識せず、同じコンテンツコレクションの一部であるファイルを認識しません。実際には、このシナリオは、uCDNで使用されるファイル管理方法がdCDNにも単に課されることを意味します。
This scenario also means that it is not possible for the dCDN to use any form of file bundling, such as the single-file mechanism, which can be used to store fragmented content as a single file (see
このシナリオでは、dCDNが、単一ファイルメカニズムなどのファイルバンドリングの形式を使用できないことも意味します。これは、フラグメント化されたコンテンツを単一ファイルとして保存するために使用できます（
Section 2.1). The one exception to this rule is the situation where the content is fragmented and the Manifest Files on the uCDN contain byte range requests, in which case the dCDN might be able to acquire fragmented content as a single file (see Section 3.2.2.2).
セクション2.1）。このルールの1つの例外は、コンテンツが断片化されており、uCDNのマニフェストファイルにバイト範囲リクエストが含まれている場合です。その場合、dCDNは断片化されたコンテンツを単一のファイルとして取得できる可能性があります（セクション3.2.2.2を参照）。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o None
o なし
Advantages/Drawbacks:
利点/欠点：
+ No HAS awareness necessary in CDNs; no changes to CDNI interfaces necessary
+ CDNではHAS認識は必要ありません。 CDNIインターフェースの変更は不要
- The dCDN is forced to store chunks as individual files
- dCDNはチャンクを個別のファイルとして保存する必要があります
In some cases, the dCDN might prefer to store fragmented content as a single file on its Surrogates to reduce file management overhead. In order to do so, it needs to be able to either acquire the content as a single file (see Section 3.2.2.2) or to merge the different chunks together and place them in the same container (e.g., fragmented MP4). The downside of this method is that in order to do so, the dCDN needs to be fully HAS aware.
場合によっては、dCDNは断片化されたコンテンツを単一のファイルとしてサロゲートに格納し、ファイル管理のオーバーヘッドを減らすことを好む場合があります。これを行うには、コンテンツを単一のファイルとして取得するか（セクション3.2.2.2を参照）、異なるチャンクをマージして同じコンテナー（フラグメント化されたMP4など）に配置できる必要があります。この方法の欠点は、そのために、dCDNが完全にHASを認識する必要があることです。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: Add fields for indicating the particular type of HAS (e.g., MPEG DASH or HLS) that is used and whether segments or fragments are used
o CDNIメタデータインターフェース：使用されているHASの特定のタイプ（MPEG DASHまたはHLSなど）と、セグメントまたはフラグメントが使用されているかどうかを示すフィールドを追加します
o CDNI Metadata interface: Add field for indicating the name and type of the Manifest File(s)
o CDNIメタデータインターフェース：マニフェストファイルの名前とタイプを示すフィールドを追加
Advantages/Drawbacks:
利点/欠点：
+ Allows the dCDN to store fragmented content as a single file, reducing file management overhead
+ dCDNが断片化されたコンテンツを単一のファイルとして保存できるようにし、ファイル管理のオーバーヘッドを削減
- Complex operation, requiring the dCDN to be fully HAS aware
- 複雑な操作、dCDNが完全にHASを認識する必要がある
An intermediary approach between the two extremes detailed in the previous two sections is one that uses an 'Access Correlation Hint'. This hint, which is added to the CDNI Metadata of all chunks of a particular content collection, indicates that those files are likely to be requested in a short time window from each other. This information can help a dCDN to implement local file storage optimizations for VoD items (e.g., by bundling all files with the same Access Correlation Hint value in a single bundle/file), thereby reducing the number of files it has to manage while not requiring any HAS awareness.
前の2つのセクションで詳述した2つの極端な方法の中間的なアプローチは、「アクセス相関のヒント」を使用する方法です。特定のコンテンツコレクションのすべてのチャンクのCDNIメタデータに追加されるこのヒントは、これらのファイルが互いに短い時間枠で要求される可能性が高いことを示しています。この情報は、dCDNがVoDアイテムのローカルファイルストレージ最適化を実装するのに役立ち（たとえば、単一のバンドル/ファイルに同じアクセス相関ヒント値を持つすべてのファイルをバンドルすることにより）、それによって、必要とせずに管理する必要があるファイルの数を減らすことができます。 HASの認識。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: Add field for indicating Access Correlation Hint
o CDNIメタデータインターフェイス：アクセス相関ヒントを示すフィールドを追加
Advantages/Drawbacks:
利点/欠点：
+ Allows the dCDN to perform file management optimization
+ dCDNがファイル管理の最適化を実行できるようにします
+ Does not require any HAS awareness
+ HAS認識を必要としません
+ Very small impact on CDNI interfaces
+ CDNIインターフェイスへの非常に小さな影響
- Expected benefit compared with Option 1.1 is small
- オプション1.1と比較して期待されるメリットは小さい
Based on the listed pros and cons, the authors recommend that the WG go for Option 1.1 (do nothing). The likely benefits of going for Option 1.3 are not believed to be significant enough to warrant changing the CDNI Metadata interface. Although Option 1.2 would bring definite benefits for HAS-aware dCDNs, going for this option would require significant CDNI extensions that would impact the WG's milestones. The authors therefore don't recommend including it in the current work but mark it as a possible candidate for rechartering once the initial CDNI solution is completed.
リストされた長所と短所に基づいて、作成者はWGがオプション1.1に進むことを推奨します（何もしない）。オプション1.3に移行することで得られる可能性のあるメリットは、CDNIメタデータインターフェイスの変更を正当化するほど重要であるとは考えられていません。オプション1.2はHAS対応のdCDNに明確な利点をもたらしますが、このオプションを使用するには、WGのマイルストーンに影響を与える重要なCDNI拡張が必要です。したがって、著者は現在の作業にそれを含めることはお勧めしませんが、最初のCDNIソリューションが完了したら、再充電の候補としてマークします。
In the previous section, the relationship between file management and HAS in a CDNI scenario was discussed. This section discusses a related topic: content acquisition between two CDNs.
前のセクションでは、CDNIシナリオにおけるファイル管理とHASの関係について説明しました。このセクションでは、2つのCDN間のコンテンツ取得という関連トピックについて説明します。
With regards to content acquisition, it is important to note the difference between CDNs that do dynamic acquisition of content and CDNs that perform content pre-positioning. In the case of dynamic acquisition, a CDN only requests a particular content item when a cache miss occurs. In the case of pre-positioning, a CDN proactively places content items on the nodes on which it expects traffic for that particular content item. For each of these types of CDNs, there might be a benefit in being HAS aware. For example, in the case of dynamic acquisition, being HAS aware means that after a cache miss for a given chunk occurs, that node might not only acquire the requested chunk but might also acquire some related chunks that are expected to be requested in the near future. In the case of pre-positioning, similar benefits can be had.
コンテンツの取得に関しては、コンテンツの動的取得を行うCDNとコンテンツの事前配信を実行するCDNの違いに注意することが重要です。動的取得の場合、CDNは、キャッシュミスが発生したときにのみ特定のコンテンツアイテムを要求します。事前配信の場合、CDNは、特定のコンテンツアイテムのトラフィックが予想されるノードにコンテンツアイテムを積極的に配置します。これらの各タイプのCDNについて、HASを認識することには利点がある場合があります。たとえば、動的取得の場合、HASに対応しているとは、特定のチャンクのキャッシュミスが発生した後、そのノードが要求されたチャンクを取得するだけでなく、近くで要求されることが予想される関連チャンクも取得する可能性があることを意味します。未来。事前配置の場合、同様の利点があります。
This option assumes no HAS awareness in both the involved CDNs and the CDNI interfaces. Just as with Option 1.1, discussed earlier with regards to file management, having no HAS awareness means that the dCDN is not aware of the relationship between chunks. In the case of content acquisition, this means that each and every file belonging to a content collection will have to be individually acquired from the uCDN by the dCDN. The exception to the rule is cases with fragmented content where the uCDN uses Manifest Files that contain byte range requests. In this case, the dCDN can simply omit the byte range identifier and acquire the complete file.
このオプションは、関連するCDNとCDNIインターフェイスの両方でHAS認識がないことを前提としています。ファイル管理に関して前述したオプション1.1と同様に、HAS認識がないことは、dCDNがチャンク間の関係を認識していないことを意味します。コンテンツ取得の場合、これは、コンテンツコレクションに属するすべてのファイルを、dCDNによってuCDNから個別に取得する必要があることを意味します。ルールの例外は、uCDNがバイト範囲リクエストを含むマニフェストファイルを使用する、断片化されたコンテンツの場合です。この場合、dCDNは単にバイト範囲識別子を省略して、完全なファイルを取得できます。
The advantage of this approach is that it is highly flexible. If a client only requests a small portion of the chunks belonging to a particular content collection, the dCDN only has to acquire those chunks from the uCDN, saving both bandwidth and storage capacity.
このアプローチの利点は、柔軟性が高いことです。クライアントが特定のコンテンツコレクションに属するチャンクのごく一部のみを要求する場合、dCDNはuCDNからそれらのチャンクを取得するだけでよく、帯域幅とストレージ容量の両方を節約できます。
The downside of acquiring content on a per-chunk basis is that it creates more transaction overhead between the dCDN and uCDN, compared to a method in which entire content collections can be acquired as part of one transaction.
チャンクごとにコンテンツを取得することの欠点は、コンテンツコレクション全体を1つのトランザクションの一部として取得できる方法と比較して、dCDNとuCDN間のトランザクションオーバーヘッドが増えることです。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o None
o なし
Advantages/Drawbacks:
利点/欠点：
+ Per-chunk content acquisition allows for a high level of flexibility between the dCDN and uCDN
+ チャンクごとのコンテンツ取得により、dCDNとuCDN間の高度な柔軟性が可能になります
- Per-chunk content acquisition creates more transaction overhead between the dCDN and uCDN
- チャンクごとのコンテンツ取得により、dCDNとuCDN間のトランザクションオーバーヘッドが増加します。
3.2.2.2. Option 2.2: Allow Single-File Acquisition of Fragmented Content
3.2.2.2. オプション2.2：断片化されたコンテンツの単一ファイル取得を許可する
As discussed in Section 3.2.2.1, there is one (fairly rare) case where fragmented content can be acquired as a single file without any HAS awareness, and that is when fragmented content is used and where the Manifest File specifies byte range requests. This section discusses how to perform single-file acquisition in the other (very common) cases. To do so, the dCDN would have to have full HAS awareness (at least to the extent of being able to map between a single file and individual chunks to serve).
セクション3.2.2.1で説明したように、フラグメント化されたコンテンツがHAS認識なしで単一のファイルとして取得できる（かなりまれな）ケースが1つあります。これは、フラグメント化されたコンテンツが使用され、マニフェストファイルがバイト範囲リクエストを指定する場合です。このセクションでは、他の（非常に一般的な）ケースで単一ファイルの取得を実行する方法について説明します。そのためには、dCDNが完全なHAS認識を持っている必要があります（少なくとも、単一のファイルとサービス対象の個々のチャンクをマッピングできる範囲で）。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: Add fields for indicating the particular type of HAS (e.g., MPEG DASH or HLS) that is used and whether segments or fragments are used
o CDNIメタデータインターフェース：使用されているHASの特定のタイプ（MPEG DASHまたはHLSなど）と、セグメントまたはフラグメントが使用されているかどうかを示すフィールドを追加します
o CDNI Metadata interface: Add field for indicating the name and type of the Manifest File(s)
o CDNIメタデータインターフェース：マニフェストファイルの名前とタイプを示すフィールドを追加
Advantages/Drawbacks:
利点/欠点：
+ Allows for more efficient content acquisition in all HAS-specific supported forms
+ HAS固有のサポートされているすべてのフォームでより効率的なコンテンツ取得が可能
- Requires full HAS awareness on the part of the dCDN
- dCDN側で完全なHAS認識が必要
- Requires significant CDNI Metadata interface extensions
- 重要なCDNIメタデータインターフェイス拡張が必要
Based on the listed pros and cons, the authors recommend that the WG go for Option 2.1, since it is sufficient to 'make HAS work'. While Option 2.2 would bring benefits to the acquisition of large content collections, it would require significant CDNI extensions that would impact the WG's milestones. Option 2.2 might be a candidate to include in possible rechartering once the initial CDNI solution is completed.
リストされた長所と短所に基づいて、「HASを機能させる」ことで十分なので、WGはオプション2.1に進むことを著者は推奨します。オプション2.2は、大規模なコンテンツコレクションの取得にメリットをもたらしますが、WGのマイルストーンに影響を与える重要なCDNI拡張が必要になります。オプション2.2は、最初のCDNIソリューションが完了したら、可能な再充電に含める候補になる可能性があります。
In this section, the effect HAS content has on request routing is identified. Of particular interest in this case are the different types of Manifest Files that might be used. In Section 2.2, three different methods for identifying and addressing chunks from within a Manifest File were described: relative URLs, absolute URLs with redirection, and absolute URLs without redirection. Of course, not every current CDN will use and/or support all three methods. Some CDNs may only use one of the three methods, while others may support two or all three.
このセクションでは、HASコンテンツがリクエストルーティングに与える影響を特定します。この場合に特に興味深いのは、使用される可能性のあるさまざまなタイプのマニフェストファイルです。セクション2.2では、マニフェストファイル内からチャンクを識別してアドレス指定するための3つの異なる方法について説明しました：相対URL、リダイレクトありの絶対URL、リダイレクトなしの絶対URL。もちろん、現在のすべてのCDNが3つの方法すべてを使用またはサポートするわけではありません。一部のCDNは3つの方法の1つのみを使用する場合がありますが、2つまたは3つすべてをサポートする場合もあります。
An important factor in deciding which chunk-addressing method is used is the CSP. Some CSPs may have a strong preference for a particular method and deliver the Manifest Files to the CDN in a particular way. Depending on the CDN and the agreement it has with the CSP, a CDN may either host the Manifest Files as they were created by the CSP or modify the Manifest File to adapt it to its particular architecture (e.g., by changing relative URLs to absolute URLs that point to the CDN Request Routing function).
使用するチャンクアドレス指定方法を決定する際の重要な要素は、CSPです。一部のCSPは、特定の方法を強く好み、マニフェストファイルを特定の方法でCDNに配信する場合があります。 CDNとCSPとの合意に応じて、CDNは、CSPによって作成されたマニフェストファイルをホストするか、マニフェストファイルを変更して特定のアーキテクチャに適合させることができます（たとえば、相対URLを絶対URLに変更することによって） CDNリクエストルーティング機能を指します）。
This option assumes no HAS awareness in both the involved CDNs and the CDNI interfaces. This scenario also assumes that neither the dCDN nor the uCDN has the ability to actively manipulate Manifest Files. As was also discussed with regards to file management and content acquisition, having no HAS awareness means that each file constituting a content collection is handled on an individual basis, with the dCDN unaware of any relationship between files.
このオプションは、関連するCDNとCDNIインターフェイスの両方でHAS認識がないことを前提としています。このシナリオでは、dCDNもuCDNもマニフェストファイルをアクティブに操作する機能がないことも前提としています。ファイル管理とコンテンツ取得に関しても説明したように、HAS認識がないことは、コンテンツコレクションを構成する各ファイルが個別に処理され、dCDNがファイル間の関係を認識しないことを意味します。
The only chunk-addressing method that works without question in this case is absolute URLs with redirection. In other words, the CSP that ingested the content into the uCDN created a Manifest File with each chunk location pointing to the Request Routing function of the uCDN. Alternatively, the CSP may have ingested the Manifest File containing relative URLs, and the uCDN ingestion function has translated these to absolute URLs pointing to the Request Routing function.
この場合に問題なく機能する唯一のチャンクアドレス指定方法は、リダイレクトを伴う絶対URLです。つまり、コンテンツをuCDNに取り込んだCSPは、各チャンクの場所がuCDNのリクエストルーティング機能を指すマニフェストファイルを作成しました。または、CSPが相対URLを含むマニフェストファイルを取り込み、uCDN取り込み機能がこれらをリクエストルーティング機能を指す絶対URLに変換した可能性があります。
In this "absolute URL with redirection" case, the uCDN can simply have the Manifest File be delivered by the dCDN as if it were a regular file. Once the client parses the Manifest File, it will request any subsequent chunks from the uCDN Request Routing function. That function can then decide to outsource the delivery of those chunks to the dCDN. Depending on whether HTTP-based (recursive or iterative) or DNS-based request routing is used, the uCDN Request Routing function will then either directly or indirectly redirect the client to the Request Routing function of the dCDN (assuming that it does not have the necessary information to redirect the client directly to a Surrogate in the dCDN).
この「リダイレクトを伴う絶対URL」の場合、uCDNは、マニフェストファイルを通常のファイルのようにdCDNから配信するだけです。クライアントがマニフェストファイルを解析すると、uCDN要求ルーティング機能から後続のチャンクを要求します。その関数は、それらのチャンクの配信をdCDNに外部委託することを決定できます。 HTTPベース（再帰的または反復的）またはDNSベースの要求ルーティングのどちらを使用するかに応じて、uCDN要求ルーティング機能は、クライアントを直接または間接的にdCDNの要求ルーティング機能にリダイレクトします（クライアントをdCDNのサロゲートに直接リダイレクトするために必要な情報）。
The drawback of this method is that it creates a large amount of request routing overhead for both the uCDN and dCDN. For each chunk, the full inter-CDN Request Routing process is invoked (which can result in two HTTP redirections in the case of iterative redirection, or one HTTP redirection plus one CDNI Request Routing Redirection interface request/response). Even in the case where DNS-based redirection is used, there might be significant overhead involved, since both the dCDN and uCDN Request Routing functions might have to perform database lookups and query each other. While with DNS this overhead might be reduced by using DNS's inherent caching mechanism, this will have significant impact on the accuracy of the redirect.
この方法の欠点は、uCDNとdCDNの両方に大量の要求ルーティングオーバーヘッドが発生することです。各チャンクについて、完全なCDN要求ルーティングプロセスが呼び出されます（反復リダイレクトの場合、2つのHTTPリダイレクト、または1つのHTTPリダイレクトと1つのCDNIリクエストルーティングリダイレクトインターフェイスの要求/応答が発生する可能性があります）。 DNSベースのリダイレクトを使用する場合でも、dCDNとuCDNの要求ルーティング機能の両方がデータベースの検索を実行し、相互にクエリを実行する必要があるため、かなりのオーバーヘッドが発生する可能性があります。 DNSでは、DNSの固有のキャッシュメカニズムを使用することでこのオーバーヘッドを減らすことができますが、これはリダイレクトの正確さに大きな影響を与えます。
With no HAS awareness, relative URLs might or might not work, depending on the type of relative URL that is used. When a uCDN delegates the delivery of a Manifest File containing relative URLs to a dCDN, the client goes directly to the dCDN Surrogate from which it has received the Manifest File for every subsequent chunk. As long as the relative URL is not path-absolute (see [RFC3986]), this approach will work fine.
HAS認識がない場合、使用される相対URLのタイプに応じて、相対URLが機能する場合と機能しない場合があります。 uCDNが相対URLを含むマニフェストファイルの配信をdCDNに委任すると、クライアントは後続のすべてのチャンクのマニフェストファイルを受け取ったdCDNサロゲートに直接移動します。相対URLが絶対パスではない限り（[RFC3986]を参照）、このアプローチは問題なく機能します。
Since using absolute URLs without redirection inherently requires a HAS-aware CDN, absolute URLs without redirection cannot be used in this case because the URLs in the Manifest File will point directly to a Surrogate in the uCDN. Since this scenario assumes no HAS awareness on the part of the dCDN or uCDN, it is impossible for either of these CDNs to rewrite the Manifest File and thus allow the client to either go to a Surrogate in the dCDN or to a Request Routing function.
リダイレクトなしの絶対URLを使用するには本質的にHAS対応のCDNが必要であるため、この場合、リダイレクションなしの絶対URLは使用できません。これは、マニフェストファイルのURLがuCDNのサロゲートを直接指すためです。このシナリオでは、dCDNまたはuCDNの側にHAS認識がないことを前提としているため、これらのCDNのいずれかがマニフェストファイルを書き換えることは不可能であり、クライアントがdCDNのサロゲートまたはリクエストルーティング機能にアクセスできるようにします。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o None
o なし
Advantages/Drawbacks:
利点/欠点：
+ Supports absolute URLs with redirection
+ リダイレクションで絶対URLをサポート
+ Supports relative URLs
+ 相対URLをサポート
+ Does not require HAS awareness and/or changes to the CDNI interfaces
+ HAS認識やCDNIインターフェースへの変更を必要としません
- Not possible to use absolute URLs without redirection
- リダイレクトなしで絶対URLを使用することはできません
- Creates significant signaling overhead in cases where absolute URLs with redirection are used (inter-CDN request redirection for each chunk)
- リダイレクション付きの絶対URLが使用されている場合に、シグナリングのオーバーヘッドが大幅に増加します（各チャンクのCDN間リダイレクション）。
While Option 3.1 does allow absolute URLs with redirection to be used, it does so in a way that creates a high level of request routing overhead for both the dCDN and the uCDN. This option presents a solution to significantly reduce this overhead.
オプション3.1ではリダイレクトを伴う絶対URLの使用が許可されていますが、dCDNとuCDNの両方に高レベルのリクエストルーティングオーバーヘッドが発生するような方法で許可されます。このオプションは、このオーバーヘッドを大幅に削減するソリューションを提供します。
In this scenario, the uCDN is able to rewrite the Manifest File (or generate a new one) to be able to remove itself from the request routing chain for chunks being referenced in the Manifest File. As described in Section 3.3.2.1, in the case of no HAS awareness, the client will go to the uCDN Request Routing function for each chunk request. This Request Routing function can then redirect the client to the dCDN Request Routing function. By rewriting the Manifest File (or generating a new one), the uCDN is able to remove this first step and have the Manifest File point directly to the dCDN Request Routing function.
このシナリオでは、uCDNはマニフェストファイルを書き換え（または新しいファイルを生成）して、マニフェストファイルで参照されているチャンクの要求ルーティングチェーンから自分自身を削除できます。セクション3.3.2.1で説明したように、HAS認識がない場合、クライアントは各チャンク要求のuCDN要求ルーティング機能に移動します。この要求ルーティング機能は、クライアントをdCDN要求ルーティング機能にリダイレクトできます。マニフェストファイルを書き換える（または新しいファイルを生成する）ことにより、uCDNはこの最初のステップを削除し、マニフェストファイルがdCDNリクエストルーティング機能を直接指すようにすることができます。
A key advantage of this solution is that it does not directly have an impact on the CDNI interfaces and is therefore transparent to these interfaces. It is a CDN-internal function that a uCDN can perform autonomously by using information configured for regular CDNI operation or received from the dCDN as part of the regular communication using the CDNI Request Routing Redirection interface.
このソリューションの主な利点は、CDNIインターフェイスに直接影響しないため、これらのインターフェイスに対して透過的であることです。これは、通常のCDNI操作用に構成された情報、またはCDNI要求ルーティングリダイレクトインターフェイスを使用した通常の通信の一部としてdCDNから受信した情報を使用して、uCDNが自律的に実行できるCDN内部機能です。
More specifically, in order for the uCDN to rewrite the Manifest File, the minimum information needed is the location of the dCDN Request Routing function (or, alternatively, the location of the dCDN delivering Surrogate). This information can be available from configuration or can be derived from the regular CDNI Request Routing Redirection interface. For example, the uCDN may ask the dCDN for the location of its request routing node (through the CDNI Request Routing Redirection interface) every time a request for a Manifest File is received and processed by the uCDN Request Routing function. The uCDN would then modify the Manifest File and deliver the Manifest File to the client. One advantage of this method is that it maximizes efficiency and flexibility by allowing the dCDN to optionally respond with the locations of its Surrogates instead of the location of its Request Routing function (and effectively turning the URLs into absolute URLs without redirection). There are many variations on this approach, such as where the modification of the Manifest File is only performed once (or once per period of time) by the uCDN Request Routing function, when the first client for that particular content collection (and redirected to that particular dCDN) sends a Manifest File request. The advantage of such a variation is that the uCDN only has to modify the Manifest File once (or once per time period). The drawback of this variation is that the dCDN is no longer in a position to influence the request routing decision across individual content requests.
より具体的には、uCDNがマニフェストファイルを書き換えるために必要な最低限の情報は、dCDNリクエストルーティング機能の場所（または、dCDN配信サロゲートの場所）です。この情報は、構成から取得することも、通常のCDNI要求ルーティングリダイレクトインターフェイスから取得することもできます。たとえば、uCDNは、マニフェストファイルの要求がuCDN要求ルーティング機能によって受信および処理されるたびに、（CDNI要求ルーティングリダイレクションインターフェイスを介して）要求ルーティングノードの場所をdCDNに要求します。その後、uCDNはマニフェストファイルを変更し、マニフェストファイルをクライアントに配信します。この方法の利点の1つは、リクエストルーティング機能の場所の代わりにサロゲートの場所でdCDNがオプションで応答できるようにして、効率と柔軟性を最大化することです（そして、リダイレクトせずにURLを絶対URLに効果的に変換します）。このアプローチには多くのバリエーションがあります。たとえば、マニフェストファイルの変更は、特定のコンテンツコレクションの最初のクライアントが（およびそのリダイレクトされたときに）uCDNリクエストルーティング機能によって1回だけ（または期間ごとに1回）実行される場合などです。特定のdCDN）は、マニフェストファイル要求を送信します。このようなバリエーションの利点は、uCDNがマニフェストファイルを1回（または期間ごとに1回）変更するだけでよいことです。このバリエーションの欠点は、dCDNが個々のコンテンツリクエスト全体のリクエストルーティング決定に影響を与えることができないことです。
It should be noted that there are a number of things to take into account when changing a Manifest File (see, for example, Sections 2.3 and 2.4 on live HAS content and ad insertion). Furthermore, some CSPs might have issues with a CDN changing Manifest Files. However, in this option the Manifest File manipulation is only being performed by the uCDN, which can be expected to be aware of these limitations if it wants to perform Manifest File manipulation, since it is in its own best interest that its customer's content gets delivered in the proper way and since there is a direct commercial and technical relationship between the uCDN (the Authoritative CDN in this scenario) and its customer (the CSP). Should the CSP want to limit Manifest File manipulation, it can simply arrange this with the uCDN bilaterally.
マニフェストファイルを変更するときは、考慮すべき点がいくつかあることに注意してください（たとえば、ライブHASコンテンツと広告挿入に関するセクション2.3および2.4を参照）。さらに、一部のCSPは、CDNがマニフェストファイルを変更するときに問題が発生する場合があります。ただし、このオプションでは、マニフェストファイルの操作はuCDNによってのみ実行されます。これは、マニフェストファイルの操作を実行したい場合に、これらの制限を認識していることが期待できるためです。適切な方法で、uCDN（このシナリオではAuthoritative CDN）とその顧客（CSP）の間に直接の商業的および技術的関係があるため。 CSPがマニフェストファイルの操作を制限する必要がある場合は、これをuCDNで双方向に調整できます。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o None
o なし
Advantages/Drawbacks:
利点/欠点：
+ Possible to significantly decrease signaling overhead when using absolute URLs
+ 絶対URLを使用すると、シグナリングのオーバーヘッドを大幅に削減することが可能
+ (Optional) Possible to have the uCDN rewrite the Manifest File with locations of Surrogates in the dCDN (turning absolute URLs with redirection into absolute URLs without redirection)
+ （オプション）uCDNでdCDNのサロゲートの場所を使用してマニフェストファイルを書き換えることができます（リダイレクトのある絶対URLをリダイレクトのない絶対URLに変換します）
+ No changes to CDNI interfaces
+ CDNIインターフェースへの変更なし
+ Does not require HAS awareness in the dCDN
+ dCDNでHAS認識を必要としません
- Requires a high level of HAS awareness in the uCDN (for modifying Manifest Files)
- uCDNで高レベルのHAS認識が必要（マニフェストファイルを変更するため）
One of the possibilities with Option 3.2 is allowing the dCDN to provide the locations of a specific Surrogate to the uCDN, so that the uCDN can fit the Manifest File with absolute URLs without redirection and the client can request chunks directly from a dCDN Surrogate. However, some dCDNs might not be willing to provide this information to the uCDN. In that case, they can only provide the uCDN with the location of their Request Routing function, thereby preventing the use of absolute URLs without redirection.
オプション3.2の可能性の1つは、dCDNが特定のサロゲートの場所をuCDNに提供できるようにすることです。これにより、uCDNはリダイレクトなしで絶対URLでマニフェストファイルに適合でき、クライアントはdCDNサロゲートから直接チャンクを要求できます。ただし、一部のdCDNは、この情報をuCDNに提供する意思がない場合があります。その場合、彼らはuCDNにリクエストルーティング機能の場所のみを提供できるため、リダイレクトせずに絶対URLを使用できなくなります。
One method for solving this limitation is allowing two-step Manifest File manipulation. In the first step, the uCDN would perform its own modification and place the locations of the dCDN Request Routing function in the Manifest File. Then, once a request for the Manifest File comes in at the dCDN Request Routing function, it would perform a second modification in which it replaces the URLs in the Manifest Files with the URLs of its Surrogates. This way, the dCDN can still profit from having limited request routing traffic while not having to share sensitive Surrogate information with the uCDN.
この制限を解決する1つの方法は、2段階のマニフェストファイル操作を許可することです。最初のステップでは、uCDNは独自の変更を実行し、dCDNリクエストルーティング機能の場所をマニフェストファイルに配置します。次に、マニフェストファイルのリクエストがdCDNリクエストルーティング機能で受信されると、マニフェストファイルのURLをサロゲートのURLに置き換える2番目の変更を実行します。このようにして、機密性の高い代理情報をuCDNと共有する必要がない一方で、dCDNは要求ルーティングトラフィックを制限することで利益を得ることができます。
The downside of this approach is that it not only assumes HAS awareness in the dCDN but also requires some HAS-specific additions to the CDNI Metadata interface. In order for the dCDN to be able to change the Manifest File, it has to have some information about the structure of the content. Specifically, it needs to have information about which chunks make up the content collection.
このアプローチの欠点は、dCDNでのHAS認識を前提とするだけでなく、CDNIメタデータインターフェイスへのHAS固有の追加も必要になることです。 dCDNがマニフェストファイルを変更できるようにするには、コンテンツの構造に関する情報が必要です。具体的には、コンテンツコレクションを構成するチャンクに関する情報が必要です。
Effect on CDNI interfaces (apart from those already listed under Option 3.2):
CDNIインターフェースへの影響（オプション3.2ですでにリストされているものを除く）：
o CDNI Metadata interface: Add necessary fields for conveying HAS-specific information (e.g., the files that make up the content collection) to the dCDN
o CDNIメタデータインターフェース：HAS固有の情報（コンテンツコレクションを構成するファイルなど）をdCDNに伝達するために必要なフィールドを追加します
o CDNI Metadata interface: Allow dCDN to modify Manifest File
o CDNIメタデータインターフェイス：dCDNがマニフェストファイルを変更できるようにする
Advantages/Drawbacks (apart from those already listed under Option 3.2):
利点/欠点（オプション3.2ですでにリストされているものを除く）：
+ Allows the dCDN to use absolute URLs without redirection, without having to convey sensitive information to the uCDN
+ 機密情報をuCDNに伝える必要なく、dCDNがリダイレクトせずに絶対URLを使用できるようにします。
- Requires a high level of HAS awareness in the dCDN (for modifying Manifest Files)
- dCDNで高レベルのHAS認識が必要（マニフェストファイルを変更するため）
- Requires adding HAS-specific and Manifest File manipulation-specific information to the CDNI Metadata interface
- HAS固有およびマニフェストファイル操作固有の情報をCDNIメタデータインターフェイスに追加する必要があります
Based on the listed pros and cons, the authors recommend going for Option 3.1, with Option 3.2 as an optional feature that may be supported as a CDN-internal behavior by a uCDN. While Option 3.1 allows for HAS content to be delivered using the CDNI interfaces, it does so with some limitations regarding supported Manifest Files and, in some cases, with a large amount of signaling overhead. Option 3.2 can solve most of these limitations and presents a significant reduction in request routing overhead. Since Option 3.2 does not require any changes to the CDNI interfaces but only changes the way the uCDN uses the existing interfaces, supporting it is not expected to result in a significant delay of the WG's milestones. The authors recommend that the WG not include Option 3.3, since it raises some questions of potential brittleness and including it would result in a significant delay of the WG's milestones.
リストされた長所と短所に基づいて、著者はオプション3.1に進むことをお勧めします。オプション3.2は、uCDNによってCDN内部動作としてサポートされるオプション機能です。オプション3.1では、CDNIインターフェイスを使用してHASコンテンツを配信できますが、サポートされているマニフェストファイルに関していくつかの制限があり、場合によっては、大量のシグナリングオーバーヘッドがあります。オプション3.2は、これらの制限のほとんどを解決でき、要求ルーティングのオーバーヘッドを大幅に削減します。オプション3.2はCDNIインターフェースの変更を必要とせず、uCDNが既存のインターフェースを使用する方法を変更するだけなので、これをサポートすることでWGのマイルストーンが大幅に遅延することはないと予想されます。著者は、WGにオプション3.3を含めないことをお勧めします。これは、脆弱性の可能性についていくつかの疑問を引き起こし、これを含めると、WGのマイルストーンが大幅に遅延するためです。
As stated in [RFC6707], the CDNI Logging interface enables details of logs or events to be exchanged between interconnected CDNs.
[RFC6707]で述べられているように、CDNI Loggingインターフェイスを使用すると、相互接続されたCDN間でログまたはイベントの詳細を交換できます。
As discussed in [CDNI-LOGGING], the CDNI logging information can be used for multiple purposes, including maintenance/debugging by a uCDN, accounting (e.g., for billing or settlement purposes), reporting and management of end-user experience (e.g., to the CSP), analytics (e.g., by the CSP), and control of content distribution policy enforcement (e.g., by the CSP).
[CDNI-LOGGING]で説明したように、CDNIロギング情報は、uCDNによるメンテナンス/デバッグ、アカウンティング（たとえば、請求または決済のため）、レポートおよびエンドユーザーエクスペリエンスの管理（たとえば、 （CSPへ）、分析（CSPなど）、およびコンテンツ配信ポリシー適用の制御（CSPなど）。
The key consideration for HAS with respect to logging is the potential increase of the number of log records by two to three orders of magnitude, as compared to regular HTTP delivery of a video, since by default log records would typically be generated on a per-chunk-delivery basis instead of a per-content-item-delivery basis. This impacts the scale of every processing step in the logging process (see [CDNI-LOGGING]), including:
ロギングに関するHASの重要な考慮事項は、通常、デフォルトでログレコードが生成されるため、ビデオの通常のHTTP配信と比較して、ログレコードの数が2〜3桁増加する可能性があることです。コンテンツアイテムごとの配信ではなく、チャンクによる配信。これは、以下を含む、ロギングプロセス（[CDNI-LOGGING]を参照）のすべての処理ステップの規模に影響します。
a. Logging information generation and storing on CDN elements (Surrogate, Request Routers, ...)
a. 情報生成のロギングとCDN要素への保存（サロゲート、リクエストルーターなど）
b. Logging information aggregation within a CDN
b. CDN内のロギング情報の集約
c. Logging information manipulation (including information protection, filtering, update, and rectification)
c. 情報操作のログ記録（情報保護、フィルタリング、更新、修正を含む）
d. (Where needed) CDNI reformatting of logging information (e.g., reformatting from a CDN-specific format to the CDNI Logging interface format for export by the dCDN to the uCDN)
d. （必要な場合）ログ情報のCDNI再フォーマット（例：dCDNからuCDNにエクスポートするためのCDN固有のフォーマットからCDNI Loggingインターフェースフォーマットへの再フォーマット）
e. Logging exchange via the CDNI Logging interface f. (Where needed) Logging re-reformatting (e.g., reformatting from the CDNI Logging interface format into a log-consuming application)
e。 CDNIログインターフェイスを介したログ交換f。 （必要な場合）ロギングの再フォーマット（例：CDNI Loggingインターフェースフォーマットからログを消費するアプリケーションへの再フォーマット）
g. Logging consumption/processing (e.g., feed logs into uCDN accounting application, feed logs into uCDN reporting system to provide per-CSP views, feed logs into debugging tools)
g. ログの消費/処理（例：uCDNアカウンティングアプリケーションへのフィードログ、CSPごとのビューを提供するためのuCDNレポートシステムへのフィードログ、デバッグツールへのフィードログ）
Note that there may be multiple instances of steps [f] and [g] running in parallel.
ステップ[f]と[g]の複数のインスタンスが並行して実行される場合があることに注意してください。
While the CDNI Logging interface is only used to perform step [e], we note that its format directly affects steps [d] and [f] and that its format also indirectly affects the other steps (for example, if the CDNI Logging interface requires per-chunk log records, steps [a], [b], and [d] cannot operate on a per-HAS-session basis, and they also need to operate on a per-chunk basis).
CDNI Loggingインターフェースはステップ[e]の実行にのみ使用されますが、そのフォーマットはステップ[d]と[f]に直接影響し、そのフォーマットは他のステップにも間接的に影響することに注意してください（たとえば、CDNI Loggingインターフェースが必要な場合）チャンクごとのログレコード、ステップ[a]、[b]、および[d]は、HASセッションごとに操作することはできず、チャンクごとに操作する必要もあります）。
This section discusses the main candidate approaches identified for CDNI in terms of dealing with HAS with respect to logging.
このセクションでは、ログに関してHASを処理することに関して、CDNIのために識別された主な候補アプローチについて説明します。
In this approach, nothing is done specifically for HAS, so each HAS-chunk delivery is considered, for CDNI logging, as a standalone content delivery. In particular, a separate log record for each HAS-chunk delivery is included in the CDNI Logging interface in step [e] (as defined in Section 3.4.1). This approach requires that steps [a], [b], [c], [d], and [f] also be performed on a per-chunk basis. This approach allows step [g] to be performed either on a per-chunk basis (assuming that step [f] maintains per-chunk records) or in a more "summarized" manner, such as on a per-HAS-session basis (assuming that step [f] summarizes per-chunk records into per-HAS-session records).
このアプローチでは、特にHASに対しては何も行われないため、各HASチャンク配信は、CDNIロギングではスタンドアロンコンテンツ配信と見なされます。特に、HASチャンク配信ごとに個別のログレコードがステップ[e]のCDNI Loggingインターフェースに含まれています（セクション3.4.1で定義）。このアプローチでは、ステップ[a]、[b]、[c]、[d]、および[f]もチャンクごとに実行する必要があります。このアプローチでは、ステップ[g]をチャンクごとに（ステップ[f]がチャンクごとのレコードを維持していると仮定して）、またはHASセッションごとなどのより「要約された」方法で実行できます（ステップ[f]がチャンクごとのレコードをHASセッションごとのレコードに要約すると仮定します）。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o None
o なし
Advantages/Drawbacks:
利点/欠点：
+ No information loss (i.e., all details of each individual chunk delivery are preserved). While this full level of detail may not be needed for some log-consuming applications (e.g., billing), this full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
+ 情報の損失はありません（つまり、個々のチャンク配信のすべての詳細が保持されます）。この完全な詳細レベルは、一部のログを消費するアプリケーション（たとえば、請求）には必要ない場合がありますが、一部のログを消費するアプリケーション（たとえば、デバッグ）には、おそらく価値がある（そしておそらく必要な）可能性があります。
+ Easier integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records
+ 既存のログツールへの統合が（少なくとも短期的には）容易になります。これらのツールはすべてチャンクごとのレコードを処理できるためです。
+ No extension needed on CDNI interfaces
+ CDNIインターフェースでの拡張は不要
- High volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [g] (while summarization in step [f] is conceivable, it may be difficult to achieve in practice without any hints for correlation in the log records)
- ステップ[a]から[g]までのロギングプロセスのすべてのステップで処理される大量のロギング情報（ストレージと処理）（ステップ[f]での要約が考えられますが、実際には、ログレコード内の相関のヒント）
An interesting question is whether a dCDN could use the CDNI Logging interface specified for the "do nothing" approach to report summarized "per-session" log information in the case where the dCDN performs such summarization. The high-level idea would be that when a dCDN performs HAS log summarization, for its own purposes anyway, this dCDN could include in the CDNI Logging interface one or more log entries for a HAS session (instead of one entry per HAS chunk) that summarize the deliveries of many/all HAS chunks for a session. However, the authors feel that when considering the details of this idea, it is not achievable without explicit agreement between the uCDN and dCDN about how to perform/interpret such summarization. For example, when a HAS session switches between representations, the uCDN and dCDN would have to agree on things such as:
興味深い質問は、dCDNが「何もしない」アプローチに指定されたCDNI Loggingインターフェースを使用して、dCDNがそのような要約を実行する場合に、要約された「セッションごとの」ログ情報を報告できるかどうかです。高レベルのアイデアは、dCDNがHASログの要約を実行するときに、いずれにせよ、このdCDNがCDNI LoggingインターフェイスにHASセッションの1つ以上のログエントリを含めることができるということです（HASチャンクごとに1つのエントリではなく）。セッションの多数またはすべてのHASチャンクの配信を要約します。ただし、著者は、このアイデアの詳細を検討するとき、そのような要約を実行/解釈する方法についてuCDNとdCDNの間の明示的な合意なしに達成できないと感じています。たとえば、HASセッションが表現を切り替える場合、uCDNとdCDNは次のような事項について合意する必要があります。
o whether the session will be represented by a single log entry (which therefore cannot convey the distribution across representations), or multiple log entries, such as one entry per contiguous period at a given representation (which therefore would be generally very difficult to correlate back into a single session)
o セッションが単一のログエントリ（したがって、表現間の分布を伝達できない）であるか、複数のログエントリ（特定の表現での連続した期間ごとに1つのエントリなど）で表現されるか（したがって、通常、相互に関連付けることは非常に困難です）単一セッション）
o what the single URI included in the log entry would correspond to (for example, the Manifest File, top-level playlist, or next-level playlist, ...)
o ログエントリに含まれる単一のURIが対応するもの（たとえば、マニフェストファイル、トップレベルのプレイリスト、または次のレベルのプレイリストなど）
The authors feel that since explicit agreement is needed between the uCDN and dCDN on how to perform/interpret the summarization, this method can only work if it is specified as part of the CDNI Logging interface, in which case it would effectively boil down to Option 4.4 (full HAS awareness / per-session logs) as defined below.
著者は、要約を実行/解釈する方法についてuCDNとdCDNの間で明示的な合意が必要であるため、この方法は、CDNIロギングインターフェースの一部として指定されている場合にのみ機能し、その場合、実質的にオプションに要約されると考えています。以下に定義する4.4（完全なHAS認識/セッションごとのログ）。
We note that support by CDNI of a mechanism (independent of HAS) allowing the customization of the fields to be reported in log entries by the dCDN to the uCDN would mitigate concerns related to the scaling of HAS logging, because it ensures that only the necessary subset of fields is actually stored, reported, and processed.
私たちは、CDSがメカニズム（HASとは無関係）をサポートし、dCDNからuCDNへのログエントリでレポートされるフィールドのカスタマイズを許可することで、HASロギングのスケーリングに関連する問題を軽減できることに注意してください。フィールドのサブセットは実際に保存、レポート、処理されます。
In this approach, a "Content Collection IDentifier (CCID)" field is distributed through the CDNI Metadata interface, and the same CCID value is associated through the CDNI Metadata interface with every chunk of the same content collection. The CCID value needs to be such that it allows, in combination with the content URI, unique identification of a content collection. When the CCID is distributed, and CCID logging is requested from the dCDN, the dCDN Surrogates are to store the CCID value in the corresponding log entries. The objective of this field is to facilitate optional summarization of per-chunk records at step [f] into something along the lines of per-HAS-session logs, at least for the log-consuming applications that do not require per-chunk detailed information (for example, billing).
このアプローチでは、「コンテンツコレクションIDentifier（CCID）」フィールドがCDNIメタデータインターフェイスを通じて配布され、同じCCID値がCDNIメタデータインターフェイスを通じて同じコンテンツコレクションのすべてのチャンクに関連付けられます。 CCID値は、コンテンツURIと組み合わせて、コンテンツコレクションの一意の識別を可能にする必要があります。 CCIDが配布され、dCDNからCCIDロギングが要求されると、dCDNサロゲートはCCID値を対応するログエントリに格納します。このフィールドの目的は、ステップ[f]でのチャンクごとのレコードのオプションの要約を、少なくともチャンクごとの詳細情報を必要としないログを消費するアプリケーションのために、HASセッションログごとにまとめることを容易にすることです。 （たとえば、請求）。
We note that if the dCDN happens to have sufficient HAS awareness to be able to generate a "Session IDentifier (Session-ID)", optionally including such a Session-ID (in addition to the CCID) in the per-chunk log record would further facilitate optional summarization at step [f]. The Session-ID value to be included in a log record by the delivering CDN is such that
dCDNがたまたま「セッションIDentifier（Session-ID）」を生成できるように十分なHAS認識を持っている場合、オプションでそのようなセッションID（CCIDに加えて）をチャンクごとのログレコードに含めます。ステップ[f]でのオプションの要約をさらに容易にします。配信するCDNによってログレコードに含まれるセッションIDの値は、
o different per-chunk log records with the same Session-ID value must correspond to the same user session (i.e., delivery of the same content to the same End User at a given point in time).
o 同じSession-ID値を持つ異なるチャンクごとのログレコードは、同じユーザーセッションに対応する必要があります（つまり、特定の時点で同じコンテンツを同じエンドユーザーに配信する）。
o log records for different chunks of the same user session (i.e., delivery of the same content to the same End User at a given point in time) should be provided with the same Session-ID value. While undesirable, there may be situations where the delivering CDN uses more than one Session-ID value for different per-chunk log records of a given session -- for example, in scenarios of fail-over or load balancing across multiple Surrogates and where the delivering CDN does not implement mechanisms to synchronize Session-IDs across Surrogates.
o 同じユーザーセッションのさまざまなチャンクのログレコード（つまり、特定の時点で同じコンテンツを同じエンドユーザーに配信）には、同じSession-ID値を指定する必要があります。望ましくない場合でも、配信するCDNが特定のセッションの異なるチャンクごとのログレコードに複数のSession-ID値を使用する場合があります。たとえば、フェイルオーバーまたは複数のサロゲート間のロードバランシングのシナリオで、 CDNの配信では、サロゲート間でセッションIDを同期するメカニズムは実装されていません。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: One additional metadata field (CCID) in the CDNI Metadata interface. We note that a similar content collection ID is discussed for the handling of other aspects of HAS and observe that further thought is needed to determine whether such a CCID should be shared for multiple purposes or should be independent.
o CDNIメタデータインターフェイス：CDNIメタデータインターフェイスに1つの追加メタデータフィールド（CCID）。 HASの他の側面の処理についても同様のコンテンツコレクションIDが説明されていることに注意し、そのようなCCIDを複数の目的で共有するか、独立させる必要があるかを判断するには、さらに検討が必要です。
o CDNI Logging interface: Two additional fields (CCID and Session-ID) in CDNI logging records.
o CDNIログインターフェイス：CDNIログレコードの2つの追加フィールド（CCIDとセッションID）。
Advantages/Drawbacks:
利点/欠点：
+ No information loss (i.e., all details of each individual chunk delivery are preserved). While this full level of detail may not be needed for some log-consuming applications (e.g., billing), this full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
+ 情報の損失はありません（つまり、個々のチャンク配信のすべての詳細が保持されます）。この完全な詳細レベルは、一部のログを消費するアプリケーション（たとえば、請求）には必要ない場合がありますが、一部のログを消費するアプリケーション（たとえば、デバッグ）には、おそらく価値がある（そしておそらく必要な）可能性があります。
+ Easier integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records
+ 既存のロギングツールへの統合が（少なくとも短期的には）容易になります。これらのツールはすべてチャンクごとのレコードを処理できるためです。
+ Very minor extension to CDNI interfaces needed
+ CDNIインターフェースへの非常にマイナーな拡張が必要
+ Facilitated summarization of records related to a HAS session in step [f] and therefore ability to operate on a lower volume of logging information in step [g] by log-consuming applications that do not need per-chunk record details (e.g., billing) or that need per-session information (e.g., analytics)
+ ステップ[f]でのHASセッションに関連するレコードの要約、したがってチャンクごとのレコードの詳細（請求など）を必要としないログ消費アプリケーションによって、ステップ[g]で少量のロギング情報を操作する機能または、セッションごとの情報が必要な場合（分析など）
- High volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [f]
- ステップ[a]から[f]までのロギングプロセスのすべてのステップで処理（保管および処理）される大量のロギング情報
In this approach, a lossless compression technique is applied to the sets of logging records (e.g., logging files) for transfer on the CDNI Logging interface. The objective of this approach is to reduce the volume of information to be stored and transferred in step [e].
このアプローチでは、CDNIロギングインターフェイスで転送するために、ロスレス圧縮技術がロギングレコード（ロギングファイルなど）のセットに適用されます。このアプローチの目的は、ステップ[e]で保存および転送される情報の量を減らすことです。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o One compression mechanism to be included in the CDNI Logging interface
o CDNI Loggingインターフェイスに含まれる1つの圧縮メカニズム
Advantages/Drawbacks:
利点/欠点：
+ No information loss (i.e., all details of each individual chunk delivery are preserved). While this full level of detail may not be needed for some log-consuming applications (e.g., billing), this full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
+ 情報の損失はありません（つまり、個々のチャンク配信のすべての詳細が保持されます）。この完全な詳細レベルは、一部のログを消費するアプリケーション（たとえば、請求）には必要ない場合がありますが、一部のログを消費するアプリケーション（たとえば、デバッグ）には、おそらく価値がある（そしておそらく必要な）可能性があります。
+ Easier integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records
+ 既存のロギングツールへの統合が（少なくとも短期的には）容易になります。これらのツールはすべてチャンクごとのレコードを処理できるためです。
+ Small extension to CDNI interfaces needed
+ CDNIインターフェースの小さな拡張が必要
+ Reduced volume of logging information in step [e]
+ ステップ[e]でのロギング情報の量の削減
+ Compression likely to also be applicable to logs for non-HAS content
+ 非HASコンテンツのログにも適用される可能性が高い圧縮
- High volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [g], except step [e].
- 手順[e]を除く手順[a]から[g]までのログプロセスのすべての手順で処理される大量のログ情報（保存と処理）。
In this approach, HAS awareness is assumed across the CDNs interconnected via CDNI, and the necessary information to describe the HAS relationship across all chunks of the same content collection is distributed through the CDNI Metadata interface. In this approach, the dCDN leverages the HAS information distributed through the CDNI Metadata and their HAS awareness, to do one of the following:
このアプローチでは、CDNIを介して相互接続されたCDN全体でHAS認識が想定され、同じコンテンツコレクションのすべてのチャンク間でHAS関係を説明するために必要な情報は、CDNIメタデータインターフェースを通じて配布されます。このアプローチでは、dCDNはCDNIメタデータを通じて配布されたHAS情報とそのHAS認識を利用して、次のいずれかを実行します。
o directly generate summarized logging information at logging information generation time (which has the benefit of operating on a lower volume of logging information as early as possible in the successive steps of the logging process), or
o ロギング情報生成時に要約されたロギング情報を直接生成します（これには、ロギングプロセスの後続のステップでできるだけ早い段階で、より少ない量のロギング情報を操作できるという利点があります）。
o (if per-chunk logs are generated) accurately correlate and summarize per-chunk logs into per-session logs for exchange over the CDNI Logging interface
o （チャンクごとのログが生成された場合）チャンクごとのログをセッションごとのログに正確に関連付けて要約し、CDNI Loggingインターフェイスを介して交換する
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: Significant extension to convey HAS relationship across chunks of a content collection. Note that this extension requires specific support for every HAS protocol to be supported over the CDNI mesh
o CDNIメタデータインターフェイス：コンテンツコレクションのチャンク間でHAS関係を伝達するための重要な拡張。この拡張では、CDNIメッシュでサポートされるすべてのHASプロトコルに対して特定のサポートが必要であることに注意してください。
o CDNI Logging interface: Extension to specify summarized per-session logs
o CDNI Loggingインターフェース：セッションごとの要約ログを指定する拡張機能
Advantages/Drawbacks:
利点/欠点：
+ Lower volume of logging information to be handled (storing and processing) at every step of the logging process, from steps [a] to [g]
+ ステップ[a]から[g]までのロギングプロセスのすべてのステップで処理（保管および処理）されるロギング情報の量が少ない
+ Accurate generation of summarized logs because of HAS awareness in the dCDN (for example, where the Surrogate is also serving the Manifest File(s) for a content collection, the Surrogate may be able to extract definitive information about the relationship between all chunks)
+ dCDNでのHAS認識による要約ログの正確な生成（たとえば、サロゲートがコンテンツコレクションのマニフェストファイルも提供している場合、サロゲートはすべてのチャンク間の関係に関する明確な情報を抽出できる場合があります）
- Very significant extensions to CDNI interfaces needed, including specific support for available HAS protocols
- 利用可能なHASプロトコルの特定のサポートを含む、CDNIインターフェイスへの非常に重要な拡張が必要
- Very significant additional requirement for HAS awareness on the dCDN and for this HAS awareness to be consistent with the defined CDNI logging summarization
- dCDNでのHAS認識、およびこのHAS認識が定義済みのCDNIロギング要約と一致するための非常に重要な追加要件
- Some information loss (i.e., all details of each individual chunk delivery are not preserved). The actual information loss depends on the summarization approach selected (typically, the lower the information loss, the lower the summarization gain), so the right "sweet spot" would have to be selected. While a full level of detail may not be needed for some log-consuming applications (e.g., billing), such a full level of detail is likely valuable (and possibly required) for some log-consuming applications (e.g., debugging)
- 一部の情報の損失（つまり、個々のチャンク配信のすべての詳細が保持されない）。実際の情報損失は、選択した要約手法に依存するため（通常、情報損失が少ないほど、要約ゲインが低くなります）、正しい「スイートスポット」を選択する必要があります。一部のログを消費するアプリケーション（たとえば、請求）には完全な詳細レベルが必要ない場合がありますが、そのような完全な詳細レベルは、一部のログを消費するアプリケーション（たとえば、デバッグ）にとって価値がある（そしておそらく必要な）
- Less easy integration (at least in the short term) into existing logging tools, since those tools are all capable of handling per-chunk records but may not be capable of handling CDNI summarized records
- 既存のログツールへの統合は（少なくとも短期的には）容易ではありません。これらのツールはすべてチャンクごとのレコードを処理できますが、CDNI要約レコードを処理できない可能性があるためです。
- Challenges in defining behavior (and achieving summarization gain) in the presence of load balancing of a given HAS session across multiple Surrogates (in the same dCDN or a different dCDN)
- （同じdCDNまたは異なるdCDN内の）複数のサロゲートにわたる特定のHASセッションのロードバランシングが存在する場合の動作の定義（および要約ゲインの達成）における課題
Because of its benefits (in particular simplicity, universal support by CDNs, and support by all log-consuming applications), the authors recommend that per-chunk logging as described in Section 3.4.2.1 (Option 4.1) be supported by the CDNI Logging interface as a "High Priority" (as defined in [CDNI-REQUIREMENTS]) and be a mandatory capability of CDNs implementing CDNI.
その利点（特に、シンプルさ、CDNによるユニバーサルサポート、およびすべてのログを消費するアプリケーションによるサポート）のため、セクション3.4.2.1（オプション4.1）で説明されているチャンクごとのログをCDNIログインターフェイスでサポートすることを推奨します。 「高優先度」（[CDNI-REQUIREMENTS]で定義）として、またCDNIを実装するCDNの必須機能
Because of its very low complexity and its benefits in facilitating some useful scenarios (e.g., per-session analytics), we recommend that the CCID mechanisms and Session-ID mechanism as described in Section 3.4.2.2 (Option 4.2) be supported by the CDNI Metadata interface and the CDNI Logging interface as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs implementing CDNI.
非常に複雑さが低く、いくつかの有用なシナリオ（セッションごとの分析など）を容易にする利点があるため、セクション3.4.2.2（オプション4.2）で説明されているCCIDメカニズムとセッションIDメカニズムをCDNIでサポートすることをお勧めします。メタデータインターフェイスとCDNIログインターフェイスは、[中優先度]（[CDNI-REQUIREMENTS]で定義）として、CDNIを実装するCDNのオプション機能です。
The authors also recommend that
著者らはまた、
(i) the ability of the uCDN to request inclusion of the CCID and Session-ID fields (in log entries provided by the dCDN) be supported by the relevant CDNI interfaces
（i）CCIDおよびSession-IDフィールド（dCDNによって提供されるログエントリ内）の包含を要求するuCDNの機能は、関連するCDNIインターフェイスによってサポートされます。
(ii) the ability of the dCDN to include the CCID and Session-ID fields in CDNI log entries (when the dCDN is capable of doing so) be indicated in the CDNI Logging interface (in line with the "customizable" log format expected to be defined independently of HAS)
（ii）CDNIログエントリにCCIDおよびセッションIDフィールドを含めるdCDNの機能（dCDNがそれを実行できる場合）は、CDNIログインターフェイスに示されます（予期される「カスタマイズ可能な」ログ形式に沿って） HASとは無関係に定義される）
(iii) items (i) and (ii) be supported as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs implementing CDNI
（iii）アイテム（i）および（ii）は「中優先度」（[CDNI-REQUIREMENTS]で定義）としてサポートされ、CDNIを実装するCDNのオプション機能である
When performing dCDN selection, a uCDN may want to take into account whether a given dCDN is capable of reporting the CCID and Session-ID. Thus, the authors recommend that the ability of a dCDN to advertise its support of the optional CCID and Session-ID capability be supported by the CDNI Footprint & Capabilities Advertisement interface as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]).
dCDN選択を実行するとき、uCDNは、特定のdCDNがCCIDおよびセッションIDを報告できるかどうかを考慮に入れたい場合があります。したがって、著者は、オプションのCCIDおよびセッションID機能のサポートをアドバタイズするdCDNの機能が、CDNI Footprint＆Capabilities Advertisementインターフェースによって「中優先度」としてサポートされることを推奨しています（[CDNI-REQUIREMENTS]で定義）。 。
The authors also recommend that a generic mechanism (independent of HAS) be supported that allows the customization of the fields to be reported in logs by CDNs over the CDNI Logging interface -- because of the reduction of the logging information volume exchanged across CDNs that it allows by removing information that is not of interest to the other CDN.
著者はまた、CDNIログインターフェイスを介してCDNによって交換されるログ情報の量が減少するため、フィールドのカスタマイズをCDNIログインターフェイスを介してCDNによってログに報告できるようにする（HASに依存しない）汎用メカニズムをサポートすることを推奨しています他のCDNに関係のない情報を削除することで許可します。
Because the following can be achieved with very little complexity and can provide some clear storage/communication compression benefits, the authors recommend that, in line with the concept of Option 4.3, some existing very common compression techniques (e.g., gzip) be supported by the CDNI Logging interface as a "Medium Priority" (as defined in [CDNI-REQUIREMENTS]) and be an optional capability of CDNs implementing CDNI.
以下は非常に簡単に達成でき、いくつかの明確なストレージ/通信圧縮の利点を提供できるため、著者は、オプション4.3の概念に沿って、既存の非常に一般的な圧縮技術（gzipなど）をサポートすることをお勧めします。 「中優先度」（[CDNI-REQUIREMENTS]で定義）としてのCDNIロギングインターフェイスであり、CDNIを実装するCDNのオプション機能です。
Because of its complexity, the time it would take to understand the trade-offs of candidate summarization approaches, and the time it would take to specify the corresponding support in the CDNI Logging interface, the authors recommend that the log summarization discussed in Section 3.4.2.4 (Option 4.4) not be supported by the CDNI Logging interface at this stage but that it be kept as a candidate topic of great interest for a rechartering of the CDNI WG once the first set of deliverables is produced. At that time, we suggest investigating the notion of complementing a "push style" CDNI Logging interface that would support summarization via an on-demand "pull type" interface that would in turn allow a uCDN to request the subset of the detailed logging information that it may need but that is lost in the summarized pushed information.
その複雑さ、候補要約手法のトレードオフを理解するのにかかる時間、およびCDNI Loggingインターフェースで対応するサポートを指定するのにかかる時間のため、著者はセクション3.4で説明するログの要約を推奨しています。 2.4（オプション4.4）は、この段階ではCDNI Loggingインターフェースでサポートされていませんが、最初の成果物のセットが作成されたら、CDNI WGの再チャーターの大きな関心のある候補トピックとして保持されます。その時点で、オンデマンドの「プルタイプ」インターフェースを介した要約をサポートする「プッシュスタイル」のCDNIロギングインターフェースを補完する概念を調査することをお勧めします。これにより、uCDNが詳細なロギング情報のサブセットを要求できるようになります。必要な場合がありますが、プッシュされた要約情報では失われます。
The authors note that while a CDN only needs to adhere to the CDNI Logging interface on its external interfaces and can perform logging in a different format within the CDN, any possible CDNI logging approach effectively places some constraints on the dCDN logging format. For example, to support the "do nothing" approach, a CDN needs to perform and retain per-chunk logs. As another example, to support the "full HAS awareness/per-session logs" approach, the dCDN cannot use a logging format that summarizes data in a way that is incompatible with the summarization specified for CDNI logging (e.g., summarizes data into a smaller set of information than what is specified for CDNI logging). However, the authors feel that such constraints are (i) inevitable, (ii) outweighed by the benefits of a standardized logging interface, and (iii) acceptable because, in the case of incompatible summarization, most or all CDNs are capable of reverting to per-chunk logging as per the "do nothing" approach that we recommend as the base mandatory approach.
著者は、CDNは外部インターフェースのCDNI Loggingインターフェースに準拠するだけでよく、CDN内で異なるフォーマットでロギングを実行できるが、可能なCDNIロギングアプローチはdCDNロギングフォーマットにいくつかの制約を効果的に課すことに注意します。たとえば、「何もしない」アプローチをサポートするには、CDNがチャンクごとのログを実行して保持する必要があります。別の例として、「完全なHAS認識/セッションごとのログ」アプローチをサポートするために、dCDNは、CDNIログに指定された要約と互換性のない方法でデータを要約するログ形式を使用できません（たとえば、データをより小さなファイルに要約します） CDNIロギングに指定されているものよりも多くの情報。ただし、著者は、そのような制約は（i）避けられない、（ii）標準化されたロギングインターフェイスの利点よりも重要であり、（iii）互換性のない要約の場合、ほとんどまたはすべてのCDNが基本必須アプローチとして推奨する「何もしない」アプローチによるチャンクごとのロギング。
URL signing is an authorization method for content delivery. This is based on embedding the HTTP URL with information that can be validated to ensure that the request has legitimate access to the content. There are two parts: 1) parameters that convey authorization restrictions (e.g., source IP address and time period) and/or a protected URL portion, and 2) a message digest that confirms the integrity of the URL and authenticates the entity that creates the URL. The authorization parameters can be anything agreed upon between the entity that creates the URL and the entity that validates the URL. A key is used to generate the message digest (i.e., sign the URL) and validate the message digest. The two functions may or may not use the same key.
URL署名は、コンテンツ配信の認証方法です。これは、リクエストにコンテンツへの正当なアクセスがあることを確認するために検証できる情報をHTTP URLに埋め込むことに基づいています。 2つの部分があります：1）許可制限（例：送信元IPアドレスと期間）および/または保護されたURL部分を伝えるパラメーター、および2）URLの整合性を確認し、作成するエンティティを認証するメッセージダイジェストURL。許可パラメーターは、URLを作成するエンティティーとURLを検証するエンティティーの間で合意されたものであれば何でもかまいません。キーは、メッセージダイジェストの生成（つまり、URLへの署名）とメッセージダイジェストの検証に使用されます。 2つの機能で同じキーを使用する場合と使用しない場合があります。
There are two types of keys used for URL signing: asymmetric keys and symmetric keys. Asymmetric keys always have a key pair made up of a public key and private key. The private key and public key are used for signing and validating the URL, respectively. A symmetric key is the same key that is used for both functions. Regardless of the type of key, the entity that validates the URL has to obtain the key. Distribution of the symmetric key requires security to prevent others from taking it. A public key can be distributed freely, while a private key is kept by the URL signer. The method for key distribution is out of scope for this document.
URL署名に使用されるキーには、非対称キーと対称キーの2種類があります。非対称鍵には、公開鍵と秘密鍵で構成される鍵ペアが常にあります。秘密鍵と公開鍵は、それぞれURLの署名と検証に使用されます。対称鍵は、両方の機能で使用される同じ鍵です。キーのタイプに関係なく、URLを検証するエンティティはキーを取得する必要があります。対称鍵の配布には、他の人がそれを取得できないようにセキュリティが必要です。公開鍵は自由に配布できますが、秘密鍵はURL署名者が保持します。キー配布の方法は、このドキュメントの範囲外です。
URL signing operates in the following way. A signed URL is provided by the content owner (i.e., URL signer) to the user during website navigation. When the user selects the URL, the HTTP request is sent to the CDN, which validates that URL before delivering the content.
URL署名は次のように動作します。署名付きURLは、Webサイトのナビゲーション中にコンテンツ所有者（URL署名者）からユーザーに提供されます。ユーザーがURLを選択すると、HTTP要求がCDNに送信され、コンテンツを配信する前にそのURLが検証されます。
The authorization lifetime for URL signing is affected by HAS. The expiration time in the authorization parameters of URL signing limits the period that the content referenced by the URL can be accessed. This works for URLs that directly access the media content, but for HAS content the Manifest File contains another layer of URLs that reference the chunks. The chunk URL that is embedded in the content may be requested some undetermined amount of time later. The time period between access to the Manifest File and chunk retrieval may vary significantly. The type of content (i.e., live or VoD) impacts this time variance as well. This property of HAS content needs to be addressed for URL signing.
URL署名の認証ライフタイムはHASの影響を受けます。 URL署名の認証パラメーターの有効期限は、URLによって参照されるコンテンツにアクセスできる期間を制限します。これはメディアコンテンツに直接アクセスするURLで機能しますが、HASコンテンツの場合、マニフェストファイルにはチャンクを参照するURLの別のレイヤーが含まれます。コンテンツに埋め込まれているチャンクURLは、しばらくしてから不確定な時間を要求される場合があります。マニフェストファイルへのアクセスからチャンクの取得までの期間は、大幅に異なる場合があります。コンテンツのタイプ（つまり、ライブまたはVoD）は、この時間変動にも影響します。 HASコンテンツのこのプロパティは、URL署名のためにアドレス指定する必要があります。
For CDNI, the two types of request routing are DNS-based and HTTP-based. The use of symmetric vs. asymmetric keys for URL signing has implications for the trust model between the CSP and CDNs and for the key distribution method that can be used.
CDNIの場合、要求ルーティングの2つのタイプはDNSベースとHTTPベースです。 URL署名に対称キーと非対称キーを使用すると、CSPとCDN間の信頼モデルと、使用できるキー配布方法に影響があります。
DNS-based request routing does not change the URL. In the case of a symmetric key, the CSP and the Authoritative CDN have a business relationship that allows them to share a key (or multiple keys) for URL signing. When the user requests content from the Authoritative CDN, the URL is signed by the CSP. The Authoritative CDN (as a uCDN) redirects the request to a dCDN via DNS. There may be more than one level of redirection to reach the delivering CDN. The user would obtain the IP address from DNS and send the HTTP request to the delivering CDN, which needs to validate the URL. This requires that the key be distributed from the Authoritative CDN to the delivering CDN. This may be problematic when the key is exposed to a delivering CDN that does not have a relationship with the CSP. The combination of DNS-based request routing and symmetric key function is a generic issue for URL signing and not specific to HAS content. In the case of asymmetric keys, the CSP signs the URL with its private key. The delivering CDN validates the URL with the associated public key.
DNSベースの要求ルーティングはURLを変更しません。対称鍵の場合、CSPとAuthoritative CDNには、URL署名用の鍵（または複数の鍵）を共有できるビジネス関係があります。ユーザーがAuthoritative CDNにコンテンツを要求すると、URLはCSPによって署名されます。権限のあるCDN（uCDNとして）は、DNS経由で要求をdCDNにリダイレクトします。配信するCDNに到達するには、複数のレベルのリダイレクトが存在する場合があります。ユーザーはDNSからIPアドレスを取得し、URLを検証する必要がある配信CDNにHTTPリクエストを送信します。これには、権限のあるCDNから配信するCDNにキーを配布する必要があります。これは、キーがCSPと関係のない配信CDNに公開されている場合に問題になる可能性があります。 DNSベースの要求ルーティングと対称キー機能の組み合わせは、URL署名の一般的な問題であり、HASコンテンツに固有のものではありません。非対称キーの場合、CSPは秘密キーでURLに署名します。配信するCDNは、関連付けられた公開鍵でURLを検証します。
HTTP-based request routing changes the URL during the redirection procedure. In the case of a symmetric key, the CSP signs the original URL with the same key used by the Authoritative CDN to validate the URL. The Authoritative CDN (as a uCDN) redirects the request to the dCDN. The new URL is signed by the uCDN with the same key used by the dCDN to validate that URL. The key used by the uCDN to validate the original URL is expected to be different than the key used to sign the new URL. In the case of asymmetric keys, the CSP signs the original URL with its private key. The Authoritative CDN validates that URL with the CSP's public key. The Authoritative CDN redirects the request to the dCDN. The new URL is signed by the uCDN with its private key. The dCDN validates that URL with the uCDN's public key. There may be more than one level of redirection to reach the delivering CDN. The URL signing operation described previously applies at each level between the uCDN and dCDN for both symmetric keys and asymmetric keys.
HTTPベースの要求ルーティングは、リダイレクト手順中にURLを変更します。対称キーの場合、CSPは、Authoritative CDNがURLを検証するために使用したのと同じキーで元のURLに署名します。権限のあるCDN（uCDNとして）は、要求をdCDNにリダイレクトします。新しいURLは、そのURLを検証するためにdCDNが使用するのと同じキーでuCDNによって署名されます。元のURLの検証にuCDNが使用するキーは、新しいURLの署名に使用されるキーとは異なることが期待されています。非対称キーの場合、CSPは元のURLにその秘密キーで署名します。 Authoritative CDNは、CSPの公開鍵を使用してそのURLを検証します。権威あるCDNは要求をdCDNにリダイレクトします。新しいURLは、その秘密鍵を使用してuCDNによって署名されます。 dCDNは、uCDNの公開鍵を使用してそのURLを検証します。配信するCDNに到達するには、複数のレベルのリダイレクトが存在する場合があります。前述のURL署名操作は、対称鍵と非対称鍵の両方のuCDNとdCDNの間の各レベルに適用されます。
URL signing requires support in most of the CDNI interfaces. The CDNI Metadata interface should specify the content that is subject to URL signing and provide information to perform the function. The dCDN should inform the uCDN that it supports URL signing in the asynchronous capabilities information advertisement as part of the Request Routing interface. This allows the CDN selection function in request routing to choose the dCDN with URL signing capability when the CDNI Metadata of the content requires this authorization method. The logging interface provides information on the authorization method (e.g., URL signing) and related authorization parameters used for content delivery. Having the information in the URL is not sufficient to know that the Surrogate enforced the authorization. URL signing has no impact on the control interface.
URL署名には、ほとんどのCDNIインターフェイスでのサポートが必要です。 CDNIメタデータインターフェイスは、URL署名の対象となるコンテンツを指定し、機能を実行するための情報を提供する必要があります。 dCDNは、要求ルーティングインターフェイスの一部として非同期機能情報アドバタイズメントでのURL署名をサポートすることをuCDNに通知する必要があります。これにより、コンテンツのCDNIメタデータでこの認証方法が必要な場合に、リクエストルーティングのCDN選択機能でURL署名機能付きのdCDNを選択できます。ロギングインターフェースは、コンテンツ配信に使用される認証方法（URL署名など）および関連する認証パラメーターに関する情報を提供します。 URLに情報が含まれていても、サロゲートが承認を実施したことを知るには十分ではありません。 URL署名は、コントロールインターフェイスに影響を与えません。
This approach means that the CSP can only perform URL signing for the top-level Manifest File. The top-level Manifest File contains chunk URLs or lower-level Manifest File URLs, which are not modified (i.e., no URL signing for the embedded URLs). In essence, the lower-level Manifest Files and chunks are delivered without content access authorization.
このアプローチは、CSPがトップレベルのマニフェストファイルに対してのみURL署名を実行できることを意味します。最上位のマニフェストファイルにはチャンクURLまたは下位レベルのマニフェストファイルURLが含まれ、これらは変更されません（つまり、埋め込まれたURLのURL署名はありません）。本質的に、下位レベルのマニフェストファイルとチャンクは、コンテンツアクセス許可なしで配信されます。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o None
o なし
Advantages/Drawbacks:
利点/欠点：
+ Top-level Manifest File access is protected
+ トップレベルのマニフェストファイルアクセスは保護されています
+ The uCDN and dCDN do not need to be aware of HAS content
+ uCDNとdCDNはHASコンテンツを認識する必要はありません
- Lower-level Manifest Files and chunks are not protected, making this approach unqualified for content access authorization
- 下位レベルのマニフェストファイルとチャンクは保護されていないため、このアプローチはコンテンツアクセス認証の対象外です
In addition to URL signing for the top-level Manifest File, the CSP performs flexible URL signing for the lower-level Manifest Files and chunks. For each HAS session, the top-level Manifest File contains signed chunk URLs or signed lower-level Manifest File URLs for the specific session. The lower-level Manifest File contains session-based signed chunk URLs. The CSP generates the Manifest Files dynamically for the session. The chunk (segment/fragment) is delivered with content access authorization using flexible URL signing, which protects the invariant portion of the URL. A "segment" URL (e.g., HLS) is individually signed for the invariant URL portion (relative URL) or the entire URL (absolute URL without redirection) in the Manifest File. A "fragment" URL (e.g., HTTP Smooth Streaming) is signed for the invariant portion of the template URL in the Manifest File. More details are provided later in this section. The URL signing expiration time for the chunk needs to be long enough to play the video. There are implications related to signing the URLs in the Manifest File. For live content, the Manifest Files are requested at a high frequency. For VoD content, the Manifest File may be quite large. URL signing can add more computational load and delivery latency in high-volume cases.
CSPは、最上位のマニフェストファイルのURL署名に加えて、下位レベルのマニフェストファイルとチャンクに対して柔軟なURL署名を実行します。 HASセッションごとに、最上位のマニフェストファイルには、特定のセッションの署名されたチャンクURLまたは署名された下位レベルのマニフェストファイルURLが含まれています。下位レベルのマニフェストファイルには、セッションベースの署名済みチャンクURLが含まれています。 CSPは、セッションのマニフェストファイルを動的に生成します。チャンク（セグメント/フラグメント）は、URLの不変部分を保護する柔軟なURL署名を使用したコンテンツアクセス認証で配信されます。 「セグメント」URL（HLSなど）は、マニフェストファイルの不変URL部分（相対URL）またはURL全体（リダイレクトなしの絶対URL）に対して個別に署名されます。 「フラグメント」URL（例：HTTP Smooth Streaming）は、マニフェストファイルのテンプレートURLの不変部分に署名されます。詳細については、このセクションの後半で説明します。チャンクのURL署名の有効期限は、ビデオを再生するのに十分な長さである必要があります。マニフェストファイルのURLへの署名に関連する影響があります。ライブコンテンツの場合、マニフェストファイルは高い頻度で要求されます。 VoDコンテンツの場合、マニフェストファイルは非常に大きくなる可能性があります。大量の場合、URL署名により、計算負荷と配信レイテンシが増える可能性があります。
For HAS content, the Manifest File contains the relative URL, absolute URL without redirection, or absolute URL with redirection for specifying the chunk location. Signing the chunk URL requires that the CSP know the portion of the URL that remains when the content is requested from the delivering CDN Surrogate.
HASコンテンツの場合、マニフェストファイルには、相対URL、リダイレクトのない絶対URL、またはチャンクの場所を指定するためのリダイレクトのある絶対URLが含まれます。チャンクURLに署名するには、配信するCDNサロゲートからコンテンツが要求されたときに残るURLの部分をCSPが知っている必要があります。
For absolute URLs without redirection, the CSP knows that the chunk URL is explicitly linked with the delivering CDN Surrogate and can sign the URL based on that information. Since the entire URL is set and does not change, the Surrogate can validate the URL. The CSP and the delivering CDN are expected to have a business relationship in this case, and so either symmetric keys or asymmetric keys can be used for URL signing.
リダイレクトのない絶対URLの場合、CSPはチャンクURLが配信CDNサロゲートに明示的にリンクされていることを認識しており、その情報に基づいてURLに署名できます。 URL全体が設定され、変更されないため、サロゲートはURLを検証できます。この場合、CSPと配信するCDNにはビジネス上の関係があることが予想されるため、対称キーまたは非対称キーのいずれかをURL署名に使用できます。
For relative URLs, the URL of the Manifest File provides the root location. The method of request routing affects the URL used to ultimately request the chunk from the delivering CDN Surrogate. For DNS, the original URL does not change. This allows the CSP to sign the chunk URL based on the Manifest File URL and the relative URL. For HTTP, the URL changes during redirection. In this case, the CSP does not know the redirected URL that will be used to request the Manifest File. This uncertainty makes it impossible to accurately sign the chunk URLs in the Manifest File. Basically, URL signing using this reference method "as is" for protection of the entire URL is not supported. However, instead of signing the entire URL, the CSP signs the relative URL (i.e., the invariant portion of the URL) and conveys the protected portion in the authorization parameters embedded in the chunk URL. This approach works in the same way as absolute URLs without redirection, except that the HOST part and (part of) the PATH part of the URL are not signed and validated. The security level should remain the same, as content access authorization ensures that the user that requested the content has the proper credentials. This scheme does not seem to compromise the authorization model, since the resource is still protected by the authorization parameters and message digest. Further evaluation of security might be helpful.
相対URLの場合、マニフェストファイルのURLがルートの場所を提供します。リクエストルーティングの方法は、配信するCDNサロゲートからチャンクを最終的にリクエストするために使用されるURLに影響します。 DNSの場合、元のURLは変更されません。これにより、CSPは、マニフェストファイルURLおよび相対URLに基づいてチャンクURLに署名できます。 HTTPの場合、URLはリダイレクト中に変更されます。この場合、CSPは、マニフェストファイルを要求するために使用されるリダイレクトされたURLを認識していません。この不確実性により、マニフェストファイル内のチャンクURLに正確に署名することが不可能になります。基本的に、この参照方法をそのまま使用してURL全体を保護するURL署名はサポートされていません。ただし、CSPはURL全体に署名する代わりに、相対URL（つまり、URLの不変部分）に署名し、保護された部分をチャンクURLに埋め込まれた認証パラメーターで伝えます。このアプローチは、リダイレクトのない絶対URLと同じように機能しますが、URLのHOST部分とPATH部分（の一部）が署名および検証されない点が異なります。コンテンツアクセス許可により、コンテンツを要求したユーザーが適切な資格情報を持つことが保証されるため、セキュリティレベルは同じままにする必要があります。リソースは依然として認証パラメーターとメッセージダイジェストによって保護されているため、このスキームは認証モデルを危険にさらしているようには見えません。セキュリティをさらに評価すると役立つ場合があります。
For absolute URLs with redirection, the method of request routing affects the URL used to ultimately request the chunk from the delivering CDN Surrogate. This case has the same conditions as those indicated above for the relative URL. The difference is that the URL is for the chunk instead of the Manifest File. For DNS, the chunk URL does not change and can be signed by the CSP. For HTTP, the URL used to deliver the chunk is unknown to the CSP. In this case, the CSP cannot sign the URL, and this method of reference for the chunk is not supported.
リダイレクトを伴う絶対URLの場合、リクエストルーティングの方法は、配信するCDNサロゲートに最終的にチャンクをリクエストするために使用されるURLに影響します。この場合の条件は、相対URLについて上記で示したものと同じです。違いは、URLがマニフェストファイルではなくチャンク用であることです。 DNSの場合、チャンクURLは変更されず、CSPによって署名できます。 HTTPの場合、チャンクの配信に使用されるURLはCSPには不明です。この場合、CSPはURLに署名できず、このチャンクの参照方法はサポートされていません。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o Requires the ability to exclude the variant portion of the URL in the signing process. (NOTE: Is this issue specific to URL signing support for HAS content and not CDNI?)
o 署名プロセスでURLのバリアント部分を除外する機能が必要です。 （注：この問題は、HASコンテンツのURL署名サポートに固有のものであり、CDNIに固有のものではありませんか？）
Advantages/Drawbacks:
利点/欠点：
+ The Manifest File and chunks are protected
+ マニフェストファイルとチャンクは保護されています
+ The uCDN and dCDN do not need to be aware of HAS content
+ uCDNとdCDNはHASコンテンツを認識する必要はありません
+ DNS-based request routing with asymmetric keys and HTTP-based request routing for relative URLs and absolute URLs without redirection work
+ 非対称キーを使用したDNSベースの要求ルーティング、およびリダイレクト作業なしの相対URLと絶対URLのHTTPベースの要求ルーティング
- The CSP has to generate Manifest Files with session-based signed URLs and becomes involved in content access authorization for every HAS session
- CSPはセッションベースの署名付きURLでマニフェストファイルを生成する必要があり、すべてのHASセッションのコンテンツアクセス認証に関与する必要があります
- Manifest Files are not cacheable
- マニフェストファイルはキャッシュできません
- DNS-based request routing with symmetric keys may be problematic due to the need for transitive trust between the CSP and delivering CDN
- 対称キーを使用したDNSベースの要求ルーティングは、CSPと配信CDNの間の推移的な信頼が必要であるため、問題が発生する可能性があります
- HTTP-based request routing for absolute URLs with redirection does not work, because the URL used by the delivering CDN Surrogate is unknown to the CSP
- 配信するCDNサロゲートが使用するURLがCSPに認識されないため、リダイレクトを伴う絶対URLのHTTPベースのリクエストルーティングは機能しません。
This is similar to the previous section, with the exception that the uCDN performs flexible URL signing for the lower-level Manifest Files and chunks. URL signing for the top-level Manifest File is still provided by the CSP.
これは前のセクションと似ていますが、uCDNが下位レベルのマニフェストファイルとチャンクに対して柔軟なURL署名を実行する点が異なります。トップレベルのマニフェストファイルのURL署名は、引き続きCSPによって提供されます。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o Requires the ability to exclude the variant portion of the URL in the signing process. (NOTE: Is this issue specific to URL signing support for HAS content and not CDNI?)
o 署名プロセスでURLのバリアント部分を除外する機能が必要です。 （注：この問題は、HASコンテンツのURL署名サポートに固有のものであり、CDNIに固有のものではありませんか？）
Advantages/Drawbacks:
利点/欠点：
+ The Manifest File and chunks are protected
+ マニフェストファイルとチャンクは保護されています
+ The CSP does not need to be involved in content access authorization for every HAS session
+ CSPは、すべてのHASセッションのコンテンツアクセス許可に関与する必要はありません
+ The dCDN does not need to be aware of HAS content
+ dCDNはHASコンテンツを認識する必要はありません
+ DNS-based request routing with asymmetric keys and HTTP-based request routing for relative URLs and absolute URLs without redirection work
+ 非対称キーを使用したDNSベースの要求ルーティング、およびリダイレクト作業なしの相対URLと絶対URLのHTTPベースの要求ルーティング
- The uCDN has to generate Manifest Files with session-based signed URLs and becomes involved in content access authorization for every HAS session
- uCDNは、セッションベースの署名付きURLでマニフェストファイルを生成する必要があり、すべてのHASセッションのコンテンツアクセス許可に関与する必要があります
- Manifest Files are not cacheable
- マニフェストファイルはキャッシュできません
- The Manifest File needs to be distributed through the uCDN
- マニフェストファイルはuCDNを通じて配布する必要があります
- DNS-based request routing with symmetric keys may be problematic due to the need for transitive trust between the uCDN and non-adjacent delivering CDN
- 対称キーを使用したDNSベースの要求ルーティングは、uCDNと隣接していない配信CDNの間の推移的な信頼が必要であるため、問題が発生する可能性があります
- HTTP-based request routing for absolute URLs with redirection does not work, because the URL used by the delivering CDN Surrogate is unknown to the uCDN
- 配信するCDNサロゲートが使用するURLがuCDNに認識されていないため、リダイレクトを伴う絶対URLのHTTPベースのリクエストルーティングは機能しません
Based on the Authorization Group ID metadata, the CDN validates the URL signing or validates the HTTP cookie for request of content in the group. The CSP performs URL signing for the top-level Manifest File. The top-level Manifest File contains lower-level Manifest File URLs or chunk URLs. The lower-level Manifest Files and chunks are delivered with content access authorization using an HTTP cookie that contains session state associated with authorization of the top-level Manifest File. The Group ID metadata is used to associate the related content (i.e., Manifest Files and chunks). It also specifies content (e.g., regexp method) that needs to be validated by either URL signing or an HTTP cookie. Note that the creator of the metadata is HAS aware. The duration of the chunk access may be included in the URL signing of the top-level Manifest File and set in the cookie. Alternatively, the access control duration could be provided by the CDNI Metadata interface.
承認グループIDメタデータに基づいて、CDNはURL署名を検証するか、グループ内のコンテンツの要求に対するHTTP Cookieを検証します。 CSPは、最上位のマニフェストファイルのURL署名を実行します。トップレベルのマニフェストファイルには、下位レベルのマニフェストファイルのURLまたはチャンクURLが含まれています。下位レベルのマニフェストファイルとチャンクは、最上位レベルのマニフェストファイルの承認に関連付けられたセッション状態を含むHTTP Cookieを使用したコンテンツアクセス承認で配信されます。グループIDメタデータは、関連するコンテンツ（つまり、マニフェストファイルとチャンク）を関連付けるために使用されます。また、URL署名またはHTTP Cookieのいずれかで検証する必要があるコンテンツ（regexpメソッドなど）も指定します。メタデータの作成者はHASを認識していることに注意してください。チャンクアクセスの期間は、最上位のマニフェストファイルのURL署名に含まれ、Cookieに設定されます。あるいは、アクセス制御期間は、CDNIメタデータインターフェースによって提供できます。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: Authorization Group ID metadata identifies the content that is subject to validation of URL signing or validation of an HTTP cookie associated with the URL signing
o CDNIメタデータインターフェイス：承認グループIDメタデータは、URL署名の検証またはURL署名に関連付けられたHTTP Cookieの検証の対象となるコンテンツを識別します
o CDNI Logging interface: Report the authorization method used to validate the request for content delivery
o CDNI Loggingインターフェース：コンテンツ配信のリクエストを検証するために使用される認証方法を報告します
Advantages/Drawbacks:
利点/欠点：
+ The Manifest File and chunks are protected
+ マニフェストファイルとチャンクは保護されています
+ The CDN does not need to be aware of HAS content
+ CDNはHASコンテンツを認識する必要はありません
+ The CSP does not need to change the Manifest Files
+ CSPはマニフェストファイルを変更する必要はありません
- Authorization Group ID metadata is required (i.e., CDNI Metadata interface enhancement)
- 許可グループIDメタデータが必要です（つまり、CDNIメタデータインターフェースの機能強化）
- Requires the use of an HTTP cookie, which may not be acceptable in some environments (e.g., where some targeted User Agents do not support HTTP cookies)
- HTTP Cookieの使用が必要です。これは、一部の環境（たとえば、一部のターゲットユーザーエージェントがHTTP Cookieをサポートしていない環境）では受け入れられない場合があります。
- The Manifest File has to be delivered by the Surrogate
- マニフェストファイルはサロゲートによって配信される必要があります
The CDN is aware of HAS content and uses URL signing and HTTP cookies for content access authorization. URL signing is fundamentally about authorizing access to a content item or its specific content collections (representations) for a specific user during a time period, possibly also using some other criteria. A chunk is an instance of the sets of chunks referenced by the Manifest File for the content item or its specific content collections. This relationship means that once the dCDN has authorized the Manifest File, it can assume that the associated chunks are implicitly authorized. The new function for the CDN is to link the Manifest File with the chunks for the HTTP session. This can be accomplished by using an HTTP cookie for the HAS session.
CDNはHASコンテンツを認識し、コンテンツへのアクセスの承認にURL署名とHTTP Cookieを使用します。 URL署名は、基本的に、特定のユーザーが特定の期間中にコンテンツアイテムまたはその特定のコンテンツコレクション（表現）へのアクセスを承認することです。チャンクは、コンテンツアイテムまたはその特定のコンテンツコレクションのマニフェストファイルによって参照されるチャンクのセットのインスタンスです。この関係は、dCDNがマニフェストファイルを承認すると、関連するチャンクが暗黙的に承認されると想定できることを意味します。 CDNの新しい機能は、マニフェストファイルをHTTPセッションのチャンクにリンクすることです。これは、HASセッションにHTTP Cookieを使用することで実現できます。
After validating the URL and detecting that the requested content is a top-level Manifest File, the delivering CDN Surrogate sets an HTTP cookie with a signed session token for the HTTP session. When a request for a lower-level Manifest File or chunk arrives, the Surrogate confirms that the HTTP cookie value contains the correct session token. If so, the lower-level Manifest File or chunk is delivered in accordance with the transitive authorization mechanism. The duration of the chunk access may be included in the URL signing of the top-level Manifest File and set in the cookie. The details of the operation are left to be determined later.
URLを検証し、要求されたコンテンツが最上位のマニフェストファイルであることを検出すると、配信するCDNサロゲートは、HTTPセッションの署名付きセッショントークンを使用してHTTP Cookieを設定します。下位レベルのマニフェストファイルまたはチャンクのリクエストが到着すると、サロゲートはHTTP Cookie値に正しいセッショントークンが含まれていることを確認します。その場合、下位レベルのマニフェストファイルまたはチャンクは、推移的承認メカニズムに従って配信されます。チャンクアクセスの期間は、最上位のマニフェストファイルのURL署名に含まれ、Cookieに設定されます。動作の詳細は後日決定します。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: New metadata identifies the content that is subject to validation of URL signing and information in the cookie for the type of HAS content
o CDNIメタデータインターフェース：新しいメタデータは、URL署名の検証の対象となるコンテンツと、HASコンテンツのタイプのCookie内の情報を識別します
o Request Routing interface: The dCDN should inform the uCDN that it supports URL signing for known HAS content types in the asynchronous capabilities information advertisement. This allows the CDN selection function in request routing to choose the appropriate dCDN when the CDNI Metadata identifies the content
o 要求ルーティングインターフェイス：dCDNは、非同期機能情報アドバタイズメントで既知のHASコンテンツタイプのURL署名をサポートすることをuCDNに通知する必要があります。これにより、CDNIメタデータがコンテンツを識別したときに、要求ルーティングのCDN選択機能が適切なdCDNを選択できるようになります
o CDNI Logging interface: Report the authorization method used to validate the request for content delivery
o CDNI Loggingインターフェース：コンテンツ配信のリクエストを検証するために使用される認証方法を報告します
Advantages/Drawbacks:
利点/欠点：
+ The Manifest File and chunks are protected
+ マニフェストファイルとチャンクは保護されています
+ The CSP does not need to change the Manifest Files
+ CSPはマニフェストファイルを変更する必要はありません
- Requires full HAS awareness on the part of the uCDN and dCDN
- uCDNおよびdCDNの側で完全なHAS認識が必要
- Requires extensions to CDNI interfaces
- CDNIインターフェースの拡張が必要
- Requires the use of an HTTP cookie, which may not be acceptable in some environments (e.g., where some targeted User Agents do not support HTTP cookies)
- HTTP Cookieの使用が必要です。これは、一部の環境（たとえば、一部のターゲットユーザーエージェントがHTTP Cookieをサポートしていない環境）では受け入れられない場合があります。
- The Manifest File has to be delivered by the Surrogate
- マニフェストファイルはサロゲートによって配信される必要があります
The CDN is aware of HAS content and uses URL signing for content access authorization of Manifest Files and chunks. The CDN generates or rewrites the Manifest Files and learns about the chunks based on the Manifest File. The embedded URLs in the Manifest File are signed by the CDN. The duration of the chunk access may be included in the URL signing. The details of the operation are left to be determined later. Since this approach is based on signing the URLs in the Manifest File, the implications for live and VoD content mentioned in Section 3.5.4 apply.
CDNはHASコンテンツを認識し、マニフェストファイルとチャンクのコンテンツアクセス認証にURL署名を使用します。 CDNはマニフェストファイルを生成または書き換え、マニフェストファイルに基づいてチャンクについて学習します。マニフェストファイルに埋め込まれたURLは、CDNによって署名されます。チャンクアクセスの期間は、URL署名に含まれる場合があります。動作の詳細は後日決定します。このアプローチはマニフェストファイルのURLへの署名に基づいているため、セクション3.5.4で述べたライブコンテンツとVoDコンテンツへの影響が適用されます。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: New metadata identifies the content that is subject to validation of URL signing and information in the cookie for the type of HAS content
o CDNIメタデータインターフェース：新しいメタデータは、URL署名の検証の対象となるコンテンツと、HASコンテンツのタイプのCookie内の情報を識別します
o Request Routing interface: The dCDN should inform the uCDN that it supports URL signing for known HAS content types in the asynchronous capabilities information advertisement. This allows the CDN selection function in request routing to choose the appropriate dCDN when the CDNI Metadata identifies the content
o 要求ルーティングインターフェイス：dCDNは、非同期機能情報アドバタイズメントで既知のHASコンテンツタイプのURL署名をサポートすることをuCDNに通知する必要があります。これにより、CDNIメタデータがコンテンツを識別したときに、要求ルーティングのCDN選択機能が適切なdCDNを選択できるようになります
o CDNI Logging interface: Report the authorization method used to validate the request for content delivery
o CDNI Loggingインターフェース：コンテンツ配信のリクエストを検証するために使用される認証方法を報告します
Advantages/Drawbacks:
利点/欠点：
+ The Manifest File and chunks are protected
+ マニフェストファイルとチャンクは保護されています
+ The CSP does not need to change the Manifest Files
+ CSPはマニフェストファイルを変更する必要はありません
- Requires full HAS awareness on the part of the uCDN and dCDN
- uCDNおよびdCDNの側で完全なHAS認識が必要
- Requires extensions to CDNI interfaces
- CDNIインターフェースの拡張が必要
- Requires the CDN to generate or rewrite the Manifest File
- マニフェストファイルを生成または書き換えるにはCDNが必要
- The Manifest File has to be delivered by the Surrogate
- マニフェストファイルはサロゲートによって配信される必要があります
The authors consider Option 5.1 (do nothing) unsuitable for access control of HAS content.
著者は、オプション5.1（何もしない）はHASコンテンツのアクセス制御には適さないと考えています。
Where the HTTP cookie mechanism is supported by the targeted User Agents and the security requirements can be addressed through the proper use of HTTP cookies, the authors recommend using Option 5.4 (Authorization Group ID and HTTP cookie) and therefore that Option 5.4 be supported by the CDNI solution. This method does not require Manifest File manipulation, as Manifest File manipulation may be a significant obstacle to deployment. Otherwise, the authors recommend that Option 5.2 (flexible URL signing by the CSP) or Option 5.3 (flexible URL signing by the uCDN) be used and therefore that flexible URL signing be supported by the CDNI solution. Options 5.2 and 5.3 protect all the content, do not require that the dCDN be aware of HAS, do not impact CDNI interfaces, support all different types of devices, and support the common cases of request routing for HAS content (i.e., DNS-based request routing with asymmetric keys and HTTP-based request routing for relative URLs).
HTTP Cookieメカニズムが対象のユーザーエージェントによってサポートされており、セキュリティ要件がHTTP Cookieの適切な使用を通じて対処できる場合、著者はオプション5.4（承認グループIDとHTTP Cookie）の使用を推奨し、したがってオプション5.4はCDNIソリューション。この方法では、マニフェストファイルの操作がデプロイメントの大きな障害になる可能性があるため、マニフェストファイルの操作は必要ありません。それ以外の場合、著者は、オプション5.2（CSPによる柔軟なURL署名）またはオプション5.3（uCDNによる柔軟なURL署名）を使用することをお勧めします。したがって、柔軟なURL署名はCDNIソリューションでサポートされます。オプション5.2および5.3はすべてのコンテンツを保護し、dCDNがHASを認識している必要はなく、CDNIインターフェイスに影響を与えず、すべての異なるタイプのデバイスをサポートし、HASコンテンツのリクエストルーティングの一般的なケースをサポートします（つまり、DNSベースの非対称キーを使用したリクエストルーティングと相対URLのHTTPベースのリクエストルーティング）。
Options 5.5 and 5.6 (HAS awareness in CDNs using HTTP cookies or Manifest Files) have some advantages that should be considered for future support (e.g., a CDN that is aware of HAS content can manage the content more efficiently in a broader context). Content distribution, storage, delivery, deletion, access authorization, etc. can all benefit. Including HAS awareness as part of the current CDNI charter, however, would almost certainly delay the CDNI WG's milestones, and the authors therefore do not recommend it right now.
オプション5.5および5.6（HTTP Cookieまたはマニフェストファイルを使用するCDNでのHAS認識）には、将来のサポートのために考慮すべきいくつかの利点があります（たとえば、HASコンテンツを認識するCDNは、より広いコンテキストでコンテンツをより効率的に管理できます）。コンテンツの配布、保存、配信、削除、アクセス許可など、すべてにメリットがあります。ただし、現在のCDNI憲章の一部としてHAS認識を含めることは、ほぼ確実にCDNI WGのマイルストーンを遅らせることになるため、著者は現時点でそれを推奨しません。
At some point in time, a uCDN might want to remove content from a dCDN. With regular content, this process can be relatively straightforward; a uCDN will typically send the request for content removal to the dCDN, including a reference to the content that it wants to remove (e.g., in the form of a URL). However, due to the fact that HAS content consists of large groups of files, things might be more complex. Section 3.1 described a number of different scenarios for doing file management on these groups of files, while Section 3.2 listed the options for performing content acquisition on these content collections. This section presents the options for requesting a content purge for the removal of a content collection from a dCDN.
ある時点で、uCDNはdCDNからコンテンツを削除したい場合があります。通常のコンテンツでは、このプロセスは比較的簡単です。 uCDNは通常、削除したいコンテンツへの参照を含めて、コンテンツの削除リクエストをdCDNに送信します（たとえば、URLの形式で）。ただし、HASのコンテンツはファイルの大きなグループで構成されているため、状況はさらに複雑になる可能性があります。セクション3.1では、これらのファイルグループでファイル管理を行うためのさまざまなシナリオについて説明し、セクション3.2では、これらのコンテンツコレクションでコンテンツ取得を実行するためのオプションを示しました。このセクションでは、dCDNからコンテンツコレクションを削除するためにコンテンツのパージを要求するためのオプションを示します。
The most straightforward way to signal content purge requests is to just send a single purge request for every file that makes up the content collection. While this method is very simple and does not require HAS awareness, it obviously creates signaling overhead between the uCDN and dCDN, since a reference is to be provided for each content chunk to be purged.
コンテンツパージリクエストを通知する最も簡単な方法は、コンテンツコレクションを構成するすべてのファイルに対して単一のパージリクエストを送信することです。この方法は非常にシンプルで、HAS認識を必要としませんが、パージされるコンテンツチャンクごとに参照が提供されるため、uCDNとdCDN間のシグナリングオーバーヘッドが明らかに発生します。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o None
o なし
Advantages/Drawbacks (apart from those already listed under Option 3.3):
利点/欠点（オプション3.3ですでにリストされているものを除く）：
+ Does not require changes to the CDNI interfaces or HAS awareness
+ CDNIインターフェースの変更やHAS認識は不要
- Requires individual purge request for every file making up a content collection (or, alternatively, requires the ability to convey references to all the chunks making up a content collection inside a purge request), which creates signaling overhead
- コンテンツコレクションを構成するすべてのファイルに対して個別のパージ要求が必要です（または、パージ要求内のコンテンツコレクションを構成するすべてのチャンクへの参照を伝達する機能が必要です）。これにより、シグナリングオーバーヘッドが発生します。
There exists a potentially more efficient method for performing content removal of large numbers of files simultaneously. By including a "Purge IDentifier (Purge-ID)" in the metadata of a particular file, it is possible to virtually group together different files making up a content collection. A Purge-ID can take the form of an arbitrary number or string that is communicated as part of the CDNI Metadata interface, and that is the same for all files making up a particular content item but different across different content items. If a uCDN wants to request that the dCDN remove a content collection, it can send a purge request containing this Purge-ID. The dCDN can then remove all files that share the corresponding Purge-ID.
多数のファイルのコンテンツ削除を同時に実行するための、より効率的な方法が潜在的に存在します。特定のファイルのメタデータに「パージIDentifier（パージID）」を含めることにより、コンテンツコレクションを構成するさまざまなファイルを仮想的にグループ化することができます。パージIDは、CDNIメタデータインターフェイスの一部として通信される任意の数値または文字列の形式を取ることができ、特定のコンテンツアイテムを構成するすべてのファイルで同じですが、コンテンツアイテムによって異なります。 uCDNがdCDNにコンテンツコレクションの削除を要求する場合は、このPurge-IDを含むパージ要求を送信できます。次に、dCDNは、対応するパージIDを共有するすべてのファイルを削除できます。
The advantage of this method is that it is relatively simple to use by both the dCDN and uCDN and requires only limited additions to the CDNI Metadata interface and CDNI Control interface.
この方法の利点は、dCDNとuCDNの両方で使用するのが比較的簡単で、CDNIメタデータインターフェイスとCDNIコントロールインターフェイスへの追加が制限されていることだけです。
The Purge-ID is similar to the CCID discussed in Section 3.4.2.2 for handling HAS logging, and we note that further thought is needed to determine whether the CCID and Purge-ID should be collapsed into a single element or remain separate elements.
Purge-IDは、HASロギングを処理するためにセクション3.4.2.2で説明したCCIDに類似しており、CCIDとPurge-IDを単一の要素に集約するか、別の要素のままにするかを決定するには、さらに検討が必要です。
Effect on CDNI interfaces:
CDNIインターフェイスへの影響：
o CDNI Metadata interface: Add metadata field for indicating Purge-ID
o CDNIメタデータインターフェース：パージIDを示すメタデータフィールドを追加
o CDNI Control interface: Add functionality to convey a Purge-ID in purge requests
o CDNI制御インターフェース：パージ要求でパージIDを伝達する機能を追加
Advantages/Drawbacks:
利点/欠点：
+ Allows for efficient purging of content from a dCDN
+ dCDNからのコンテンツの効率的なパージが可能
+ Does not require HAS awareness on the part of a dCDN
+ dCDNの側でHAS認識を必要としません
Based on the listed pros and cons, the authors recommend that the WG have mandatory support for Option 1.1 (do nothing). In addition, because of its very low complexity and its benefit in facilitating low-overhead purge of large numbers of content items simultaneously, the authors recommend that Purge-IDs (Option 6.2; see Section 3.6.2) be supported as an optional feature by the CDNI Metadata interface and the CDNI Control interface.
リストされた長所と短所に基づいて、作成者はWGがオプション1.1を強制的にサポートすることを推奨します（何もしない）。さらに、非常に複雑さが少なく、同時に多数のコンテンツアイテムを低オーバーヘッドでパージできるというメリットがあるため、著者は、Purge-ID（オプション6.2、セクション3.6.2を参照）をオプション機能としてサポートすることを推奨しています。 CDNIメタデータインターフェイスとCDNIコントロールインターフェイス。
This section includes some HAS-specific issues that came up during the discussion of this document and that do not fall under any of the categories discussed in the previous sections.
このセクションには、このドキュメントの説明中に発生し、前のセクションで説明したカテゴリのいずれにも該当しないHAS固有の問題がいくつか含まれています。
- As described in Section 2.2, a Manifest File might be delivered by either a CDN or the CSP and thereby be invisible to the CDN delivering the chunks. Obviously, the decision of whether the CDN or CSP delivers the Manifest File is made between the uCDN and CSP, and the dCDN has no choice in the matter. However, some dCDNs might only want to offer their services in the cases where they have access to the Manifest File (e.g., because their internal architecture is based on the knowledge inside the Manifest File). For these cases, it might be useful to include a field in the CDNI Capability Advertisement to allow dCDNs to advertise the fact that they require access to the Manifest File.
- セクション2.2で説明したように、マニフェストファイルはCDNまたはCSPのいずれかによって配信されるため、チャンクを配信するCDNからは見えません。明らかに、CDNとCSPのどちらがマニフェストファイルを配信するかの決定は、uCDNとCSPの間で行われ、dCDNには問題の選択肢がありません。ただし、一部のdCDNは、マニフェストファイルにアクセスできる場合にのみサービスを提供したい場合があります（たとえば、内部アーキテクチャはマニフェストファイル内の知識に基づいているため）。これらのケースでは、CDNI機能アドバタイズメントにフィールドを含めて、dCDNがマニフェストファイルへのアクセスを必要とする事実をアドバタイズできるようにすることが役立つ場合があります。
This document does not discuss security issues related to HTTP or HAS delivery, as these topics are expected to be discussed in the CDNI WG documents, including [CDNI-FRAMEWORK].
これらのトピックは[CDNI-FRAMEWORK]を含むCDNI WGドキュメントで議論されることが期待されているため、このドキュメントではHTTPまたはHAS配信に関連するセキュリティの問題については説明していません。
The authors would like to thank Kevin Ma, Stef van der Ziel, Bhaskar Bhupalam, Mahesh Viveganandhan, Larry Peterson, Ben Niven-Jenkins, and Matt Caulfield for their valuable contributions to this document.
このドキュメントへの貴重な貢献をしてくださったKevin Ma、Stef van der Ziel、Bhaskar Bhupalam、Mahesh Viveganandhan、Larry Peterson、Ben Niven-Jenkins、およびMatt Caulfieldに感謝します。
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012.
[RFC6707] Niven-Jenkins、B.、Le Faucheur、F。、およびN. Bitar、「Content Distribution Network Interconnection（CDNI）Problem Statement」、RFC 6707、2012年9月。
[CDNI-FRAMEWORK] Peterson, L., Ed., and B. Davie, "Framework for CDN Interconnection", Work in Progress, February 2013.
[CDNI-FRAMEWORK] Peterson、L.、Ed。、and B. Davie、 "Framework for CDN Interconnection"、Work in Progress、2013年2月。
[CDNI-LOGGING] Bertrand, G., Ed., Stephan, E., Peterkofsky, R., Le Faucheur, F., and P. Grochocki, "CDNI Logging Interface", Work in Progress, October 2012.
[CDNI-LOGGING] Bertrand、G.、Ed。、Stephan、E.、Peterkofsky、R.、Le Faucheur、F。、およびP. Grochocki、「CDNI Logging Interface」、Work in Progress、2012年10月。
[CDNI-REQUIREMENTS]
[CDNI-REQUIREMENTS]
Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", Work in Progress, July 2013.
Leung、K.、Ed。とY. Lee、Ed。、 "Content Distribution Network Interconnection（CDNI）Requirements"、Work in Progress、2013年7月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986] Berners-Lee、T.、Fielding、R。、およびL. Masinter、「Uniform Resource Identifier（URI）：Generic Syntax」、STD 66、RFC 3986、2005年1月。
Authors' Addresses
著者のアドレス
Ray van Brandenburg TNO Brassersplein 2 Delft 2612CT the Netherlands
レイヴァンブランデンブルクTNOブラッサースプレイン2デルフト2612CTオランダ
Phone: +31-88-866-7000
EMail: ray.vanbrandenburg@tno.nl
Oskar van Deventer TNO Brassersplein 2 Delft 2612CT the Netherlands
オスカーファンデーフェンターTNOブラッサースプレイン2デルフト2612CTオランダ
Phone: +31-88-866-7000
EMail: oskar.vandeventer@tno.nl
Francois Le Faucheur Cisco Systems E.Space Park - Batiment D 6254 Allee des Ormes - BP 1200 06254 Mougins cedex France
フランソワルフォシェールシスコシステムズEスペースパーク-バティメントD 6254アリーデオルム-BP 1200 06254ムージャンセデックスフランス
Phone: +33 4 97 23 26 19
EMail: flefauch@cisco.com
Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USA
Kent Leung Cisco Systems 170 West Tasman Drive San Jose、CA 95134 USA
Phone: +1 408-526-5030
EMail: kleung@cisco.com