Skip to main content

CCNinfo: Discovering Content and Network Information in Content-Centric Networks
draft-irtf-icnrg-ccninfo-07

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft that was ultimately published as RFC 9344.
Authors Hitoshi Asaeda , Atsushi Ooka , Xun Shao
Last updated 2021-07-12
Replaces draft-asaeda-icnrg-ccninfo
RFC stream Internet Research Task Force (IRTF)
Formats
IETF conflict review conflict-review-irtf-icnrg-ccninfo, conflict-review-irtf-icnrg-ccninfo, conflict-review-irtf-icnrg-ccninfo, conflict-review-irtf-icnrg-ccninfo, conflict-review-irtf-icnrg-ccninfo, conflict-review-irtf-icnrg-ccninfo
Additional resources Mailing list discussion
Stream IRTF state Active RG Document
Consensus boilerplate Unknown
Document shepherd (None)
IESG IESG state Became RFC 9344 (Experimental)
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-irtf-icnrg-ccninfo-07
Internet-Draft                   CCNinfo                       July 2021

           3. Reply(C)   2. Reply(C)
           3. Reply(P)   2. Reply(P)   1. Reply(P)
             +----+        +----+        +----+
             |    |        |    |        |    |
             v    |        v    |        v    |
    +--------+    +--------+    +--------+    +--------+    +---------+
    | CCNinfo|----| Router |----| Router |----| Router |----|Publisher|
    |  user  |    |   A    |    |   B    |    |   C    |    |         |
    +--------+    +--------+    +--------+    +--------+    +---------+
                                         ^
                                          \          +-------+
                               1. Reply(C) \         | Cache |
                                            \ +---------+    |
                                             \| Caching |----+
                                              |  router |
                                              +---------+

      Figure 17: Full discovery request.  Reply messages forwarded by
   publisher and routers.  Each router forwards the Reply message along
      its PIT entry and finally, the CCNinfo user receives two Reply
   messages: one from the FHR (Router C) and the other from the Caching
                                  router.

   To receive different Reply messages forwarded from different routers,
   the PIT entries initiated by CCNinfo remain until the configured
   CCNinfo Reply Timeout (Section 7.1) is expired.  In other words,
   unlike the ordinary Interest-Data exchanges in CCN, if routers that
   accept the full discovery request receive the full discovery request,
   the routers SHOULD NOT remove the PIT entry created by the full
   discovery request until the CCNinfo Reply Timeout value expires.

   Note that the full discovery request is an OPTIONAL implementation of
   CCNinfo; it may not be implemented on routers.  Even if it is
   implemented on a router, it may not accept the full discovery request
   from non-validated CCNinfo users or routers or because of its policy.
   If a router does not accept the full discovery request, it rejects
   the full discovery request as described in Section 6.11.  Routers
   that enable the full discovery request MAY rate-limit Replies, as
   described in Section 10.8 as well.

5.4.  Sending CCNinfo Reply

   If there is a caching router or FHR for the specified content within
   the specified hop count along the path, the caching router or FHR
   sends back the Reply message toward the CCNinfo user and terminates
   the Request.

Asaeda, et al.          Expires January 13, 2022               [Page 25]
Internet-Draft                   CCNinfo                       July 2021

   When a router decides to send a Reply message to its downstream
   neighbor router or the CCNinfo user with NO_ERROR return code, it
   inserts a Report block with the Request Arrival Time and Node
   Identifier to the Request message.  Then, the router inserts the
   corresponding Reply sub-block(s) (Figure 15) to the payload.  The
   router finally changes the Type field in the fixed header from
   PT_CCNINFO_REQUEST to PT_CCNINFO_REPLY and forwards the message back
   as the Reply toward the CCNinfo user in a hop-by-hop manner.

   If a router cannot continue the Request, the router MUST put an
   appropriate ReturnCode in the Request message, change the Type field
   value in the fixed header from PT_CCNINFO_REQUEST to
   PT_CCNINFO_REPLY, and forward the Reply message back toward the
   CCNinfo user to terminate the Request (see Section 6).

