Re: [icnrg] Questions about an empty name segment

[Atsushi Ooka <[e-mail]>]

Dear Marc,

Thank you very much for your kind reply.
I mostly understand how to use a 0-length name, a 0-length name
component and nameless object.

Before your reply, I thought that T_APP TLV might be
application-dependent supplementary information, i.e., T_APP TLV might
be used by only applications and it might be ignored in matching
process in a router.

However, in my current understanding, T_APP TLV involves matching process.
Moreover, not only Value but also Type of name component are used in
the matching process.
If the type of 0-length name component in a FIB prefix is T_APP, the
FIB prefix acts as a typed default route.


Then, I have additional questions about the type of name component, as below.
I'd appreciate if you could answer the questions.
Thanks a lot.


(A) Is a T_NAMESEGMENT-type 0-length name segment possible on specifications?
     (Although it may not be typical and Metis [4] deletes such a name segment.)

(B) Which is correct about a FIB prefix with 0-length name component
that is NOT the 1st one? (e.g., "ccnx:/NAME=foo/APP:1=")
    (B.1) It acts as a typed default route against a name that has the
same prefix.
    (B.2) It acts as a typed wild-card that matches any name
components that has same type and is located in the same position.
        (e.g., Interest named "ccnx:/NAME=foo/APP:1=hoge/APP:2=fuga"
matches FIB prefix "ccnx:/NAME=foo/APP:1=/APP:2=fuga".)
    (B.3) The name component acts as null value and the FIB prefix
matches only a name that has the exactly same prefix.
        (i.e., Interest named "ccnx:/NAME=foo/APP:1=hoge" cannot match
FIB prefix "ccnx:/NAME=foo/APP:1=".)

(C) If (B.3) is true, is it assumed that a typed default route using
T_APP is used within only a local network?
    (This is because the 4096 types for T_APP seem to be too few
compared to the number of network applications all over the world.)

(D) If FIB has the prefix "ccnx:/NAME=", is it correct that only a
name with T_NAMESEGMENT-type 1st name component can match the prefix
and a name with T_APP-type 1st name component cannot match the prefix?

(E) The matching rule for T_ORG (organization specific) TLV is defined?
    In other words, does a incompatible router ignore the T_ORG TLV in
the matching process, or treat it as a normal name component?


