KR20150114404A - System and method for device registration and discovery in content-centric networks - Google Patents

Abstract

One embodiment of the present invention provides a system for device registration and discovery in a content-centric network (CCN). During operation, the system receives, by a computer, an interest for registration of a client device. The Interest includes at least a unique identifier associated with the client device. In response to the interest, the system generates a content object, which includes at least a name assigned to the client device; and sends the content object to the client device, thereby enabling the client device to be discovered by other client devices in the CCN.

Description

[0001] SYSTEM AND METHOD FOR DEVICE REGISTRATION AND DISCOVERY IN CONTENT-CENTRIC NETWORKS [0002]

This disclosure generally relates to a content-centric network (CCN). More particularly, this disclosure relates to systems and methods for device registration and discovery within a content-centric network (CCN).

The proliferation of the Internet and electronic commerce continues to accelerate the revolutionary changes in the network industry. Today, a significant number of information exchanges are conducted online, ranging from online movie viewing to daily news delivery, consumer sales, and instant messaging. Increasing Internet applications are also becoming mobile. However, the current Internet operates mainly in a location-based addressing scheme. The two most common protocols, Internet Protocol (IP) and Ethernet protocols are both based on end-to-end addresses. That is, a consumer of content can only receive content by explicitly requesting content from an address (e.g., an IP address or an Ethernet media access control (MAC) address) typically associated with a physical object or location. Limited addressing techniques are becoming increasingly inadequate to meet ever-changing network demands.

Recently, an information-centric network (ICN) architecture has been proposed in industries where content is directly named and handled. A content-centric network (CCN) brings a new approach to content delivery. Instead of having network traffic observed at the application level as an end-to-end conversation over which content is moving, content is requested or returned based on its unique name, and the network is moved from the provider to the consumer The content is routed. Note that the content includes data that can be transmitted in a communication system, including the format of data, such as text, images, video and / or audio. Consumers and providers can be automation processes inside or outside the CCN or around the computer. The portion of the content may refer to the entire content or each portion of the content. For example, a newspaper article may be represented as a portion of a plurality of content that is implemented as a data packet. Portions of content may also be associated with metadata describing or augmenting portions of the content with information such as an authentication date, a creation date, a content owner, and the like.

In CCN, names have an important role. More specifically, the content objects and interests are identified by their names, which is typically a hierarchically structured variable-length identifier (HSVLI). The interrest and content objects flow through the network based on their name. When the computing device first joins the CCN network, it needs to know where to deliver the inter- est message and also know what name or name prefix is to be included in the inter- est message to be sent in order to obtain the underlying service in the new environment . In addition, the device must register itself with the CCN network.

One embodiment of the present invention provides a system for device registration and discovery in a content centric network (CCN). During operation, the system receives, by the computer, an interface for registration of the client device. The at least one identifier associated with the client device. In response to the interleaving, the system generates a content object, which includes at least a name assigned to the client device, and by sending the content object to the client device, To be discovered by the user.

In one variation of this embodiment, the interrest further includes at least one of a public key associated with the client device, a device type, a device model number, and a device identifier in any format.

In one variation of this embodiment, the content object includes a name prefix that can be routed to the client device, a subdirectory device-discovery namespace, one or more namespaces for the client device to publish data , And optionally, a namespace for the client device to obtain a signature key.

In one variation of this embodiment, the interrest has a pre-determined name prefix.

In another variation, the system notifies the client device of the pre-determined name prefix during an initial configuration of the client device.

In another variation, the pre-determined name prefix is provided by the manufacturer of the client device.

In one variation of this embodiment, the system updates the device database by adding the client device using the assigned name.

In another variation, the system receives additional interrupts for discovery of other devices within the CCN. In response to the additionalinterest, the system creates a device-list content object based on the information stored in the device database and returns the device-list content object.

In another variation, the system performs a security check to determine whether the device transmitting the additional interrest is authorized to obtain the device-list content object. In response to the determination that the device transmitting the additionalinterest is authorized to obtain the device-list content object, the system sends the device-list content object to the authorized device.

Figure 1 shows a network architecture, in accordance with an embodiment of the present invention.
Figure 2 shows a diagram representing an architecture of a CCN Dynamic Namespace Configuration Protocol (DNCP) client, in accordance with an embodiment of the present invention.
FIG. 3 is a diagram illustrating an architecture of a CCN-DNCP server according to an embodiment of the present invention.
4 is a flow diagram illustrating a server process for dynamic namespace configuration, in accordance with one embodiment of the present invention.
5 is a flow diagram illustrating a client process for dynamic namespace configuration, in accordance with one embodiment of the present invention.
Figure 6 is a diagram illustrating the architecture of a device-discovery intermediary, in accordance with an embodiment of the present invention.
7 is a flow diagram illustrating a device-registration process performed by a device-discovery intermediary, in accordance with an embodiment of the present invention.
8 is a flow diagram illustrating a device-discovery process performed by a device-discovery intermediary, in accordance with an embodiment of the present invention.
Figure 9 shows a system for device registration and discovery, in accordance with an embodiment of the present invention.
In the drawings, like reference numerals refer to the same drawing elements.