5.5.  Forwarding CCNinfo Reply

   When a router receives a CCNinfo Reply whose Request ID and Node
   Identifier match those in the PIT entry, sent from a valid adjacent
   neighbor router, it forwards the CCNinfo Reply back toward the
   CCNinfo user.  If the router does not receive the corresponding Reply
   within the [CCNinfo Reply Timeout] period, then it removes the
   corresponding PIT entry and terminates the trace.

   The Flags field in the Request block TLV is used to indicate whether
   the router keeps the PIT entry during the CCNinfo Reply Timeout even
   after one or more corresponding Reply messages are forwarded.  When
   the CCNinfo user does not set the F flag (i.e., "0"), the
   intermediate routers immediately remove the PIT entry whenever they
   forward the corresponding Reply message.  When the CCNinfo user sets
   the F flag (i.e., "1"), which means the CCNinfo user chooses the
   "full discovery request" (see Section 5.3.2), the intermediate
   routers keep the PIT entry within the [CCNinfo Reply Timeout] period.
   After this timeout, the PIT entry is removed.

   CCNinfo Replies MUST NOT be cached in routers upon the transmission
   of Reply messages.

5.6.  PIT Entry Management for Multipath Support

   Within a network with multipath condition, there is a case
   (Figure 18) wherein a single CCNinfo Request is split into multiple
   Requests (e.g., at Router A), which are injected into a single router
   (Router D).  In this case, multiple Replies with the same Request ID
   and Node Identifier including different Report blocks are received by
   the router (Router D).

Asaeda, et al.          Expires January 13, 2022               [Page 26]
Internet-Draft                   CCNinfo                       July 2021

                               +--------+
                               | Router |
                               |   B    |
                               +--------+
                              /          \
                             /            \
     +--------+    +--------+              +--------+     +---------+
     | CCNinfo|----| Router |              | Router | ... |Publisher|
     |  user  |    |   A    |              |   D    |     |         |
     +--------+    +--------+              +--------+     +---------+
                             \            /
                              \          /
                               +--------+
                               | Router |
                               |   C    |
                               +--------+

                                 Figure 18

   To recognize different CCNinfo Reply messages, the routers MUST
   distinguish the PIT entries by the Request ID and exploiting path
   labels, which could be a hash value of the concatenation information
   of the cumulate Node Identifiers in the hop-by-hop header and the
   specified content name.  For example, when Router D in Figure 18
   receives a CCNinfo Request from Router B, its PIT includes the
   Request ID and value such as H((Router_A|Router_B)|content_name),
   where "H" indicates some hash function and "|" indicates
   concatenation.  When Router D receives a CCNinfo Request from Router
   C, its PIT includes the same Request ID and value of
   H((Router_A|Router_C)|content_name).  Two different Replies are later
   received on Router D and each Reply is appropriately forwarded to
   Router B and Router C, respectively.  Note that two Reply messages
   coming from Router B and Router C are reached at Router A, but the
   CCNinfo user can only receive the first Reply message either from
   Router B or Router C as Router A removes the corresponding PIT entry
   after it forwards the first Reply.

   To avoid routing loop, when a router seeks the cumulate Node
   Identifiers of the Report blocks in the hop-by-hop header, it MUST
   examine whether its own Node Identifier is not previously inserted.
   If a router detects its own Node Identifier in the hop-by-hop header,
   the router inserts its Report block and terminates the Request as
   will be described in Section 6.8.

Asaeda, et al.          Expires January 13, 2022               [Page 27]
Internet-Draft                   CCNinfo                       July 2021

6.  CCNinfo Termination

   When performing a hop-by-hop trace, it is necessary to determine when
   to stop the trace.  There are several cases when an intermediate
   router might return a Reply before a Request reaches the caching
   router or the FHR.

6.1.  Arriving at First-hop Router

   A CCNinfo Request can be determined to have arrived at the FHR.  To
   ensure that a router recognizes that it is the FHR for the specified
   content, it needs to have a FIB entry (or attach) to the
   corresponding publisher or the content.

6.2.  Arriving at Router Having Cache

   A CCNinfo Request can be determined to have arrived at the router
   having the specified content cache within the specified HopLimit.

6.3.  Arriving at Last Router

   A CCNinfo Request can be determined to have arrived at the last
   router of the specified HopLimit.  If the last router does not have
   the corresponding cache, it MUST insert its Report block and send the
   Reply message with NO_INFO return code without appending any Reply
   (sub-)block TLVs.