Best regards,
Atsushi Ooka.
2018年10月23日(火) 5:09 <[e-mail]>:
>
> A minor correction, in the example
>
> ccnx:/APP:00=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:01=
> ccnx:/APP:01=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:01=
>
> it should read, where the 1st FIB prefix is corrected to APP:00 from APP:01
>
> ccnx:/APP:00=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:00=
> ccnx:/APP:01=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:01=
>
> Marc
> ________________________________________
> From: icnrg [[e-mail]] on behalf of [e-mail] [[e-mail]]
> Sent: Monday, October 22, 2018 11:32 AM
> To: [e-mail]
> Cc: [e-mail]
> Subject: Re: [icnrg] Questions about an empty name segment
>
> Dr. Ooka,
>
> Thank you for the question, as there are several important distinctions here.
>
> =================
> Definitions
> =================
>
> A Name has two primary use cases: (1) in a protocol message and in the PIT, (2) in an implementation’s FIB.
>
> In case 1, the syntax of a Name is defined in the ABNF of [2], which correspond to the “exact” name concept (Sec 3 of [2]).  It identifies a specific content object, but not including the ConObjHash restriction (which would make it a “full” name).
>
> In case 2, in the FIB, one wants the ability to specify the “prefix” name concept.  These specify a prefix of an exact name.
>
> In a protocol message (case 1), the Name maybe (1.a) missing, (1.b) exactly 1 name segment, where the 1st name segment cannot be 0 length, or (1c) more than 1 name segment, where the 1st name segment cannot be 0 length, but any or all subsequent name segments could be 0 length.  In case 1.a, it is a so-called nameless object and processed as per the specs; note that here the name is missing, it is not a 0-length name.  In the PIT, the name is the same as it is in a protocol message (as the PIT records the protocol message’s name).
>
> In the FIB in case 2, you can have (1.b) or (1.c) or a (2.a) 0-length name, or (2b) a 1-segment name with 0-length.  In case 2.a, this is considered the default route and would match any name.  In case 2.b, it is a typed default route and would match any name with a specific first name segment type.  In cases 1.b or 1.c, it works the obvious way.
>
> In ccnxmessages, a 0-length name is defined as the NAME TLV with T = T_NAME, L = 0.  A 1-segment name with 0-length is (T = T_NAME, L = 4, V = (T = x, L = 0)), where x is some name segment type.
>
> Note that in the specs we do not say how an implementation must encode a default route in its FIB.  We only specify how it is externally represented in the CCNX URI spec.  The actual value in the FIB or how the the implementation uses a default route is up to the implementation.  The default route, for example, could be in a separate data structure and only used if there’s no match in the FIB.
>
> =================
> Usage
> =================
>
> In an application (and thus in protocol messages), I do not think it is typical for a name segment to be empty, but this is a way to express a null value.  In CCNx 0.x, for example, a 0-length name segment was sometimes used because it was always short-lex sorted before any other value in the name segment.  Sometimes it used a 0-length name segment to represent the value “0” rather than encode a %00.  In CCNx 1.0 (the IETF spec), we steered away from this sort of usage because saving 1 byte was not considered as important as avoiding the confusion this sort of usage engendered.  Also, a competent compression scheme would fix the byte usage.  We preferred to encode a 0 as %00 and encode null as 0-length.
>
> Here is a simple made-up example.  An application might have some application-defined name components where the name components might be “first_name” and “middle_name” and “family_name”.  Some people might not have a middle_name and in that case the application could represent null as a 0-length name component.  Another way to represent this would be to discard the middle_name name component.
>
> Examples:
> ccnx:/name=foo/name=bar/name=my_app/APP:00=alice/APP:01=jane/APP:02=smith
> ccnx:/name=foo/name=bar/name=my_app/APP:00=bob/APP:01=/APP:02=tucker
>
> In a certain application, perhaps we use distinguished first name component types to distinguish a service, where we want different routing based on the _type_ of the name component, not the actual name.  For example, these two names should have different routing:
>
> ccnx:/APP:00=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:01=
> ccnx:/APP:01=gold/name=foo/name=bar => FIB prefix = ccnx:/APP:01=
>
> Note that we are routing on the name component _type_ not the _value_.
>
> This same technique can also be used mid-way through the name, such as to distinguish between /NAME=foo/APP:00=silver and /NAME=foo/APP:01=silver.
>
> Marc
>
>
> > On Oct 22, 2018, at 3:23 AM, Atsushi Ooka <[e-mail]> wrote:
> >
> > Dear all.
> >
> > I have some questions about an empty name segment
> > such as "ccnx:/NAME=" and "ccnx:/foo/bar/NAME=".
> >
> > Why is an empty name segment needed, and how can it be used?
> >
> > I have read Internet-Drafts (IDs) [1,2,3] and
> > confirmed the behavior of Metis [4] and iping [5];
> > however, it is not clear for me how to use them.
> >
> > Thank you in advance.
> >
> > Best regards,
> > Atsushi Ooka
> >
> > [1] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxmessages-08
> > [2] https://tools.ietf.org/html/draft-irtf-icnrg-ccnxsemantics-09
> > [3] https://tools.ietf.org/html/draft-mosko-icnrg-ccnxurischeme-01
> > [4] Metis (FD.IO sb-forwareder) https://wiki.fd.io/view/Sb-forwarder
> > [5] iping (FD.IO libicnet) https://wiki.fd.io/view/Libicnet
> >
> > ----------------------------------------------------------------------
> > Atsushi Ooka, Ph.D.
> >
> > Network Science and Convergence Device Technology Laboratory,
> > Network System Research Institute,
> > National Institute of Information and Communications Technology (NICT)
> >
> > E-mail: [e-mail]
> > Tel: [phone]
> > URL: http://www.nict.go.jp
> > ----------------------------------------------------------------------
> >
> > _______________________________________________
> > icnrg mailing list
> > [e-mail]
> > https://www.irtf.org/mailman/listinfo/icnrg
>
> _______________________________________________
> icnrg mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/icnrg