Embodiments of the present invention provide a system and method for device registration and discovery within a CCN. This solution allows new "out-of-the-box" devices to register themselves with the network to issue their devices, and existing devices are newly registered Allowed devices to be discovered. Also, if the new device has a name prefix that can be routed and it is to be reached under that name prefix, then the appropriate intercept message for that name prefix can be routed to this device. It can also start serving (or issuing) content under one or more authorized name prefixes. More specifically, when the device is a new "out-of-the-box ", or when introduced into a new CCN environment, it obtains the namespace of the registration service and device-discovery service as part of its initial configuration. Subsequently, it may send an inter-message containing the necessary registration information to the namespace of the registration service. If the registration service determines that all necessary information is provided by the interleaved message, the registration service returns the content object to the device and includes the device name and other information associated with the device name in the device database. The device may also send an inter-message to the device-discovery service namespace, which returns a content object. The returned content object optionally lists all registered devices in the network.

In general, CCNs use two types of messages: interlaces and content objects. The interpreter carries a hierarchically structured variable-length identifier (HSVLI), also referred to as the "name" of the content object, and is provided as a request to the object. If a network element (e.g., a router) receives multiple interlaces for the same name, it aggregates these interlaces. A network component along the path of the inter- est with the matching content object may cache and return the object to satisfy the inter- est. The content object follows the reverse path of the intercept to the origin (s) of the interlace. The content object includes, among other information, the same HSVLI, payload of the object, and encryption information used to bind the HSVLI to the payload.

The terms used in this disclosure are generally defined as follows (but their interpretation is not so limited).

"HSVLI:" is a hierarchically structured variable-length identifier (HSVLI), also called a name. This is an ordered list of name components and can be a variable-length octet string. In a human-readable format, this can be expressed in the same format as ccnx: / path / part. In addition, HSVLO may not be human readable. As mentioned above, HSVLI refers to content, and it is desirable that they represent an organizational structure for content and at least partially meaningful to humans. Each component of the HSVLI may have any length. In addition, HSVLI may have explicitly partitioned components, may contain a sequence of bytes, and are not limited to human-readable characters. The longest-prefix-matching lookup is important in delivering packets with HSVLI. For example, an HSVLI representing an interlude in "parc / home / bob" would match "parc / home / bob / test.txt" and "parc / home / bob / bar.txt". In the context of the number of name components, the longest match is considered the best because it is the most obvious. A detailed description of HSVLI can be found in U.S. Patent No. 8,160,069 entitled " SYSTEM FOR FORWARDING A PACKET WITH A HIERARCHICHALLY STRUCTURED VARIABLE-LENGTH IDENTIFIER ", filed September 23, 2009 by inventors Van L. Jacobson and James D. Thornton Can be found in

"Interrest:" Request for a content object. The interrest specifies an HSVLI name prefix and other option selectors that can be used to select among a plurality of objects having the same name prefix. A content object that has a name that matches an interrest name prefix (and optionally other required parameters such as issuer key-ID matching) satisfies the interleaves.

"Content Object:" Data object sent in response to an < / RTI > It has an HSVLI name and content payload tied together through a cryptographic signature. Optionally, all content objects have an implicit terminal name component consisting of an SHA-256 digest (digest) of the content object. In one embodiment, the implicit digest is not transmitted over the wire, and is calculated at each hop, if necessary.

"Face": In CCN, the term face is a generalization of the concept of an interface. The face may be a connection to the network or directly to the application portion. The face can be used to send and receive broadcast or multicast packets on a particular network interface, or to use point-to-point addressing within the underlying transport, or to use a tunnel (for example, a TCP tunnel) And transmit and receive packets. The pace may also be a connection to an encapsulation scheme such as UDP or to a single application process running on the same device via an OS-specific inter-process communication path. All messages arrive through the face and are transmitted through the face.

As mentioned earlier, HSVLI includes a contiguous component that points to a portion of the content, is hierarchically structured, and is ordered from the most general level to the most specific level. The length of each HSVLI is not fixed. In a content-centric network, unlike conventional IP networks, packets can be identified by HSVLI. For example, "abcd / bob / papers / ccn / news" may be the name of the content and may be a newspaper for a user named "Bob " in the corresponding packet (s) News "articles from the collection" ccn " In order to request a portion of the content, the node expresses (e.g., broadcasts) an interrelation in the content by the name of the content. The interrelation of a portion of the content may be a name for the content according to the name or identifier of the content. The content may be sent back to the requesting node from the node storing the content if it is available in the network. The routing infrastructure propagates the inter- est to the expected node with information and then carries the available content along the reverse path traversed by the inter- est message. Essentially, the content object follows the trace left by the inter- est message and arrives at the requested node.

Figure 1 shows a network architecture, in accordance with an embodiment of the present invention. In this example, the network 180 includes nodes 100-145. Each node in the network is connected to one or more other nodes. Network connection 185 is an example of such a connection. Network connections are represented by lines, but each line may also represent a sub-network or a super-network connecting one node to another. Network 180 may be content-centric, local network, super-network, or sub-network. Each of these networks may be interconnected such that the nodes in one network can reach the nodes in the other network. The network connection may be broadband, wireless, telephone, satellite, or any other type of network connection. A node may be a computer system, an end-point representing a user, and / or a device capable of creating aninterest or creating content.