6.4.  Invalid Request

   If the router does not validate the Request or the Reply, the router
   MUST note a ReturnCode of INVALID_REQUEST in the fixed header of the
   message, insert its Report block, and forward the message as the
   Reply back to the CCNinfo user.  The router MAY, however, randomly
   ignore the received invalid messages.  (See Section 10.7.)

6.5.  No Route

   If the router cannot determine the routing paths or neighbor routers
   for the specified name prefix within the specified HopLimit, it MUST
   note a ReturnCode of NO_ROUTE in the fixed header of the message,
   insert its Report block, and forward the message as the Reply back to
   the CCNinfo user.

6.6.  No Information

   If the router does not have any information about the specified name
   prefix within the specified HopLimit, it MUST note a ReturnCode of

Asaeda, et al.          Expires January 13, 2022               [Page 28]
Internet-Draft                   CCNinfo                       July 2021

   NO_INFO in the fixed header of the message, insert its Report block,
   and forward the message as the Reply back to the CCNinfo user.

6.7.  No Space

   If appending the Report block or the Reply (sub-)block would make the
   hop-by-hop header longer than 247 bytes or the Request packet longer
   than the MTU of the Incoming face, the router MUST note a ReturnCode
   of NO_SPACE in the fixed header of the message and forward the
   message as the Reply back to the CCNinfo user.

6.8.  Fatal Error

   If a CCNinfo Request has encountered a fatal error, the router MUST
   note a ReturnCode of FATAL_ERROR in the fixed header of the message
   and forward the message as the Reply back to the CCNinfo user.  This
   may happen, for example, when the router detects some routing loop in
   the Request blocks (see Section 1).  The fatal error can be encoded
   with another error: if a router detects routing loop but cannot
   insert its Report block, it MUST note NO_SPACE and FATAL_ERROR
   ReturnCodes (i.e., %x85) in the fixed header and forward the message
   back to the CCNinfo user.

6.9.  CCNinfo Reply Timeout

   If a router receives the Request or Reply message that expires its
   own [CCNinfo Reply Timeout] value (Section 7.1), the router will
   silently discard the Request or Reply message.

6.10.  Non-Supported Node

   Cases will arise in which a router or a FHR along the path does not
   support CCNinfo.  In such cases, a CCNinfo user and routers that
   forward the CCNinfo Request will time out the CCNinfo request.

6.11.  Administratively Prohibited

   If CCNinfo is administratively prohibited, the router rejects the
   Request message and MUST send the CCNinfo Reply with the ReturnCode
   of ADMIN_PROHIB.  The router MAY, however, randomly ignore the
   Request messages to be rejected (see Section 10.7).

7.  Configurations

Asaeda, et al.          Expires January 13, 2022               [Page 29]
Internet-Draft                   CCNinfo                       July 2021

7.1.  CCNinfo Reply Timeout

   The [CCNinfo Reply Timeout] value is used to time out a CCNinfo
   Reply.  The value for a router can be statically configured by the
   router's administrators/operators.  The default value is 3 (seconds).
   The [CCNinfo Reply Timeout] value SHOULD NOT be larger than 4
   (seconds) and SHOULD NOT be lower than 2 (seconds).

7.2.  HopLimit in Fixed Header

   If a CCNinfo user does not specify the HopLimit value in the fixed
   header for a Request message as the HopLimit, the HopLimit is set to
   32.  Note that 0 HopLimit is an invalid Request; hence, the router in
   this case follows the way defined in Section 6.4.

7.3.  Access Control

   A router MAY configure the valid or invalid networks to enable an
   access control.  The access control MAY be defined per name prefix,
   such as "who can retrieve which name prefix" (see Section 10.2).

8.  Diagnosis and Analysis

8.1.  Number of Hops and RTT

   A CCNinfo Request message is forwarded in a hop-by-hop manner and
   each forwarding router appends its own Report block.  We can then
   verify the number of hops to reach the content forwarder or publisher
   and the RTT between the content forwarder or publisher.

8.2.  Caching Router Identification

   While some routers may hide their node identifiers with all-zeros in
   the Report blocks (as seen in Section 10.1), the routers in the path
   from the CCNinfo user to the content forwarder can be identified.

