Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP
Browse files

refs #100771 Merge remote-tracking branch 'origin/100771-protocol-doc'

* origin/100771-protocol-doc:
  refs #100771  Clarify ChildSelector with an example.
  Refs #100771  Fix a fragmentary clause, and correct the list of encodings not encompassed by the current XML schema.
  Refs #100771  Move the definition of Face earlier, so it is defined before being used.
  Refs #100771  Reduce the use of *destination* in CCNxProtocol document.
  • Loading branch information...
commit 6826e3f2b765c7457e6645144216238c7d9bcb69 2 parents c7a5441 + 5958508
David J. Kordsmeier authored
View
38 doc/technical/CCNxProtocol.txt
@@ -240,7 +240,7 @@ application) contains the following data structures to provide
buffering/caching and loop-free forwarding.
Content Store (CS)::
- A buffer memory organized for retrieval by longest prefix match
+ A buffer memory organized for retrieval by prefix match
lookup on names. Since CCNx Content Object messages are
self-identifying and self-authenticating, each one is potentially
useful to many consumers. The CS SHOULD implement a replacement
@@ -248,17 +248,8 @@ Content Store (CS)::
Least Recently Used (LRU) or Least Frequently Used (LFU). The CS
MUST also implement the link:Staleness.html[Staleness Bit]. The CS
MAY retain Content Object messages indefinitely but is not required
- to take any special measures to preserve them; the CS is a cache not
+ to take any special measures to preserve them; the CS is a cache, not
a persistent store.
-Forwarding Information Base (FIB)::
- A table of destinations for Interests, organized for retrieval by
- longest prefix match lookup on names. Each prefix entry in the FIB
- may point to a list of destinations rather than only one.
-Pending Interest Table (PIT)::
- A table of sources for unsatisfied Interests, organized for
- retrieval by longest prefix match lookup on names. Each entry in
- the PIT may point to a list of sources. Entries in the PIT MUST
- timeout rather than being held indefinitely.
Face::
A 'face' is a generalization of the concept of 'interface': a face
may be a connection to a network or directly to an application
@@ -270,6 +261,15 @@ Face::
on the same machine, via an encapsulation like UDP or an
OS-specific interprocess communication path. All messages arrive
through a face and are sent out through a face.
+Forwarding Information Base (FIB)::
+ A table of outbound faces for Interests, organized for retrieval by
+ longest prefix match lookup on names. Each prefix entry in the FIB
+ may point to a list of faces rather than only one.
+Pending Interest Table (PIT)::
+ A table of sources for unsatisfied Interests, organized for
+ retrieval by longest prefix match lookup on names. Each entry in
+ the PIT may point to a list of sources. Entries in the PIT MUST
+ timeout rather than being held indefinitely.
Note that the tables listed above may be interconnected through a
single index to minimize the cost of lookup operations at the core of
@@ -298,12 +298,14 @@ Interests in the PIT entry and the the Interest Message is discarded.
3. Lookup is performed on FIB. If a matching prefix is found in the
FIB, an entry is created in the PIT identifying the arrival face of
the Interest Message and the message is transmitted according to the
-'strategy rules' to one or more of the destination faces registered
-for the prefix in the FIB. Note that one of the destination faces may
+'strategy rules' to one or more of the outbound faces registered
+for the prefix in the FIB. Note that one of the outbound faces may
actually be connected to a local agent that uses the semantics of the
name to dynamically configure new faces.
4. If no match is found in the previous steps then the node has no way
-to satisfy the Interest Message and it is discarded.
+to satisfy the Interest Message at present. It may be held for a short
+time before being discarded, since the creation of a new FIB entry may
+provide way to satisfy it.
Processing Content Messages
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -328,15 +330,15 @@ subsequently requested.
Strategy Rules
~~~~~~~~~~~~~~
-Unlike in IP, CCNx FIB entries may point to multiple destinations
+Unlike in IP, CCNx FIB entries may point to multiple next-hop destinations
simultaneously. The self-identifying nature of Interest Messages and
ContentObjects means that loops can be avoided without establishing a
spanning tree allowing only one destination for any particular prefix
-at any particular node. The possibility of multiple destinations
+at any particular node. The possibility of multiple outbound faces
means that different strategies may be employed to select among them
-for forwarding messages. A node MUST implement some strategy rule,
+when forwarding messages. A node MUST implement some strategy rule,
even if it is only to transmit an Interest Message on all listed
-destination faces in sequence. A node MAY implement many different
+outbound faces in sequence. A node MAY implement many different
strategies. Strategy rules SHOULD be specified by FIB entries: in
this case the FIB entry MAY contain effectively a constrained program
for handling the forwarding of Interest Messages addressing the
View
19 doc/technical/InterestMessage.txt
@@ -90,7 +90,7 @@ The *Bloom* element's BLOB is of length 8 + ceiling(n/8) bytes, where n is the n
...........................................................
and the remaining bytes hold the bits of the Bloom filter. The bits in the filter itself are packed little-endian by byte. Note that a Bloom filter with 0 hash functions is one way to match everything, and a filter with all ones is another. But these are not very compact, so the *All* element is provided as a better way to encode this common case.
-**TODO - The the calculation of the hash functions must also be specified. At present, referring to the c code or java code in the libraries is the best option.**
+**TODO - The calculation of the hash functions must also be specified. At present, referring to the c code or java code in the libraries is the best option.**
**NOTE - New applications should avoid the use of the Bloom form of exclusion. Support for this will be phased out in future revisions.**
@@ -98,7 +98,22 @@ and the remaining bytes hold the bits of the Bloom filter. The bits in the filt
...........................................................
ChildSelector ::= nonNegativeInteger
...........................................................
-Often a given interest will match more than one ContentObject within a given content store. The *ChildSelector* provides a way of expressing a preference for which of these should be returned. If the (low order bit of) the value is 0, the leftmost child is preferred. If 1, the rightmost child is preferred. Here leftmost and rightmost refer to the least and greatest components according to the link:CanonicalOrder.html[canonical CCNx ordering]. This ordering is only done at the level of the name hierarchy one past the name prefix.
+Often a given interest will match more than one ContentObject within a given content store. The *ChildSelector* provides a way of expressing a preference for which of these should be returned.
+If the value is 0, the leftmost child is preferred.
+If 1, the rightmost child is preferred.
+Here leftmost and rightmost refer to the least and greatest components according to the link:CanonicalOrder.html[canonical CCNx ordering].
+This ordering is only done at the level of the name hierarchy one past the name prefix.
+
+For example, when using the normal versioning and segmentation profiles,
+use of rightmost order while performing version resolution is useful.
+It increases the likelyhood that the most desirable response is obtained,
+namely the first segment of the highest version.
+However, a single round cannot be counted on to yield the final answer,
+because the selection is only done with respect to a single content store,
+not globally.
+Additional rounds that exclude the earlier versions may be used to explore the space of versions.
+In this case, the use of ChildSelector does not change the multi-round outcome,
+but it decreases the number of rounds needed to converge to an answer.
== AnswerOriginKind
...........................................................
View
8 doc/technical/Name.txt
@@ -18,10 +18,12 @@ term 'name prefix' or simply 'prefix'.
It is often convenient to use a link:URI.html[URI Representation] for a CCNx Name.
=== XML Presentation
-There are no restrictions on what byte sequences may be used in the,
+There are no restrictions on what byte sequences may be used in a Component,
so when displayed as XML, a base64Binary or hexBinary encoding may be
-needed. When the bytes happen to be printable UTF-8, a more human-friendly "text"
-alternative is available. (Note that the base64Binary and hexBinary options are not currently not shown in the link:xsd.html[official schema].)
+needed.
+When the bytes happen to be printable UTF-8, a more human-friendly "text"
+alternative is available.
+(Note that the text and hexBinary options are not currently not shown in the link:xsd.html[official schema].)
=== Related
The Name element plays a pivotal role in both the
Please sign in to comment.
Something went wrong with that request. Please try again.