In accordance with one embodiment of the present invention, a consumer may create an interpreter for a portion of the content and deliver the interpreter to a node in the network 180. Portions of the content may be stored in a node within the network 180 by an issuer or content creator that may be located inside or outside the network. For example, in FIG. 1, the interes within the portion of the content originate at node 105. If the content is not available at the node, the interpreter flows to one or more nodes connected to the first node. For example, in FIG. 1, an interpreter flows to node 115 (an interrupted flow 150), which does not have any available content. Next, the interpreter flows from the node 115 to the node 125 (the interrupted flow 155), which also has no content. Next, the interpreter flows to node 130 (interref flow 160), which has available content. The flow of the content object then reverses its path (content flows 165, 170, and 175) until the next node 105 is reached, where the content is delivered. Other processes such as authentication can be included in the content flow.

In the network 180, any number of intermediate nodes (nodes 100-145) in the path between the content holder (node 130) and the inter-generating node (node 105) caching. Caching implicitly shares access to locally cached content, thereby alleviating the network load on the second subscriber adjacent to the other subscriber.

Within the CCN, each node maintains three main data structures, which include a forwarding information base (FIB), a content store (CS), and a pendinginterest table (PIT).

The FIB can be used to deliver the intercepted packets to the potential source (s) of the matching content object. Typically, a routing protocol can be used to populate the FIB between all nodes in the network. A FIB entry is often indexed by a name prefix, with each entry containing a physical address of at least one face for which a matching interlace should be delivered. During the delivery of the inter- est message, the longest-prefix-matching lookup of the name is performed in the FIB to find the matching entry.

The content store (CS) is similar to a buffer memory used by an IP router. More particularly, the CS temporarily buffers the content objects passing through this node, allowing for efficient data retrieval by different consumers. When a router receives an interlaced packet, it first checks whether there is a matching content object in its content repository.

The pendinginterest table (PIT) tracks the upstream delivered to the content source (s) and allows the returned content object to send downstream to its requestor (s). Only intra-CC packets within the CCN are routed. The returned content object follows the traces of the intercepted packets going to the content requestor. The PIT entry for the interrest specifies the name of the interlace and one or more incoming faces that requested the interlace.

When the interlaced packet reaches a certain pace, the longest-matching lookup is performed based on the content name or HSVLI. The index structure used for name lookups is arranged in a way that CS matching is preferred to PIT matching, which would be preferred over FIB matching. Thus, if there is already a content object matching the interlace in the CS, the content object will be transmitted over the pace reached by the interlace and the interlace will be discarded. Otherwise, the PIT will be checked to see if a match can be found. If so, the reach pace of the intercept will be added to the request face list of the PIT entry, and the intercept will be discarded. Otherwise, the FIB is checked and the intercept is delivered along one of the more paces listed in the matching FIB entry.

As described above, packets (including inter- ests and content objects) within the CCN flow through the network based on their name prefix. When the device is initialized (for the first time or when it joins the network), the device must notify other devices of the network of its presence and inform the network router of the physical address of its pace. For example, when a sensor (e.g., a thermometer) is first installed in the home, the sensor should be configured to know where to transmit its data. Similarly, when a laptop or tablet computer is moved from a home environment to a coffee shop, the computer has to know where to send itsinterest, and optionally tells other devices on the network how to reach it. Although it is possible to manually configure the device during initialization, the existing CCN protocol has no solution for automated device initialization.

In existing Internet Protocol (IP) networks, Dynamic Host Configuration Protocol (DHCP) is used to dynamically configure network configuration parameters, such as IP addresses for interfaces and services. More specifically, DHCP allows a computer to automatically request an IP address and networking parameters from a DHCP server, thereby reducing the need for the network administrator or user to manually configure the settings. A similar mechanism is needed within the CCN to initialize the device when it first comes online or when it is introduced to a new environment. More specifically, in order for the device to function properly in the CCN network, the device must know where to send the interleaved packet to receive the particular service. Since the CCN relies on the name prefix to move the packet, the initial configuration of the device will include the configuration of the namespace. For example, the device may set default forwarding information within the FIB (which may include one or more appropriate entries), or may include a name of various services such that a request for such a service may be properly delivered Space needs to be configured. Also, in order to obtain this service, the device must know the name or name prefix that is included in the appropriate inter- est message. Examples of these services include, but are not limited to, device registration, service discovery, authentication services that authorize keys, and the like.

To provide an automated solution to device initialization, in some embodiments, the system implements a Dynamic Namespace Configuration Protocol (DNCP), for example, a default forwarding entry, a device registration and discovery service namespace, Such as the namespace of the service (bypass) service, for the proper functioning of the device. Note that in order for DNCP to work properly, the following conditions must be met: First, each device must perform a basic CCN stack and be able to create and process CCN inter- ests and content objects. Second, the device can be manually configured or automatically set up a basic network connection (including, but not limited to, Ethernet, WiFi, Bluetooth, etc.). Third, each device should be provided with a unique device identifier supplied by the manufacturer, which is similar to a media access control (MAC) address. Note that such a device ID may be 16 or 32 bytes long, or it may be any length. It can also take the format defined by the device manufacturer. For example, each temperature sensor manufactured by a particular manufacturer may have a unique ID issued by the manufacturer. In addition, each device must be pre-loaded with a signature key, such as a public-private key pair, a symmetric key, or any other signature key that meets CCN requirements, in order to sign the content object it intends to issue. If the device is not pre-configured with such keys, then the DNCP service should convert the device to the appropriate service and obtain or authenticate its key by specifying the name of this service.