8.3.  TTL or Hop Limit

   By taking the HopLimit from the content forwarder and forwarding the
   TTL threshold over all hops, it is possible to discover the TTL or
   hop limit required for the content forwarder to reach the CCNinfo
   user.

8.4.  Time Delay

   If the routers have synchronized clocks, it is possible to estimate
   the propagation and queuing delays from the differences between the
   timestamps at the successive hops.  However, this delay includes the

Asaeda, et al.          Expires January 13, 2022               [Page 30]
Internet-Draft                   CCNinfo                       July 2021

   control processing overhead; therefore, it is not necessarily
   indicative of the delay that would be experienced by the data
   traffic.

8.5.  Path Stretch

   By obtaining the path stretch "d / P", where "d" is the hop count of
   the data and "P" is the hop count from the consumer to the publisher,
   we can measure the improvements in path stretch in various cases,
   such as in different caching and routing algorithms.  We can then
   facilitate the investigation of the performance of the protocol.

8.6.  Cache Hit Probability

   CCNinfo can show the number of received interests per cache or chunk
   on a router.  Accordingly, CCNinfo measures the content popularity
   (i.e., the number of accesses for each content/cache), thereby
   enabling the investigation of the routing/caching strategy in
   networks.

9.  IANA Considerations

   New assignments can only be made via a Standards Action as specified
   in [5].  This document does not intend to be the standard document.
   However, the new assignments such as the ReturnCode and various type
   values will be considered when this specification becomes the RFC.

10.  Security Considerations

   This section addresses some of the security considerations.

10.1.  Policy-Based Information Provisioning for Request

   Although CCNinfo gives excellent troubleshooting cues, some network
   administrators or operators may not want to disclose everything about
   their network to the public or may wish to securely transmit private
   information to specific members of their networks.  CCNinfo provides
   policy-based information provisioning, thereby allowing network
   administrators to specify their response policy for each router.

   The access policy regarding "who is allowed to retrieve" and/or "what
   kind of cache information" can be defined for each router.  For the
   former type of access policy, routers with the specified content MAY
   examine the signature enclosed in the Request message and decide
   whether they should notify the content information in the Reply.  If
   the routers decide to not notify the content information, they MUST
   send the CCNinfo Reply with the ReturnCode of ADMIN_PROHIB without
   appending any Reply (sub-)block TLVs.  For the latter type of policy,

Asaeda, et al.          Expires January 13, 2022               [Page 31]
Internet-Draft                   CCNinfo                       July 2021

   the permission, whether (1) All (all cache information is disclosed),
   (2) Partial (cache information with a particular name prefix can (or
   cannot) be disclosed), or (3) Deny (no cache information is
   disclosed), is defined at the routers.

   In contrast, we entail that each router does not disrupt the
   forwarding of CCNinfo Request and Reply messages.  When a Request
   message is received, the router SHOULD insert the Report block if the
   ReturnCode is NO_ERROR.  Here, according to the policy configuration,
   the Node Identifier field in the Report block MAY be null (i.e., all-
   zeros), but the Request Arrival Time field SHOULD NOT be null.
   Finally, the router SHOULD forward the Request message to the
   upstream router toward the content forwarder if the ReturnCode is
   kept with NO_ERROR.

10.2.  Filtering CCNinfo Users Located in Invalid Networks

   A router MAY support an access control mechanism to filter out
   Requests from invalid CCNinfo users.  To accomplish this, invalid
   networks (or domains) could, for example, be configured via a list of
   allowed/disallowed networks (as observed in Section 7.3).  If a
   Request is received from a disallowed network (according to the Node
   Identifier in the Request block), the Request MUST NOT be processed
   and the Reply with the ReturnCode of INFO_HIDDEN SHOULD be used to
   note that.  The router MAY, however, perform rate limited logging of
   such events.

10.3.  Topology Discovery

   CCNinfo can be used to discover actively used topologies.  If a
   network topology is not disclosed, CCNinfo Requests SHOULD be
   restricted at the border of the domain using the ADMIN_PROHIB return
   code.

10.4.  Characteristics of Content

   CCNinfo can be used to discover the type of content being sent by
   publishers.  If this information is a secret, CCNinfo Requests SHOULD
   be restricted at the border of the domain, using the ADMIN_PROHIB
   return code.

