from http://ppkpub.org/doc/PPK_AP_SPEC_20150811.txt
結合ODIN(開放數據索引命名)的AP（數據訪問點）技術規範（草案）
-- PPk開放小組 ( The PPk Public Group )
http://ppkpub.org/
1、AP簡介
AP是數據訪問點(Access Point)的縮寫。每一個ODIN標識會被解析映射到一個或若干個數據訪問點（AP）上，由AP負責提供具體數據。
AP可以理解爲PPk網絡的“路由器”(Router)。
2、AP架構
借鑑NDN（Named Data Networking，即命名數據網絡）的定義，AP相關通信採用發佈/訂閱機制（publish/subscribe）， 是由接收端（即數據消費者，Data Consumer）驅動的。爲了接收數據，一個消費者發出一條興趣（Interest）報文，該報文攜帶一個ODIN標識，由ODIN標識來識別期望的數據（見圖1）。
----------------------------------
| ODIN標識符(ODIN) |
|--------------------------------|
| 負載標識(PayloadID) |
----------------------------------
圖1 興趣報文
作爲PPk網絡分階段實現路線的第一階段目標，將先實現最簡單的情況，即消費者直接以IP形式連接存放所需數據的AP獲得數據報文。例如：一個消費者可請求 ppk:/23.567/videos/2381920#，會通過層級解析獲知可用的AP地址，並以IP數據包的形式向AP發出興趣報文，AP則同樣以IP數據包的形式發回一條數據（Data）報文，它攜帶數據的ODIN標識(比如ppk:/23.567/videos/2381920#2.0)和對應內容，還有對應生產者內容簽名私鑰所生成的一個簽名（見圖2）。
注：請求者的ODIN標識如果未指定準確的數據塊位置，則缺省匹配返回的是對應內容的最新區塊N的第一個數據塊（即#N.0）。
----------------------------------
| ODIN標識符(ODIN) |
|--------------------------------|
| 元數據描述信息(MetaInfo) |
|--------------------------------|
| 數據內容(Content) |
|--------------------------------|
| 生產者簽名(Signature) |
----------------------------------
圖2 數據報文
ODIN標識對於路由網絡而言是不透明的，即路由不知道一個標識的含義（雖然它們知道一個標識各組成部分之間的邊界）。這允許應用可以自主選擇其需要的具體資源命名方案，並允許命名方案獨立於網絡而演化。
爲了檢索動態產生的數據，消費者必須能夠確定性地定位數據的期望片段構造標識，而不需要以前看到該標識或數據。
例如: 消費者可請求ppk:/23.567/videos_2381920，並得到名字爲ppk:/23.567/videos_2381920#1.0的一條數據報文（標識尾部增加的“1.0”表示第1個版本區塊的第1個片段數據塊），之後消費者可指定以後的片段，並請求它們，使用的是第一條數據報文以及消費者應用和生成者應用之間達成的命名慣例等所揭示的信息組合。（如果判斷來源AP在一段時間內訪問過該資源標識且沒有更新的話，可以返回LINK類型，直接利用來源AP的緩存數據返回）
注：AP可以支持所有現有的應用，包括“推動”內容的那些應用。例如： 爲了發送一封電子郵件，客戶端首先向服務器發送一條興趣報文，來請求對於接受該電子郵件的服務器興趣。如果服務器是感興趣的，則它將向客戶端發送一條興趣報文，之後客戶端向服務器發送數據報文。
興趣報文中的ODIN標識可以採用標準結構式或自定義結構式，但解析結果的數據報文中ODIN標識都採用標準結構式。
注意:如果多級AP存在相同的情況，借鑑NDN的設計，相同的興趣報文或數據報文會被忽略以避免環路。
3. 報文定義
參考和兼容NDN/CCNx協議規範(http://named-data.net/doc/ndn-tlv/index.html , http://tools.ietf.org/html/draft-mosko-icnrg-ccnxmessages-01)。
報文定義採用了TLV格式編碼,即每一個數據字段對應： Type類型， Lenght長度，Value值
Type和Length的長度固定，都是2字節；
Value的長度由Length指定；
解析方法：
1.讀取type 轉換爲ntohl、ntohs轉換爲主機字節序得到類型；指針偏移+2
2.讀取length，轉換爲ntohl、ntohs轉換爲主機字節序得到長度；指針偏移+2
3.根據得到的長度讀取value，指針偏移+Length；
。。。。
繼續處理後面的TLV；
3.1 報文總體結構
每一個報文都有8字節的固定頭部，後面是採用TLV格式的字段集合，對應逐跳描述(Hop-by-hop，可選)和實際報文(PacketPayload)數據。
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Version | PacketType | PacketLength |
+---------------+---------------+---------------+---------------+
| PacketType specific fields | HeaderLength |
+---------------+---------------+---------------+---------------+
/ Optional Hop-by-hop header TLVs /
+---------------+---------------+---------------+---------------+
/ PacketPayload TLVs /
+---------------+---------------+---------------+---------------+
3.2 報文固定頭部
固定頭部說明如下：
o Version: 協議版本，本文對應爲 1 。.
o HeaderLength: 包含固定頭部（8字節）和逐跳描述(Hop-by-hop)頭部TLV字段的總字節長度，最小爲8，最大爲255.
o PacketType: 報文類型， 目前取值定義：興趣報文(Interest)取值0, 數據報文(ContentObject) 取值1, 興趣異常反饋報文(InterestReturn)取值2。
o PacketLength: 報文總字節長度（包括頭部和正文）。
o PacketType Specific Fields: 保留字段(3字節)，由特定報文類型定義。
3.2.1 興趣報文（Interest）固定頭部
興趣報文的固定頭部構成如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| 1 | 0 | PacketLength |
+---------------+---------------+---------------+---------------+
| HopLimit | Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
其中，
逐跳限制(HopLimit) 在多個AP間接力傳播興趣報文時將依次減1直到0，當該字段減爲0後該興趣報文將不再被轉發。 該字段初始可設爲1到255範圍內的任意值。AP對於收到HopLimit爲0的興趣報文將做忽略處理。
保留字段(Reserved)在發出的興趣報文(Interest)中應設置爲0， 在返回的興趣異常反饋報文(InterestReturn)將被填寫上一個狀態值。
擴展標誌(Flags)暫時沒有定義，缺省設置爲0。
3.2.2 數據報文(ContentObject)固定頭部
數據報文的固定頭部構成如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| 1 | 1 | PacketLength |
+---------------+---------------+---------------+---------------+
| Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
保留字段(Reserved)應設置爲0。
擴展標誌(Flags)暫時沒有定義，缺省設置爲0。
3.2.3 興趣異常反饋報文(InterestReturn)固定頭部
興趣異常反饋報文的固定頭部構成如下：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| 1 | 2 | PacketLength |
+---------------+---------------+---------------+---------------+
| HopLimit | ReturnCode | Flags | HeaderLength |
+---------------+---------------+---------------+---------------+
興趣異常反饋報文與對應興趣報文的字節長度一樣，只是PacketType字段設置爲2，原有的保留字段(Reserved)被填寫上具體的反饋狀態值(ReturnCode)，其他字段內容都保持原樣。
反饋狀態值(ReturnCode)取值爲大於0的整數，定義如下：
+-------+--------------------+
| Value | Return Type |
+-------+--------------------+
| 1 | No Route |
| | |
| 2 | Hop Limit Exceeded |
| | |
| 3 | No Resources |
| | |
| 4 | Path Error |
| | |
| 5 | Prohibited |
| | |
| 6 | Congested |
| | |
| 7 | MTU too large |
+-------+--------------------+
Table 1: ReturnCode
3.3 逐跳描述(Hop-by-hop TLV header)字段
Hop-by-hop TLV headers are unordered and no meaning should be
attached to their ordering. Four hop-by-hop headers are described in
this document:
+--------+-------------+-----------------+--------------------------+
| Type | Abbrev | Name | Description |
+--------+-------------+-----------------+--------------------------+
| %x0001 | T_INTLIFE | Interest | The time an Interest |
| | | Lifetime | should stay pending at |
| | | (Section 3.3.1) | an intermediate node. |
| | | | |
| %x0002 | T_CACHETIME | Recommended | The Recommended Cache |
| | | Cache Time | Time for Content |
| | | (Section 3.3.2) | Objects. |
+--------+-------------+-----------------+--------------------------+
Table 2: Hop-by-hop Header Types
Additional hop-by-hop headers are defined in higher level
specifications such as the fragmentation specification.
3.3.1. Interest Lifetime
The Interest Lifetime is the time that an Interest should stay
pending at an intermediate node. It is expressed in milliseconds as
an unsigned, network byte order integer.
A value of 0 (encoded as 1 byte %x00) indicates the Interest does not
elicit a Content Object response. It should still be forwarded, but
no reply is expected.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_INTLIFE | Length |
+---------------+---------------+---------------+---------------+
/ /
/ Lifetime (length octets) /
/ /
+---------------+---------------+---------------+---------------+
3.3.2. Recommended Cache Time
The Recommended Cache Time (RCT) is a measure of the useful lifetime
of a Content Object as assigned by a content producer or upstream
node. It serves as a guideline to the Content Store cache in
determining how long to keep the Content Object. It is a
recommendation only and may be ignored by the cache. This is in
contrast to the ExpiryTime (described in Section 3.6.2.2.2)which
takes precedence over the RCT and must be obeyed.
Because the Recommended Cache Time is an optional hop-by-hop header
and not a part of the signed message, a content producer may re-issue
a previously signed Content Object with an updated RCT without
needing to re-sign the message. There is little ill effect from an
attacker changing the RCT as the RCT serves as a guideline only.
The Recommended Cache Time (a millisecond timestamp) is a network
byte ordered unsigned integer of the number of milliseconds since the
epoch in UTC of when the payload expires. It is a 64-bit field.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CACHETIME | 8 |
+---------------+---------------+---------------+---------------+
/ /
/ Recommended Cache Time /
/ /
+---------------+---------------+---------------+---------------+
3.4. 頂層類型(Top-Level Types)
The top-level TLV types listed below exist at the outermost level of
a PPk-AP/CCNx protocol message.
+-------+----------------------+-------------------+----------------+
| Type | Abbrev | Name | Description |
+-------+----------------------+-------------------+----------------+
| %x000 | T_INTEREST | Interest | An Interest |
| 1 | | (Section 3.6) | MessageType. |
| | | | |
| %x000 | T_OBJECT | Content Object | A Content |
| 2 | | (Section 3.6) | Object |
| | | | MessageType |
| | | | |
| %x000 | T_VALIDATION_ALG | Validation | The method of |
| 3 | | Algorithm | message |
| | | (Section 3.6.4.1) | verification |
| | | | such as |
| | | | Message |
| | | | Integrity |
| | | | Check (MIC), a |
| | | | Message |
| | | | Authentication |
| | | | Code (MAC), or |
| | | | a |
| | | | cryptographic |
| | | | signature. |
| | | | |
| %x000 | T_VALIDATION_PAYLOAD | Validation | The validation |
| 4 | | Payload | output, such |
| | | (Section 3.6.4.2) | as the CRC32C |
| | | | code or the |
| | | | RSA signature. |
+-------+----------------------+-------------------+----------------+
Table 3: PPk-AP/CCNx Top Level Types
3.5. 全局格式定義(Global Formats)
3.5.1. 字符塊(Pad)
The pad type may be used by protocols that prefer word-aligned data.
The size of the word may be defined by the protocol. Padding 4-byte
words, for example, would use a 1-byte, 2-byte, and 3-byte Length.
Padding 8-byte words would use a (0, 1, 2, 3, 5, 6, 7)-byte Length.
A pad may be inserted after any TLV except within a ODIN Name TLV. In the
remainder of this document, we will not show optional pad TLVs.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAD | Length |
+---------------+---------------+---------------+---------------+
/ variable length pad MUST be zeros /
+---------------+---------------+---------------+---------------+
3.5.2. 組織團體身份標識(Organization Specific TLVs)
Organizations may request proprietary TLV types in the Hop-By-Hop
headers section or other TLV containers. The organization then has
control of the contents of the Value, which may be its own binary
field or an encapsulated set of TLVs. The inner TLVs, because we use
a context-dependent TLV scheme, may be fully defined by the
organization.
Organization specific TLVs MUST use the T_ORG type. The Length field
is the length of the organization specific information plus 3. The
Value begins with the 3 byte organization number derived from the
last three digits of the IANA Private Enterprise
Numbers([CCNSemantics]), followed by the organization specific
information.
+--------+--------+------------------+------------------------------+
| Type | Abbrev | Name | Description |
+--------+--------+------------------+------------------------------+
| %x000B | T_ORG | Vendor Specific | Information specific to a |
| | | Information | vendor implementation. |
+--------+--------+------------------+------------------------------+
Table 4: Additional PPk-AP/CCNx Message Types
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| (T_ORG) | Length (3+value length) |
+---------------+---------------+---------------+---------------+
| PEN[0] | PEN[1] | PEN[2] | /
+---------------+---------------+---------------+ +
/ Vendor Specific Value /
+---------------+---------------+---------------+---------------+
3.5.3. 鏈接(Link)
A Link is the tuple: {ODIN, KeyId, ContentObjectHash}. It is a
general encoding that is used in both the payload of a Content Object
with PayloadType = "Link" and in the KeyName field in a KeyLocator.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
/ Mandatory ODIN name /
+---------------+---------------+-------------------------------+
/ Optional KeyId /
+---------------------------------------------------------------+
/ Optional ContentObjectHash /
+---------------------------------------------------------------+
3.6. PPk-AP/CCNx Message
This is the format for the PPk-AP/CCNx protocol message itself. The PPk-AP/CCNx
message is the portion of the packet between the hop-by-hop headers
and the Validation TLVs. The figure below is an expansion of the
"CCNx Message TLV" depicted in the beginning of Section 3. The PPk-AP/CCNx
message begins with MessageType and runs through the optional
Payload. The same general format is used for both Interest and
Content Object messages which are differentiated by the MessageType
field. The first enclosed TLV of a PPk-AP/CCNx Message is always the Name
TLV. This is followed by an optional Message TLVs and an optional
Payload TLV.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| ODIN Name TLV (Type = T_NAME) |
+---------------+---------------+---------------+---------------+
/ Optional Message TLVs (Various Types) /
+---------------+---------------+---------------+---------------+
/ Optional Payload TLV (Type = T_PAYLOAD) /
+---------------+---------------+---------------+---------------+
+--------+-----------+-----------------+----------------------------+
| Type | Abbrev | Name | Description |
+--------+-----------+-----------------+----------------------------+
| %x0000 | T_NAME | ODIN Name | The ODIN name requested in |
| | | (Section 3.6.1) | an Interest or published |
| | | | in a Content Object. |
| | | | |
| %x0001 | T_PAYLOAD | Payload | The message payload. |
| | | (Section 3.6.3) | |
+--------+-----------+-----------------+----------------------------+
Table 5: PPk-AP/CCNx Message Types
3.6.1. ODIN Name
A ODIN Name is a TLV encoded sequence of segments. The table below lists
the type values appropriate for these Name segments. A Name MUST NOT
include PAD TLVs.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_NAME | Length |
+---------------+---------------+---------------+---------------+
/ Name segment TLVs /
+---------------+---------------+---------------+---------------+
+--------+---------------+-------------------+----------------------+
| Type | Symbolic Name | Name | Description |
+--------+---------------+-------------------+----------------------+
| %x0001 | T_NAMESEGMENT | ODIN Name segment | A generic ODIN name |
| | | (Section 3.6.1.1) | Segment. |
| | | | |
| %x0002 | T_IPID | Interest Payload | An identifier that |
| | | ID | represents the |
| | | (Section 3.6.1.2) | Interest Payload |
| | | | field. As an |
| | | | example, the Payload |
| | | | ID might be a nonce or a hash |
| | | | of the Interest |
| | | | Payload. This |
| | | | provides a way to |
| | | | differentiate |
| | | | between Interests |
| | | | based on their |
| | | | payloads without |
| | | | having to parse all |
| | | | the bytes of the |
| | | | payload itself; |
| | | | instead using only |
| | | | this Payload ID Name |
| | | | segment |
| | | | |
| %x1000 | T_APP:00 - | Application | Application-specific |
| - | T_APP:4095 | Components | payload in a name |
| %x1FFF | | (Section 3.6.1.1) | segment. An |
| | | | application may |
| | | | apply its own |
| | | | semantics to the |
| | | | 4096 reserved types. |
+--------+---------------+-------------------+----------------------+
Table 6: PPk-AP/ODIN Types
3.6.1.1. Name Segments
Special application payload name segments are in the range %x1000 -
%1FFF. These have application semantics applied to them. A good
convention is to put the application's identity in the name prior to
using these name segments.
For example, a name like "ppk:/100/bar/yo#1.0" would be encoded as:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| (T_NAME) | %x14 (32) |
+---------------+---------------+---------------+---------------+
| (T_NAME_SEGMENT) | %x04 (4) |
+---------------+---------------+---------------+---------------+
| p p k | : |
+---------------+---------------+---------------+---------------+
| (T_NAME_SEGMENT) | %x03 (3) |
+---------------+---------------+---------------+---------------+
| 1 0 0 |(T_NAME_SEGMENT)
+---------------+---------------+---------------+---------------+
| | %x03 (3) | b |
+---------------+---------------+---------------+---------------+
| a r | (T_NAME_SEGMENT) |
+---------------+---------------+---------------+---------------+
| %x06 (6) | y | o |
+---------------+---------------+---------------+---------------+
| # | 1 | . | 0 |
+---------------+---------------+---------------+---------------+
3.6.1.2. Interest Payload ID
The Interest Payload ID is an octet string created by the origin of
an Interest to represent the Interest Payload. A common
representation is to use a nonce or a hash of the Interest Payload as the
Interest Payload ID.
3.6.2. Message TLVs
Each message type (Interest or Content Object) is associated with a
set of optional Message TLVs. Additional specification documents may
extend the types associated with each.
3.6.2.1. Interest Message TLVs
There are three Message TLVs currently associated with an Interest
message: the KeyIdRestriction selector and the
ContentObjectHashRestriction selector are used to narrow the universe
of acceptable Content Objects that would satisfy the Interest. The
InterestPayloadIDMethod identifies how the InterestPayloadID was
created
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| ODIN Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional KeyIdRestriction TLV /
+---------------------------------------------------------------+
/ Optional ContentObjectHashRestriction TLV /
+---------------------------------------------------------------+
/ Optional InterestPayloadIDMethod TLV /
+---------------------------------------------------------------+
+-------+---------------+-----------------------------+-------------+
| Type | Abbrev | Name | Description |
+-------+---------------+-----------------------------+-------------+
| %x000 | T_KEYIDRESTR | KeyIdRestriction | An octet |
| 2 | | (Section 3.6.2.1.1) | string |
| | | | identifying |
| | | | the |
| | | | specific |
| | | | publisher |
| | | | signing key |
| | | | that would |
| | | | satisfy the |
| | | | Interest. |
| | | | |
| %x000 | T_OBJHASHREST | ContentObjectHashRestrictio | The SHA-256 |
| 3 | R | n (Section 3.6.2.1.2) | hash of the |
| | | | specific |
| | | | Content |
| | | | Object that |
| | | | would |
| | | | satisfy the |
| | | | Interest. |
| | | | |
| %x000 | T_IPIDM | Interest Payload ID Method | Defines the |
| 4 | | (Section 3.6.2.1.3) | method used |
| | | | to create |
| | | | the |
| | | | Interest |
| | | | Payload ID. |
+-------+---------------+-----------------------------+-------------+
Table 7: PPk-AP/CCNx Interest Message TLV Types
3.6.2.1.1. KeyIdRestriction
An Interest may include a KeyIdRestriction selector. This ensures
that only Content Objects with matching KeyIds will satisfy the
Interest. See Section 3.6.4.1.4.1 for the format of a KeyId.
可用於滿足雙方事先約定的特定加密數據需求，或者請求方已掌握內容方的簽名公鑰，要求內容方用對應合法私鑰簽名內容以便驗證。
3.6.2.1.2. ContentObjectHashRestriction
An Interest may also contain a ContentObjectHashRestriction selector.
This is the SHA-256 hash of the Content Object - the self-certifying
name restriction that must be verified in the network, if present.
The only acceptable length is 32.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_OBJHASHRESTR | Length |
+---------------+---------------+---------------+---------------+
/ /
/ SHA-256 digest (32 bytes) /
/ /
/ /
+---------------+---------------+---------------+---------------+
3.6.2.1.3. Interest Payload ID Method
An optional enumeration that identifies how the Interest Payload ID
was created. If the IPIDM field is missing, it is assumed to be "0"
(application specific).
o 0: Application specific
o 1: Nonce
o 2: RFC 6920
If using an RFC 6920 [RFC6920] name segment for the payload ID, only
include the "Digest Algorithm; Digest Value" portion of the NI name
in an LCI URI. For example, use a name like ppk:/name=foo/name=bar/
ipid=sha-256-32;f4OxZQ." The binary wire-format uses the RFC 6920
Binary Format inside the name segment Value.
3.6.2.2. Content Object Message TLVs
The following message TLVs are currently defined for Content Objects:
PayloadType (optional) and ExpiryTime (optional).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| MessageType | MessageLength |
+---------------+---------------+---------------+---------------+
| ODIN Name TLV |
+---------------+---------------+---------------+---------------+
/ Optional PayloadType TLV /
+---------------------------------------------------------------+
/ Optional ExpiryTime TLV /
+---------------------------------------------------------------+
+--------+-------------+---------------------+----------------------+
| Type | Abbrev | Name | Description |
+--------+-------------+---------------------+----------------------+
| %x0005 | T_PAYLDTYPE | PayloadType | Indicates the type |
| | | (Section 3.6.2.2.1) | of Payload contents. |
| | | | |
| %x0006 | T_EXPIRY | ExpiryTime | The time at which |
| | | (Section 3.6.2.2.2) | the Payload expires, |
| | | | as expressed in the |
| | | | number of |
| | | | milliseconds since |
| | | | the epoch in UTC. |
| | | | If missing, Content |
| | | | Object may be used |
| | | | as long as desired. |
| | | | |
+--------+-------------+---------------------+----------------------+
Table 8: PPk-AP/CCNx Content Object Message TLV Types
3.6.2.2.1. PayloadType
The PayloadType is a network byte order integer representing the
general type of the Payload TLV.
o 0: Data
o 1: Key (Reserved for PPk)
o 2: Link
o 3: Manifest (Reserved for PPk)
The Data type indicate that the Payload of the ContentObject is
opaque application bytes. The Key type indicates that the Payload is
a DER encoded public key. The Link type indicates that the Payload
is a Link (Section 3.5.3). If this field is missing, a "Data" type
is assumed. A Manifest type indicates that the Payload is a Manifest
(format TBD).
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAYLDTYPE | Length |
+---------------+---------------+---------------+---------------+
| PayloadType /
+---------------+
3.6.2.2.2. ExpiryTime
The ExpiryTime is the time at which the Payload expires, as expressed
by a timestamp containing the number of milliseconds since the epoch
in UTC. It is a network byte order unsigned integer in a 64-bit
field. A cache or end system should not respond with a Content
Object past its ExpiryTime. Routers forwarding a Content Object do
not need to check the ExpiryTime. If the ExpiryTime field is
missing, the Content Object has no expressed expiration and a cache
or end system may use the Content Object for as long as desired.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_EXPIRY | 8 |
+---------------+---------------+---------------+---------------+
/ ExpiryTime /
/ /
+---------------+---------------+---------------+---------------+
3.6.3. Payload
The Payload TLV contains the content of the packet. It is
permissible to have a "0" length. If a packet does not have any
payload, this field may be omitted, rather than carrying a "0"
length.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_PAYLOAD | Length |
+---------------+---------------+---------------+---------------+
/ Payload Contents /
+---------------+---------------+---------------+---------------+
3.6.3.1. Data Payload Contents
The following message TLVs are currently defined for Data Payload
Contents:
DataMetaInfo and DataChunk .
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------------------------------------------------------+
/ Data MetaInfo TLV /
+---------------------------------------------------------------+
/ Data Chunk TLV /
+---------------------------------------------------------------+
+--------+-------------+---------------------+----------------------+
| Type | Abbrev | Name | Description |
+--------+-------------+---------------------+----------------------+
| %x1000 | T_METAINFO | DataMetaInfo | The meta information |
| | | (Section 3.6.3.1.1) | defined by PPk |
| | | | application |
| | | | |
| %x1001 | T_DATACHUNK | DataChunk | The chunk of the data|
| | | (Section 3.6.3.1.2) | |
| | | | |
+--------+-------------+---------------------+----------------------+
3.6.3.1.1. Data Meta Information
ODIN標識對應數據內容組織結構採用類區塊鏈結構，能很好地滿足定位和讀寫不同的應用數據內容的需求。
對於文件File， 一個區塊可對應文件的一個版本， 每一個區塊內部則由類似交易記錄的若干個二進制子塊組成文件實際內容；
對於動態數據流Stream，和比特幣一樣可以理解爲按一定順序產生並記錄的數據塊。
在元數據描述信息(MetaInfo)字段裏，對於具體資源內容提供以下信息：
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_METAINFO | Length |
+---------------+---------------+---------------+---------------+
/ ChunkType TLV /
+---------------------------------------------------------------+
/ BlockSerialNumber TLV /
+---------------------------------------------------------------+
/ BlockChunks TLV /
+---------------------------------------------------------------+
/ ChunkIndex TLV /
+---------------------------------------------------------------+
/ Optional MetaDesc TLV /
+---------------------------------------------------------------+
+--------+-------------+---------------------+----------------------+
| Type | Abbrev | Name | Description |
+--------+-------------+---------------------+----------------------+
| %x1000 | T_CHUNKTYPE | ChunkType | 數據子塊的類型. |
| | | | |
| %x1001 | T_BLOCKSN | BlockSerialNumber | 對應內容區塊號， |
| | | | 從1開始. |
| | | | |
| %x1002 |T_BLOCKCHUNKS| BlockChunks | 此區塊包含數據子塊數 |
| | | | |
| %x1003 | T_CHUNKINDEX| ChunkIndex | 當前數據子塊在該區塊 |
| | | | 內的索引位置，從0開始|
| | | | |
| | | | |
| %x1004 | T_BLOCKMETA | BlockMeta | 對區塊整體的元數據描 |
| | | | 述，隨該區塊的第1個索|
| | | | 引子塊提供 |
+--------+-------------+---------------------+----------------------+
3.6.3.1.1.1. Chunk Type
The ChunkType is a network byte order integer representing the
general type of the Payload TLV.
o 0: Data (possibly encrypted by application)
o 2: Link
The Data type indicate that the Payload of the ContentObject is
opaque application bytes. The Link type indicates that the Payload
is a Link (Section 3.5.3). If this field is missing, a "Data" type
is assumed.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CHUNKTYPE | 1 |
+---------------+---------------+---------------+---------------+
| ChunkType /
+---------------+
3.6.3.1.1.2. Block Meta
對區塊整體的元數據描述，隨該區塊的第1個索引子塊提供。
對於文件數據(File)，該元數據描述可以包含文件名稱、創建者、內容格式等描述信息。
對於流數據(Stream), 該元數據描述可以包含創建者、內容格式等描述信息。
待進一步定義。
3.6.3.1.1. Data Chunk
The Payload TLV contains the content of the packet. It is
permissible to have a "0" length. If a packet does not have any
payload, this field may be omitted, rather than carrying a "0"
length.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_DATACHUNK | Length |
+---------------+---------------+---------------+---------------+
/ Data Chunk /
+---------------+---------------+---------------+---------------+
3.6.4. Validation
Both Interests and Content Objects have the option to include
information about how to validate the PPk-AP/CCNx message. This information
is contained in two TLVs: the ValidationAlgorithm TLV and the
ValidationPayload TLV. The ValidationAlgorithm TLV specifies the
mechanism to be used to verify the PPk-AP/CCNx message. Examples include
verification with a Message Integrity Check (MIC), a Message
Authentication Code (MAC), or a cryptographic signature. The
ValidationPayload TLV contains the validation output, such as the
CRC32C code or the RSA signature.
An Interest would most likely only use a MIC type of validation - a
crc, checksum, or digest.
3.6.4.1. Validation Algorithm
The ValidationAlgorithm is a set of nested TLVs containing all of the
information needed to verify the message. The outermost container
has type = T_VALIDATION_ALG. The first nested TLV defines the
specific type of validation to be performed on the message. The type
is identified with the "ValidationType" as shown in the figure below
and elaborated in the table below. Nested within that container are
the TLVs for any ValidationType dependent data, for example a Key Id,
Key Locator etc.
Complete examples of several types may be found in Section 3.6.4.1.5
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | ValidationAlgLength |
+---------------+---------------+---------------+---------------+
| ValidationType | Length |
+---------------+---------------+---------------+---------------+
/ ValidationType dependent data /
+---------------+---------------+---------------+---------------+
+--------+---------------+---------------------+--------------------+
| Type | Abbrev | Name | Description |
+--------+---------------+---------------------+--------------------+
| %x0002 | T_CRC32C | CRC32C | Castagnoli CRC32 |
| | | (Section 3.6.4.1.1) | (iSCSI, ext4, |
| | | | etc.), with normal |
| | | | form polynomial |
| | | | 0x1EDC6F41. |
| | | | |
| %x0004 | T_HMAC-SHA256 | HMAC-SHA256 | HMAC (RFC 2104) |
| | | (Section 3.6.4.1.2) | using SHA256 hash. |
| | | | |
| %x0005 | T_VMAC-128 | VMAC-128 | VMAC with 128bit |
| | | (Section 3.6.4.1.2) | tags [VMAC] |
| | | | |
| %x0006 | T_RSA-SHA256 | RSA-SHA256 | RSA public key | Default for PPk
| | | (Section 3.6.4.1.3) | signature using |
| | | | SHA256 digest. |
| | | | |
| %x0007 | EC-SECP-256K1 | SECP-256K1 | Elliptic Curve |
| | | (Section 3.6.4.1.3) | signature with |
| | | | SECP-256K1 |
| | | | parameters (see |
| | | | [ECC]). |
| | | | |
| %x0008 | EC-SECP-384R1 | SECP-384R1 | Elliptic Curve |
| | | (Section 3.6.4.1.3) | signature with |
| | | | SECP-384R1 |
| | | | parameters (see |
| | | | [ECC]). |
+--------+---------------+---------------------+--------------------+
Table 9: PPk-AP/CCNx Validation Types
3.6.4.1.1. Message Integrity Checks
MICs do not require additional data in order to perform the
verification. An example is CRC32C that has a "0" length value.
3.6.4.1.2. Message Authentication Checks
MACs are useful for communication between two trusting parties who
have already shared private keys. Examples include an RSA signature
of a SHA256 digest or others. They rely on a KeyId. Some MACs might
use more than a KeyId, but those would be defined in the future.
3.6.4.1.3. Signature
Signature type Validators specify a digest mechanism and a signing
algorithm to verify the message. Examples include RSA signature og a
SHA256 digest, an Elliptic Curve signature with SECP-256K1
parameters, etc. These Validators require a KeyId and a mechanism
for locating the publishers public key (a KeyLocator) - optionally a
PublicKey or Certificate or KeyName.
3.6.4.1.4. Validation Dependent Data
Different Validation Algorithms require access to different pieces of
data contained in the ValidationAlgorithm TLV. As described above,
Key Ids, Key Locators, Public Keys, Certificates, Links and Key Names
all play a role in different Validation Algorithms.
Following is a table of PPk-AP/CCNx ValidationType dependent data types:
+--------+-------------+-----------------------+--------------------+
| Type | Abbrev | Name | Description |
+--------+-------------+-----------------------+--------------------+
| %x0009 | T_KEYID | SignerKeyId | An identifier of |
| | | (Section 3.6.4.1.4.1) | the shared secret |
| | | | or public key |
| | | | associated with a |
| | | | MAC or Signature. |
| | | | Typically the |
| | | | SHA256 hash of the |
| | | | key. |
| | | | |
| %x000B | T_PUBLICKEY | Public Key | DER encoded public |
| | | (Section 3.6.4.1.4.2) | key. |
| | | | |
| %x000C | T_CERT | Certificate | DER encoded X509 |
| | | (Section 3.6.4.1.4.3) | certificate. |
| | | | |
| %x000E | T_KEYNAME | KeyName | A PPk-AP/CCNx Link | Default for PPk
| | | (Section 3.6.4.1.4.4) | object. |
| | | | |
| %x000F | T_SIGTIME | SignatureTime | A millsecond |
| | | (Section 3.6.4.1.4.5) | timestamp |
| | | | indicating the |
| | | | time when the |
| | | | signature was |
| | | | created. |
+--------+-------------+-----------------------+--------------------+
Table 10: PPk-AP/CCNx Validation Dependent Data Types
3.6.4.1.4.1. KeyId
The KeyId is the publisher key identifier. It is similar to a
Subject Key Identifier from X509 [RFC 3820, Section 4.2.1.2]. It
should be derived from the key used to sign, such as from the SHA-256
hash of the key. It applies to both public/private key systems and
to symmetric key systems.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_KEYID | Length |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
3.6.4.1.4.2. Public Key
A Public Key is a DER encoded Subject Public Key Info block, as in an
X509 certificate.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+---------------+---------------+---------------+---------------+
| T_PUBLICKEY | Length |
+---------------+---------------+---------------+---------------+
/ Public Key (DER encoded SPKI) /
+---------------+---------------+---------------+---------------+
3.6.4.1.4.3. Certificate
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_CERT | Length |
+---------------+---------------+---------------+---------------+
/ Certificate (DER encoded X509) /
+---------------+---------------+---------------+---------------+
3.6.4.1.4.4. KeyName
A KeyName type KeyLocator is a Link.
The KeyName digest is the publisher digest of the Content Object
identified by KeyName. It may be included on an Interest's digest
restriction. A KeyName is a mandatory Name and an optional KeyId.
The KeyId inside the KeyLocator may be included in an Interest's
KeyId to retrieve only the specified key.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| T_KEYNAME | Length |
+---------------+---------------+-------------------------------+
/ Link /
+---------------------------------------------------------------+
3.6.4.1.4.5. SignatureTime
The SignatureTime is a millisecond timestamp indicating the time at
which a signature was created. The signer sets this field to the
current time when creating a signature. A verifier may use this time
to determine whether or not the signature was created during the
validity period of a key, or if it occurred in a reasonable sequence
with other associated signatures. The SignatureTime is unrelated to
any time associated with the actual PPk-AP/CCNx Message, which could have
been created long before the signature. The default behavior is to
always include a SignatureTime when creating an authenticated message
(e.g. HMAC or RSA).
SignatureTime is a network byte ordered unsigned integer of the
number of milliseconds since the epoch in UTC of when the signature
was created. It is a fixed 64-bit field.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------------------------------+
| T_SIGTIME | 8 |
+---------------+---------------+-------------------------------+
/ SignatureTime /
+---------------------------------------------------------------+
3.6.4.1.5. Validation Examples
As an example of a MIC type validation, the encoding for CRC32
validation would be:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 4 |
+---------------+---------------+---------------+---------------+
| T_CRC32 | 0 |
+---------------+---------------+---------------+---------------+
As an example of a MAC type validation, the encoding for an HMAC
using a SHA256 hash would be:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 40 |
+---------------+---------------+---------------+---------------+
| T_HMAC-SHA256 | 36 |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
As an example of a Signature type validation, the encoding for an RSA
public key signing using a SHA256 digest and Public Key would be:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_ALG | 44 + Variable Length |
+---------------+---------------+---------------+---------------+
| T_RSA-SHA256 | 40 + Variable Length |
+---------------+---------------+---------------+---------------+
| T_KEYID | 32 |
+---------------+---------------+---------------+---------------+
/ KeyId /
/---------------+---------------+-------------------------------+
| T_PUBLICKEY | Variable Length (~ 160) |
+---------------+---------------+---------------+---------------+
/ Public Key (DER encoded SPKI) /
+---------------+---------------+---------------+---------------+
3.6.4.2. Validation Payload
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| T_VALIDATION_PAYLOAD | ValidationPayloadLength |
+---------------+---------------+---------------+---------------+
/ Type-dependent data /
+---------------+---------------+---------------+---------------+
The ValidationPayload contains the validation output, such as the
CRC32C code or the RSA signature.
4、AP的功能點
4.1 解析ODIN標識前綴
類以於DNS解析WWW網址中的主機域名部分，解析ODIN標識前綴可以獲得指定ODIN標識的登記信息（包括：名稱、AP列表、數據內容驗證參數、登記時間）。
4.1.1 自主解析一級ODIN標識前綴
一級標識對應AP需要從比特幣區塊鏈上同步全部一級ODIN的列表和配置數據，可以自主解析任意一個一級ODIN標識前綴。
4.1.2 遞歸解析多級擴展ODIN標識前綴
假設一個多級ODIN標識爲ppk:/305678.1000/21.35/23.678/ISBN2890321345_P218#
其去掉資源後綴部分後的前綴爲 ppk:/305678.1000/21.35/23.678
先判斷緩存中是否已有3級標識前綴 ppk:/305678.1000/21.35/23.678# 起始對應的數據報文
如果沒有，則遞歸判斷緩存中是否已有2級標識前綴 ppk:/305678.1000/21.35# 起始對應的數據報文
如果沒有，則判斷是否已有1級標識前綴 ppk:/305678.1000# 對應的註冊信息
如果沒有，則返回無效數據
如有，則向1級標識AP發出對 ppk:/305678.1000/21.35# 的興趣報文並將收到的數據報文返回使用
如有，則向2級標識AP發出對 ppk:/305678.1000/21.35/23.678# 的興趣報文並將收到的數據報文返回使用
如果有，則返回緩存的數據報文
以此類推即可遞歸解析多級擴展ODIN標識前，得到的數據報文中的內容是一個JSON字符串,包含指定該ODIN標識前綴的擁有者相關信息（包括：名稱、AP列表、數據內容驗證參數、登記時間戳UTC）。
4.2 接收興趣報文並反饋數據報文
TCP/UDP方式:
對應AP_URL形式： socket://ap_host:port/
請求:
興趣報文(Interest)
正常應答:
數據報文(ContentObject)
異常應答：
興趣異常反饋報文(InterestReturn)
HTTP方式:
對應AP_URL形式： http(s)://ap_host:port/
請求:
以request或form提供ppk_interest字段，取值爲對應興趣報文(Interest)
正常應答:
數據報文(ContentObject)
異常應答：
興趣異常反饋報文(InterestReturn)
3、未來發展
隨着PPk網絡的進一步發展，後續將借鑑NDN的定義，在消費者無法直連存放所需數據的AP時，可以向自己所能連接的一臺或若干臺AP發出興趣報文，AP將記住請求到達的接口，之後通過在其轉發信息表（FIB）(是由一種基於ODIN標識的路由協議傳播的)中查找該名字而轉發興趣報文。一旦興趣報文到達擁有被請求數據的一個節點，則發回一條數據（Data）報文。這條數據報文經興趣報文所產生的反向路徑到達消費者。
注意興趣或數據報文都沒有攜帶任何主機或接口地址（例如IP地址）：依據興趣報文中攜帶的ODIN標識，興趣報文向數據生產者路由，而數據報文依據在每個路由跳處由興趣所建立的狀態信息得以返回。
未來，PPk網絡將固有地支持多路徑路由，而IP路由採用單一最佳路徑來防止環路。在PPk網絡中，興趣不能永久地環回，原因是標識加上隨機數的做法可有效地識別要丟棄的重複副本。數據是不會環回的，原因是數據走的是興趣的反向路徑。因此，一臺AP可使用多個接口發出一條興趣，而不用擔憂環回。返回的第一條數據將滿足興趣，並被局部緩存；後到達的則被丟棄。這種能力可以進一步細化完善並稱之爲轉發策略。
在未來PPk網絡中路由安全將得到極大提高，首先，對所有數據（包括路由消息）簽名，防止了數據被欺騙或篡改。第二，多路徑路由緩解了前綴劫持，原因是路由可檢測到由前綴劫持所導致的異常，並嘗試其它路徑來檢索數據。第三，PPk消息僅談論數據以及簡單地不會尋址到主機的事實，使之向一個特定的目標發送惡意報文成爲困難的事情。爲了做到實用高效，針對PPk的攻擊一定會將焦點放在拒絕服務上，這將通過特定方案來解決。
在接收到一條興趣報文時，一臺AP會首先檢查內容存儲，如果存在這樣的數據，其名字落在該興趣的名字範圍內，則數據將作爲一條響應被髮回。與傳統IP路由的緩存機制不同的是，AP能夠向不同請求者重用數據，原因是這些數據由永久唯一標識加以區別的。緩存標識數據將涉及到隱私擔憂，這可以通過非顯式的命名標識的資源層級來降低隱私風險，同時PPk完全地去除了誰正在請求數據的信息，除非直接通過一條點對點鏈路連接到正在請求的主機，否則一臺AP將僅知道某個人請求了某些數據，但不知道是誰發出的請求。
除了在應用層AP可自行實現多路徑路由外，未來如果NDN網絡能逐步替代IP網絡，則AP可以兼容選擇NDN作爲承載（即AP支持類似“ndn:”起始的URI配置），可以獲得更好的傳輸性能。
以NDN爲代表的CCN 由於自身可能存在的缺點，以及其他未來網絡或改良方案的競爭，也面臨着很大的
挑戰。例如：CCN 是消費者驅動的。沒有基於推的動作，即信息沒有推到終端的功能，既然
以信息爲中心，那麼從信息流動的角度講或者從終端用戶對信息的使用講，有時是爲了獲取
信息變化自己，有時是爲了主動發送信息驅動某對象。網絡中很多控制信息都是基於推的（但
也可能是出於安全的考慮，因爲信息的消費者，可以理解爲資源的消費者，那麼資源提供什
麼服務或者提供什麼控制，都可由消費者發送 interest 獲取，但 interest 不帶數據內容，所
以控制者的信息又是資源主動請求的，這樣可以提高安全性，即我不接受的信息，是不會被
收到的）；另外 CCN 採用分級的命名方案，這種方案在安全上不如扁平的命名方案【3】；最
後，CCN 也有一些沒有考慮到的問題，比如體系結構的可演化問題等。
下面是一些主要的競爭技術：
? 開放式可演化網絡模式
CCN 以內容爲中心，對內容分發等有明顯優點，但目前是否可以判斷這種應用模式是肯
定代表未來，或者內容的標識可以承載並靈活區分處理其他實體對象？否則是否應該開放式
好些呢？當前可演化的網絡體系結構主要有 openflow和 XIA。
? 改良方案
CCN 的目標是解決當前互聯網上存在的問題，而不是以正確的科學理論爲指導而設計。
因此對問題的解決還可以有其他不同的方案，現在出現的每一種問題，都有基於 IP 的改良
方案正在研究，這些方案的性能也在不斷改善。比如基於 IP 的 CDN，互聯網安全的源地址
驗證、IPSec，各種移動方案等。
4、FAQ
4.1 AP如何保護數據隱私？
AP只負責對傳輸數據的簽名驗證，確保收到的數據確實是合法的生產者所提供，但不涉及對數據內容的加解密以提供額外的隱私保護， 由具體應用來確定是否需要加解密，對於限定消費者才能訪問的數據內容，應區分使用不同的ODIN標識並使用生產者和消費者約定方式加密。