Figure 2 shows a diagram representing an architecture of a CCN Dynamic Namespace Configuration Protocol (DNCP) client, in accordance with an embodiment of the present invention. 2, the CCN-DNCP client 200 includes a plurality of paces, an interface generation module 208, a delivery module 210, a reception module 212, A base (FIB) 214 and a namespace configuration module 216.

The paces 202-206 may include not only a physical interface but also an application process capable of sending and receiving packets. The interrest creation module 208 is responsible for generating an intercept packet, which may be a request for content or service. In some embodiments, the inter-create module 208 is configured to generate a "HELLO" INTERRESS message, which can be used to request a DNCP service. In another embodiment, a "HELLO" interrest message is generated in a pre-determined namespace. That is, the system predefines and holds the namespace for DNCP purposes (such as "/ hello"), and the CCN-DNCP client 200 is preconfigured (by the CCN stack running on the machine) in this namespace. Note that if the predefined DCNP namespace is "/ hello", then the "HELLO" interpreter has the namespace as "/ hello".

The delivery module 210 is responsible for delivering packets, such as interrests and content objects, to various paces on the CCN-DNCP client 200. In accordance with the CCN protocol, the delivery module 210 delivers the content based on the entry in the FIB 214 and delivers the content object based on the entry in the PIT (not shown in Fig. 2). In some embodiments, the delivery module 210 is configured to deliver (or broadcast) the "HELLO" interpreter to all paces on the DNCP client 200. The FIB 214 stores information conveying the interrest. Entries in the FIB 214 are sometimes indexed with a name prefix. In some embodiments, the FIB 214 may be pre-populated with default entries (during the initialization process) and the delivery module 210 may use these default entries to deliver the interleaves.

Receiving module 212 is responsible for receiving packets containing interlaces and content objects from various faces. For example, the receiving module 212 may receive the content object in response to an already transmitted interlace. In some embodiments, the receiving module 212 may receive a response to the "HELLO" The DNCP response includes a default entry for the FIB 214 and a list of service attributes for device registration and discovery, service discovery, a pool service to obtain a signature key or hash for the content name, a key service, a print service, But is not limited to, a namespace for various services, such as a network service.

The default entry for the FIB 214 may specify the physical address of the detour forwarder, which may be a DMZ (unarmed area) router and may have MAC addresses 00: 01: 02: 03: 04: 05. Thus, the inter- ests in the root namespace "/" can be passed to the default forwarder. Other default entries may specify the physical address of the local router and its matching namespace. For example, an additional default entry may map the name prefix "/ abc" to the MAC address 12: 34: 56: 78: 9A: 9B, Address 12: 34: 56: 78: 9A: 9B.

The namespace configuration module 216 is responsible for configuring the namespace on the CCN-DNCP client 200 based on the DNCP response. Once the namespace is properly configured, the inter-create module 208 may appropriately generate various service requests (in the form of aninterest), and the delivery module 210 may forward the service request to the appropriate destination . For example, if the DNCP response specifies that the namespace for the device-discovery service provided in room 2015 is "/ devices / room2015", then the inter-create module 208 will generate a name prefix "/ devices / room2015" And the delivery module 210 can deliver this interlace based on the name prefix. The system may also use a substructure scheme to refine the device-discovery space based on the device type. For example, the namespace "/ devices / room2015 / thermometers" can be used to find all the thermometers in room 2015. Other additional namespaces may also be included in the DNCP response, allowing the namespace configuration module 216 to properly configure these namespaces. For example, the network may include a printer, and a DNCP response to a new client device may declare the namespace for the printer service as "/ abc / printer". When a new device attempts to print a document, it can send its print request to the namespace "/ abc / printer ". Note that the forwarding information associated with the namespace is stored in the FIB 214.

FIG. 3 is a diagram illustrating an architecture of a CCN-DNCP server according to an embodiment of the present invention. 3, the CCN-DNCP server 300 includes a number of paces, such as the paces 302, 304, and 306, a packet-processing module 308, a DNCP listener 310, a DNCP- A database 314, and a delivery module 316.