10.5.  Computational Attacks

   CCNinfo may impose heavy tasks at content forwarders because it makes
   content forwarders seek their internal cache states reported in the
   Reply messages whenever they form the Reply messages.  The current
   CCNinfo specification allows to return null values for several
   fields, such as First/Last Seqnum or Elapsed Cache Time fields in the

Asaeda, et al.          Expires January 13, 2022               [Page 32]
Internet-Draft                   CCNinfo                       July 2021

   Reply sub-block.  As mentioned in Section 3.2.1.1, these values MAY
   be null.  This means that the content forwarder can not only hide
   these values owing to privacy/security policies, but also skip the
   implementations of the complex functions to report these values.

10.6.  Longer or Shorter CCNinfo Reply Timeout

   Routers can configure CCNinfo Reply Timeout (Section 7.1), which is
   the allowable timeout value to keep the PIT entry.  If routers
   configure a longer timeout value, there may be an attractive attack
   vector against the PIT memory.  Moreover, especially when the full
   discovery request option (Section 5.3) is specified for the CCNinfo
   Request, several Reply messages may be returned and cause a response
   storm.  (See Section 10.8 for rate-limiting to avoid the storm).  To
   avoid DoS attacks, routers MAY configure the timeout value, which is
   shorter than the user-configured CCNinfo timeout value.  However, if
   it is too short, the Request may be timed out and the CCNinfo user
   does not receive all Replies; s/he only retrieves the partial path
   information (i.e., information about a part of the tree).

   There may be a way to enable incremental exploration (i.e., to
   explore the part of the tree that was not explored by the previous
   operation); however, discussing such mechanisms is out of scope of
   this document.

10.7.  Limiting Request Rates

   A router MAY rate-limit CCNinfo Requests by ignoring some of the
   consecutive messages.  The router MAY randomly ignore the received
   messages to minimize the processing overhead, i.e., to keep fairness
   in processing requests, or prevent traffic amplification.  In such a
   case, no error message is returned.  The rate limit function is left
   to the router's implementation.

10.8.  Limiting Reply Rates

   CCNinfo supporting multipath forwarding may result in one Request
   returning multiple Reply messages.  To prevent abuse, the routers in
   the traced path MAY need to rate-limit the Replies.  In such a case,
   no error message is returned.  The rate limit function is left to the
   router's implementation.

10.9.  Adjacency Verification

   It is assumed that the CCNinfo Request and Reply messages are
   forwarded by adjacent neighbor nodes or routers.  The CCNx message
   format or semantics do not define a secure way to verify the node/
   router adjacency, while HopAuth [10] provides a possible method for

Asaeda, et al.          Expires January 13, 2022               [Page 33]
Internet-Draft                   CCNinfo                       July 2021

   an adjacency verification and defines the corresponding message
   format for adjacency verification as well as the router behaviors.
   CCNinfo MAY use a similar method for node adjacency verification.

11.  Acknowledgements

   The authors would like to thank Spyridon Mastorakis, Paulo Mendes,
   Ilya Moiseenko, David Oran, and Thierry Turletti for their valuable
   comments and suggestions on this document.

12.  References

12.1.  Normative References

   [1]        Mosko, M., Solis, I., and C. Wood, "CCNx Messages in TLV
              Format", RFC 8609, July 2019.

   [2]        Mosko, M., Solis, I., and C. Wood, "CCNx Semantics",
              RFC 8569, July 2019.

   [3]        Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [4]        Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", May 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [5]        Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

12.2.  Informative References

   [6]        Asaeda, H., Matsuzono, K., and T. Turletti, "Contrace: A
              Tool for Measuring and Tracing Content-Centric Networks",
              IEEE Communications Magazine, Vol.53, No.3, pp.182-188,
              March 2015.

   [7]        Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and
              D. Oran, "ICN Ping Protocol Specification", draft-irtf-
              icnrg-icnping-02 (work in progress), April 2021.

