[Ndn-interest] Selector Protocol over exact matching

Ignacio.Solis at parc.com Ignacio.Solis at parc.com
Thu Sep 25 01:10:00 PDT 2014

On 9/25/14, 9:17 AM, "Marc.Mosko at parc.com" <Marc.Mosko at parc.com> wrote:
>In the CCNx 1.0 spec, one could also encode this a different way.  One
>could use a name like ³/mail/inbox/selector_matching/<hash of payload>²
>and in the payload include "exclude_before=(t=version, l=2, v=279) &

I want to highlight this.

There is a role that selectors can play in a network.  However, our
biggest issue with selectors is that they are mandated at the forwarder
level.  This means that every node must support selectors.

We want to make sure that the core protocol is simple and efficient.
Exact matching gives us that.  If you¹re interested in selector matching
and searching, then create that protocol over exact matching.

Marc just described a simple ³Selector Protocol", basically:
- Encode selectors (or any query you want) in the interest payload.
- Add a name segment to indicate that this is a selector based query
- Add a name segment to uniquely identify the query (a hash of the payload
for example)

name    = /mail/inbox/list/selector_matching/<hash of interest payload>

payload = version > 100


A ‹‹ B ‹‹ C

A and C run the Selector Protocol
B does not run the Selector Protocol

- Any node that does not understand the Selector Protocol (B) forwards
normally and does exact matching.
- Any node that understands the Selector Protocol (C) can parse the
payload to find a match.

If no match is found, forward the interest.
If a match is found, create a reply.

The reply can contain 2 types of data:
- Structured data with links to the actual content objects
- Encapsulated content objects

So, in our example, the Selector Protocol reply could be:

name = /mail/inbox/list/selector_matching/<hash of interest payload>
payload =
  [  matching name = /mail/inbox/list/v101 ]
  [  embedded object < name = /mail/inbox/list/v101, payload = list,
signature = mail server > ]
signature = responding cache

A few notes:
- Malicious nodes could inject false replies.  So, if C is malicious, it
can insert a reply linking to some random object or just return junk.
Well, this would be the case with regular selectors as well.  C could
reply with random crap or it could reply with a valid answer that is not
the optimal answer (so, for example, not the right-most child or
This is something that we can¹t prevent.

In the case of CCN, our fast path does not check signatures, so you
wouldn¹t be able to check the signature of the reply no matter what.  I¹m
unsure if NDN is still advocating that every node checks signatures.  If
you are, then this approach might not work for you.

Nodes that DO understand the Selector Protocol can check the signature of
the encapsulated reply (if they wanted to).
Nodes that DO understand the Selector Protocol can unpack the reply, and
add the corresponding object to their cache, effectively enabling them to
answer other Selector Protocol queries.

- The reply from the Selector Protocol enabled node (C), could:
‹  include a list of all valid answers
‹  embed no objects
‹  embed more than 1 object
‹  process complex queries, regex, etc.

The Selector Protocol could also:
- include a method for authentication
- include a cursor or some other state between queries

I think this sort of protocol gives you everything you want while still
maintaining an exact match protocol as the core protocol.

What is this protocol missing to satisfy your needs?
Can we create a protocol that will satisfy your needs on top of exact


Nacho (Ignacio) Solis
Protocol Architect
Principal Scientist
Palo Alto Research Center (PARC)
Ignacio.Solis at parc.com

More information about the Ndn-interest mailing list