The faces 302-306 are similar to the faces 202-206 and may include physical interlaces and application processes. The packet-processing module 308 is responsible for processing the received packets on various faces. In some embodiments, the packet-processing module 308 extracts the name prefix of the received packet. In another embodiment, if the name prefix of the receivedinterest is within a predetermined DNCP namespace (e.g., a "/ hello" namespace), the packet-processing module 308 sends the interpreter to the DNCP listener 310, , Which listens to the inter- ests within the predetermined namespace. In the example mentioned above, the predetermined DNCP namespace is "/ hello ". When the DNCP listener 310 receives a "HELLO" INTEREST message in the predetermined DNCP namespace, the CCN-DNCP server 300 determines that the node receiving the "HELLO" In response to the DNCP request, the DNCP-response-generation module 312 generates an appropriate DNCP response, in the form of a content packet, based on the information stored in the DNCP database 314. The DNCP database 314 stores various namespace configuration information, such as default FIB entries, device registration and discovery, namespace for network service discovery, resolution service namespace, key service namespace, and the like. The namespace for device registration and discovery permits the client device to send a registration or device-discovery interleaved message to the server. The service discovery namespace allows the client device to send an intercept message to discover available network services. The resolution service's namespace allows the client device to send an intercept message to the namespace to obtain a hash of the issuer key or content name. The namespace of the key service permits the client device to send an INTEREST message to obtain an authenticated signing key, if the client device has not been pre-loaded with an authentication key. Note that since the network environment varies over time, the DNCP response packet may optionally include a lease time for each namespace, thereby indicating how long the namespace will remain valid. In such a scenario, the client device must periodically send DNCP interrupts to ensure that their namespace configuration is still valid, and update their namespace configuration, if necessary. Note that because the client device has received a previous DNCP response, the DNCP interpreter can be sent directly to the DNCP service without having to re-broadcast the DNCP inter- est.

The generated DNCP response packet (as a content object) is forwarded back to the incoming face of the "HELLO" interlace by the forwarding module 316 to ensure that the response packet is forwarded back to the original node of the " HELLO " .

The configuration information stored in the DNCP database is too much for a single content object, or the configuration information includes a plurality of sectors, some of which are essential for device operation, some of which are optional. For example, the default FIB entry is mandatory configuration information, while the printer service is optional. In some embodiments, the DNCP-response-generation module 312 may generate a DNCP content object that includes instructions that allow the client device to gain additional configuration information. For example, when a client device sends a first "HELLO" -received to the CCN-DNCP server 300, the DNCP-response-generation module 312 (the default FIB entry and the namespace for device registration And the like). ≪ / RTI > The DNCP content object may indicate that more DNCP information is available, and may specify a namespace associated with additional DNCP information. Thus, in order to obtain additional information, the client device may send an additional DNCP request to a particular namespace. For example, the initial DNCP response to the client device indicates that the printing service is available, and to obtain the namespace for the printing service, the client device sends a new "HELLO" Must be sent to the namespace. Similarly, if the available DNCP information occupies a plurality of content objects, the first content object sent to the client device may include a new "HELLO" "You can tell it to send to the namespace.

4 is a flow diagram illustrating a server process for dynamic namespace configuration, in accordance with one embodiment of the present invention. During operation, the system hears interlaced in a predetermined namespace (act 402) and determines whether a predetermined inter- est with a name prefix in this namespace has been received from the client device (act 404). For example, the predetermined namespace may be a DNCP namespace, such as "/ hello ", and the predetermined DNCP interface may be a predefined" HELLO "packet. In some embodiments, the format of the DNCP namespace and the "HELLO" interface is preconfigured by the CCN protocol running on the server and client device.

If the system receives a DNCP request, the system generates a DNCP response (operation 406), and sends the DNCP response to the original node of the DNCP (operation 408). The DNCP response also includes a default FIB entry (such as the default face at which the client device can send its inter- est) and a namespace for various services. In some embodiments, the DNCP interpreter indicates the type of service requested by the client, and a DNCP response is generated based on the requested service. For example, the DNCP interpreter may indicate that the original node does not have a signing key. In response, the DNCP response includes the namespace of the key service, in which the client can send an intercept to obtain the signing key.

5 is a flow diagram illustrating a client process for dynamic namespace configuration, in accordance with one embodiment of the present invention. During operation, a client device joining a new environment or first introducing online first broadcasts a DNCP request message on all its faces (act 502). In some embodiments, the DNCP request message is an intercept packet having a name prefix in a predefined namespace. The predefined namespace may be a namespace specifically reserved for the DNCP service. For example, the system may have a namespace " / hello "for the DNCP service. The DNCP or "HELLO" interpreter has the name prefix "/ hello". Since the DNCP inter- est (or "HELLO" inter- est) is broadcast on all paces of the client device, the DNCP service either directly receives the "HELLO" Quot; HELLO " In some embodiments, other devices (such as other client devices) in the network environment, such as those in a network environment, that have the delivery information set to perform the tasks of the bridge, or to allow devices to receive the "HELLO" Lt; / RTI >

The client device then receives a DNCP response packet from the DNCP service (act 504). The DNCP response packet is in the form of a content object. In some embodiments, the name of the DNCP content object matches the name of the inter- est message, such as "/ hello. &Quot; The DNCP content object may include information that may be used to configure the client device, such as the default FIB entry and various namespaces that the client device may use to obtain the required service. Upon receiving the DNCP response, the client device fills its FIB with a default entry and configures its namespace (act 506). Once the FIB is populated with the default entry and the namespace is configured, the client device may create an interpreter with the appropriate name prefix to obtain the service.

In some embodiments, the namespaces included in the DNCP response have lease times (such as one or ten days), which means they are only valid for a certain predetermined period of time. In such a scenario, the client device may determine whether the lease time has expired (operation 508) and may retransmit the DNCP interpreter to obtain the latest configuration settings (act 502).