Asaeda, et al.          Expires January 13, 2022               [Page 34]
Internet-Draft                   CCNinfo                       July 2021

   [8]        Mastorakis, S., Gibson, J., Moiseenko, I., Droms, R., and
              D. Oran, "ICN Traceroute Protocol Specification", draft-
              irtf-icnrg-icntraceroute-02 (work in progress), April
              2021.

   [9]        Asaeda, H., Mayer, K., and W. Lee, "Mtrace Version 2:
              Traceroute Facility for IP Multicast", RFC 8487, October
              2018.

   [10]       Li, R. and H. Asaeda, "Hop-by-Hop Authentication in
              Content-Centric Networking/Named Data Networking", draft-
              li-icnrg-hopauth-02 (work in progress), February 2020.

   [11]       Li, R., Matsuzono, K., Asaeda, H., and X. Fu, "Consecutive
              Caching and Adaptive Retrieval for In-Network Big Data
              Sharing", Proc. IEEE ICC, Kansas City, USA, May 2018.

   [12]       Asaeda, H., Ooka, A., Matsuzono, K., and R. Li, "Cefore:
              Software Platform Enabling Content-Centric Networking and
              Beyond", IEICE Transaction on Communications, Vol.E102-B,
              No.9, pp.1792-1803, September 2019.

   [13]       "Cefore Home Page", <https://cefore.net/>.

Appendix A.  ccninfo Command and Options

   CCNinfo is implemented in Cefore [12][13]. "ccninfo" is the command
   invoked by the CCNinfo user (e.g., consumer).  The ccninfo command
   sends the Request message and receives the Reply message(s).  There
   are several options that can be specified with ccninfo, while the
   content name prefix (e.g., ccnx:/news/today) is the mandatory
   parameter.

   The usage of ccninfo command is as follows:

   Usage: ccninfo [-c] [-f] [-o] [-V] [-r hop_count] [-s hop_count] [-v
          algo] name_prefix

   name_prefix
      Prefix name of content (e.g., ccnx:/news/today) or exact name of
      content (e.g., ccnx:/news/today/Chunk=10) the CCNinfo user wants
      to trace.

   c option
      This option can be specified if a CCNinfo user needs the cache
      information as well as the routing path information for the
      specified content/cache and RTT between the CCNinfo user and
      content forwarder.

Asaeda, et al.          Expires January 13, 2022               [Page 35]
Internet-Draft                   CCNinfo                       July 2021

   f option
      This option enables the "full discovery request"; routers send
      CCNinfo Requests to multiple upstream faces based on their FIBs
      simultaneously.  The CCNinfo user can then trace all possible
      forwarding paths.

   o option
      This option enables to trace the path to the content publisher.
      Each router along the path to the publisher inserts each Report
      block and forwards the Request message.  It does not send Reply
      even if it caches the specified content.  FHR that attaches the
      publisher (who has the complete set of content and is not a
      caching router) sends the Reply message.

   V option
      This option requests the Reply sender to validate the Reply
      message with the Reply sender's signature.  The Reply message will
      then include the CCNx ValidationPayload TLV.  The validation
      algorithm is selected by the Reply sender.

   r option
      Number of traced routers.  This value is set in the "HopLimit"
      field located in the fixed header of the Request.  For example,
      when the CCNinfo user invokes the CCNinfo command with this
      option, such as "-r 3", only three routers along the path examine
      their path and cache information.

   s option
      Number of skipped routers.  This value is set in the "SkipHop"
      field located in the Request block TLV.  For example, when the
      CCNinfo user invokes the CCNinfo command with this option, such as
      "-s 3", three upstream routers along the path only forward the
      Request message but do not append their Report blocks in the hop-
      by-hop header and do not send Reply messages despite having the
      corresponding cache.

   v option
      This option enables the CCNinfo user to validate the Request
      message with his/her signature.  The Request message will include
      the CCNx ValidationPayload TLV.  The validation algorithm is
      specified by the CCNinfo user.

Authors' Addresses

Asaeda, et al.          Expires January 13, 2022               [Page 36]
Internet-Draft                   CCNinfo                       July 2021

   Hitoshi Asaeda
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: asaeda@nict.go.jp

   Atsushi Ooka
   National Institute of Information and Communications Technology
   4-2-1 Nukui-Kitamachi
   Koganei, Tokyo  184-8795
   Japan

   Email: a-ooka@nict.go.jp

   Xun Shao
   Kitami Institute of Technology
   165 Koen-cho
   Kitami, Hokkaido  090-8507
   Japan

   Email: x-shao@mail.kitami-it.ac.jp

Asaeda, et al.          Expires January 13, 2022               [Page 37]