In the example shown in FIGS. 2-5, note that the DNCP request is answered by the DNCP server or server process. In fact, it is also possible to have a DNCP-response process running in a cluster of computers. Best of all, you can have other peer client computers in the CCN network to respond to DNCP inter- views. In some embodiments, the peer client machine may respond to a DNCP < RTI ID = 0.0 > For example, the content object may provide a different DNCP namespace (different from the namespace of the DNCP interpreter) from which the requesting client may send a DNCP request. This re-switching content object may also include configuration information of other client devices in the CCN network. For example, a client device joining a CCN network sends a DNCP < Desc / Clms Page number 2 >interest to the "/ hello" namespace and receives a content object from an existing peer client device in the CCN network. The content object indicates that the new client device should send a new DNCP interface to the namespace "/ name-abc" in order to obtain configuration information. In addition, the content object may specify that another peer device on the network should use the "/ device-discovery" namespace for registration of the new device and discovery of other new devices on the network.

Once the client device receives the necessary namespace configuration information, it can send the interlace packet to the appropriate namespace to obtain the service, such as device registration and discovery. Registration of the device is necessary to allow the device to issue its data under one or more authorized name prefixes, and / or allow other devices on the network to reach the device. Moreover, registration permits verifying whether the device is allowed on the network and whether the device requires another authentication / security process. In some embodiments, in order for the network to register and discover new devices, all device registration and configuration services are configured to listen to the inter- est messages within a particular namespace. This particular namespace can be pre-defined and agreed upon. During the registration process, the new device may send an interlaced message to this particular namespace, having the device ID contained in the interlaced message and other information associated with the device. A service (e.g., a device-registration service or a device-discovery service) authorized to respond to these interleaved messages may respond with a content object. The content object provides additional information that can be used by the device to identify the device ID and issue its data.

In some embodiments, the device-discovery arbiter assigns a name to a device in the network and provides a namespace where the device can issue their data. To do so, the device-discovery arbiter needs to manage the device-discovery namespace schema, which includes an organized namespace structure that can represent various types of devices. In addition, the device-discovery arbiter supports discovery of other devices within the same CCN network.

The device-discovery namespace schema facilitates device discovery within the network by organizing namespaces associated with various types of devices in a meaningful manner. There are several techniques for dealing with device-discovery namespace schemas. One option is to select the name prefix as the root prefix for the device-discovery namespace. For example, the namespace "/ devices" can be used as a root prefix for all device-discovery services. Additionally, the sub-structure schema may be used to further refine the area of device discovery. For example, the namespace "/ devices / abc / room 2105" may be provided as a namespace prefix for all device-discovery services in room 2015 in the "/ abc" namespace.

In addition, the device-discovery namespace can be refined based on the device type using the sub-structure schema. For example, the namespace "/ devices / abc / printers" can be used to find new printers in the "/ device / abc" namespace, while "/ devices / abc / thermometers / room2105" It can be used for all device-discovery services related to thermometers in room 2015 in the space. The decision on how to create and manage the various sub-structures within the namespace can be handled by the device-discovery service.

The second option is that the devices have their own manufacturer-supplied namespace schema for device discovery. For example, all devices manufactured by the "def" company can use "/ devices / def" as their root prefix and send an intercept message to a specific namespace prefix. The device-discovery service listening on this root name prefix processes the intra-message.

It will be appreciated that the first and second options rely on a predetermined namespace scheme for device discovery. That is, the device is pre-configured with the device-discovery namespace (by the device manufacturer or by the CCN protocol performed by the device) and automatically transmits the inter- ests to the pre-configured device-discovery namespace.

The third option depends on the aforementioned DNCP service, which automatically configures the device-discovery namespace when the device is newly removed from the box or when it is first introduced into the environment. More specifically, the device broadcasts a "HELLO" interpreter on all of its faces within the DNCP namespace. The DNCP service responds to a "HELLO" interface having a content object that specifies the root name prefix of the device-discovery service (such as "/ abc / devices"). Once the device receives such a content object, it sends the inter- est message to the specific route name prefix for the device-discovery service.

Figure 6 is a diagram illustrating the architecture of a device-discovery intermediary, in accordance with an embodiment of the present invention. 6, device-discovery intermediary 600 may include a number of paces, such as pace 602, 604, 606, a packet-processing module 608, a listener 610, a device-registration module 612, A creation module 614, a namespace database 616, a device database 718, and a delivery module 620.

Pairs 602-606 are similar to faces 202-206 and may include physical interlaces and application processes. The packet-processing module 608 is responsible for processing packets received on various faces. In some embodiments, the packet-processing module 608 checks the name prefix of the received inter- est and sends the inter- est to the listener 610 if the name prefix of the inter- est is in the device-discovery namespace. Listener 610 listens to the intercept message on the root prefix of the device-discovery namespace, such as "/ abc / devices." The device-discovery namespace provides a registration service (with the name prefix "/ abc / devices / registration") for the device to register with the device-discovery intermediary 600 and allows the device to discover other devices on the network Note that it is possible to provide a discovery service with the name prefix "/ abc / devices / list", note that a new device must first be registered before it can be discovered by another device.

When the listener 610 receives the intra-message in the registration namespace, the device-registration module 612 registers the device that transmits the inter-post by extracting the information contained in the inter-message. In some embodiments, the interrest message for device registration includes various information associated with the device, including a device ID (which may be the only ID issued by the manufacturer), a public key used by the device for content signing (Or a reference to a public key), and a description of the device. The description of the device may include device type (such as a bulb or thermometer), model number, and the like. Based on the received registration context, the device-registration module 612 determines whether the intercept contains all of the information required for registration. If so, the response-creation module 614 creates a "registration confirmation" content object. The "registration confirmation" content object may include an assigned name of the device, and optionally a name prefix that can be routed to the device. For example, a registered thermometer can be given the name "/ thermometer-id-123" and optionally the name prefix "/ abc / Room2105 / thermometer-id-123" that can be routed. Other device-registration information may also be included in the "registration confirmation" content object, which may include a subdirectory namespace, a namespace for the device to issue data (or a namespace authorized for the device to issue) The device may include a namespace for authentication authority to obtain an authentication key, but is not limited thereto. In another embodiment, based on a security policy, once the device obtains a key (such as a public-private key pair) from a key service, the device must send a device name with its public key to the device-discovery intermediary 600 Note that you can. These namespaces are obtained from the namespace database 616. Note that the subdirectory namespace allows additional device-discovery services. For example, the subdirectory namespace "/ devices / abc / room 2105" allows device discovery in room 2015 within the namespace "/ abc ". The namespace for the thermometer for issuing the data may be "abc / Room 2105 / thermometer-id-123 / data ". Note that the response-generating module 614 is capable of generating a plurality of content objects, each of which includes a namespace that can be used by the client device to obtain portions of the device registration information and the next portion. That is, a chain of content objects may be formed such that each item contains a pointer to the next item.

If the device-registration module 612 determines that all necessary information has not been provided, the response-creation module 614 generates a "required information" content object that specifies what information the device needs to properly register itself do. The necessary information may include authentication information, key information, etc., in accordance with the specific security policy currently implemented by the device-discovery arbiter 600. The content object ("registration confirmation" or "necessary information") is returned to the device by the delivery module 620.

Once the device is registered, the device database 618 is updated to include the new device name and the registration information associated with the new device name. The device database 618 facilitates the process of discovering other devices on the network. During operation, when the listener 610 receives an inter- est message in the discovery service namespace (such as "/ abc / devices / list"), the response-generating module 614 generates, based on the information stored in the device database 618 Thereby creating a content object. In some embodiments, the content object may include a list of all currently registered devices in the network. In other implementations, proper authentication and encryption are part of the device-discovery process. For example, only a specific device is authorized to obtain a list of all registered devices. In addition, the registered client device may optionally hide itself so that it is not discovered by other client devices in the network.

In addition to initial registration and discovery, the client device also sends a periodic heartbeat message to the device-discovery intermediary 600 to allow the device-discovery intermediary 600 to send an updated current < RTI ID = 0.0 > The list can be maintained. In some embodiments, the listener 610 may listen to an interlaced message in a predetermined heartbeat namespace (which may be distributed to the device during initial device configuration). The heartbeat transmitted by the device must contain the device's assigned name and is signed with the device's key. Once the listener 610 receives such a periodic heartbeat message, the response-creation module 614 generates an acknowledgment content object, and the delivery module 620 sends the acknowledgment content object to the device.

7 is a flow diagram illustrating a device-registration process performed by a device-discovery intermediary, in accordance with an embodiment of the present invention. During operation, the device-discovery intermediary listens for a registration inter- est on the namespace of the registration service (act 702) and determines whether a registration inter- est has been received (act 704). If so, the device-discovery intermediary determines whether all the information needed to properly register the device is included in the registration interface (act 706). This information-checking operation includes an additional step of determining whether the device has previously been registered, and if so, determining whether a registration update is required. Above all, the device-discovery intermediary also performs a security check to ensure that the device is authorized to register itself to prevent malicious nodes from registering themselves in the network. If all necessary information is included and the device passes the security check, the device-discovery arbitrator generates a registration confirmation content object, which contains the name assigned to the device and includes a name prefix that can be optionally routed (Act 708). Note that the name prefix that can be routed allows the device to be reached by another device. For example, a laptop computer may receive a name "/ laptop" from a device-discovery intermediary and receive a name prefix "/ abc / laptop" Thus, another device can reach the laptop by sending an " / abc / laptop " Additional information that may be used by the device to discover other devices, issue data, and obtain a signature key may also be included in the registration confirmation content object. For example, the aforementioned laptop computer ("/ abc / laptop") is authorized to issue data under one or more name prefixes different from the routable name prefix assigned to the laptop, such as "abc / research / . This additional name prefix for data publication may also be included in the registration confirmation content object. The device-discovery intermediary then updates its device database (act 710), and sends a registration confirmation content object to the device (act 712). If all the necessary information is not provided by the registration interface, the device-discovery intermediary creates a required-information content object (act 714) and sends the content object back to the device to request additional information (act 716) .

8 is a flow diagram illustrating a device-discovery process performed by a device-discovery intermediary, in accordance with an embodiment of the present invention. During operation, the device-discovery intermediary listens for an interlace on the namespace of the discovery service (act 802) and determines whether the interlace has been received (act 804). If so, the device-discovery intermediary determines whether the intercept has been transmitted by the authorized device to receive the list of registered devices (act 806). To do so, the device-discovery intermediary can perform a security check based on the access information (e.g., key, user ID, password, etc.) included in the inter- est message. If the device passes the security check and is authorized to receive the device list, the device-discovery intermediary obtains a list of registered devices from the device database (act 808), and creates a content object containing the device list ) And sends the content object to the requesting device (act 812). If the device-discovery intermediary determines that the device is not authorized to receive the list of devices, it sends an error message (act 814).

The device-discovery intermediary may be a process performed on a stand-alone central server that handles device configuration and registration, or it may be a distributed process performed on a cluster of machines. Alternatively, it may be a process performed on any machine, which may be part of the client device. For example, within a CCN network, a client device may be capable of providing the necessary device registration and discovery services to other client devices.

Figure 9 shows a system for device registration and discovery, in accordance with an embodiment of the present invention. A system 900 for device registration and discovery includes a processor 910, a memory 920, and a storage 930. The storage 930 may be executed by a process 910 that typically stores instructions that can be loaded into the memory 920 and performs the methods described above. In one embodiment, the instructions of the repository 930 may implement a device-discovery intermediary module 932, a namespace database 934, and a device database 936, all of which may communicate with one another through various means .

In some embodiments, modules 932,934, and 936 may be implemented in hardware, either partially or entirely, and may be part of processor 910. [ Also, in some embodiments, the system may not include a separate processor and memory. Instead, in addition to performing their specific tasks, the modules 932, 934, 936 may be part of a general purpose or special purpose computing engine, either separate or cooperating.

The storage 930 stores programs executed by the processor 910. In particular, the repository 930 stores a program that implements a system (application) that facilitates device registration and discovery. During operation, the application program may be loaded into the memory 920 from the storage 930 and executed by the processor 910. [ As a result, the system 900 can perform the functions described above. The system 900 may be coupled to an optional display 980 (which may be a touch screen display), a keyboard 960, and a pointing device 970 and may also be coupled to the network 982 via one or more network interfaces .

The data structures and codes described in this specification are typically stored in a computer-readable storage medium, which may be an apparatus or medium capable of storing code and / or data for use by a computer system. The computer-readable storage medium may be a magnetic and optical storage device such as a volatile memory, a non-volatile memory, a disk drive, a magnetic tape, a CD (compact disk), a DVD (digital versatile disk or digital video disk) And other media capable of storing computer-readable media to be played back.

The methods and processes described in this Detailed Description section may be implemented as code and / or data and stored in a computer-readable storage medium, as described above. When a computer system reads and executes code and / or data stored in a computer-readable storage medium, the computer system is implemented as a data structure and code to perform the methods and processes stored in the computer-readable storage medium.

In addition, the methods and processes described above may be included in a hardware module or device. These modules or devices may be application specific integrated circuit (ASIC) chips, field-programmable gate arrays (FPGAs), dedicated software modules or dedicated or shared processors that execute portions of code at specific times, and / And other programmable-logic devices to be developed. When a hardware module or device is activated, they perform the methods and processes contained within them.

The above description is presented to enable one of ordinary skill in the art to make and use the embodiments, and is provided in the context of specific applications and requirements. Various modifications to the disclosed embodiments will be readily apparent to those skilled in the art to which the invention pertains and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit or scope of the disclosure. Accordingly, the present invention is not limited to the embodiments described herein but is to be accorded the widest scope consistent with the principles and features disclosed herein.

Claims (9)

A computer system for device registration and detection of a content centric network (CCN)
A processor; And
And a storage coupled to the processor and storing instructions for causing the processor to perform the method when executed by the processor, the method comprising:
Receiving, by a computer, an interest for registration of a client device, the intercept comprising at least a unique identifier associated with the client device;
Generating a content object in response to the interleaving, the content object including at least a name assigned to the client device; And
And sending the content object to the client device, thereby making it possible for the client device to be detected by other client devices in the CCN. 2. The method of claim 1,
A public key associated with the client device;
Device type;
Device model number; And
Device identifiers in any format
≪ / RTI > The method of claim 1, wherein the content object
A routable name prefix assigned to the client device;
Subdirectory device-discovery namespace;
One or more namespaces for which the client device issues data; And
Wherein the client device obtains a signature key from a namespace
≪ / RTI > The method according to claim 1,
Wherein the interrest has a pre-determined name prefix. 5. The method of claim 4,
The method further comprising, during an initial configuration of the client device, notifying the client device of the pre-determined name prefix. 5. The method of claim 4,
Wherein the pre-determined name prefix is provided by a manufacturer of the client device. The method according to claim 1,
The method further comprising updating the device database by adding the client device using the assigned name. 8. The method of claim 7,
Receiving an additionalinterest for detection of other devices in the CCN;
Generating a device-list content object based on the information stored in the device database, in response to the additionalinterest; And
And returning the device-list content object. 9. The method of claim 8,
Performing a security check to determine whether the device transmitting the additionalinterest is authorized to obtain the device-list content object; And
And sending the device-list content object to the authorized device in response to determining that the device transmitting the additional content is authorized to obtain the device-list content object.

Images