US20180145945A1

US20180145945A1 - Information centric network island bridging

Info

Publication number: US20180145945A1
Application number: US15/487,808
Authority: US
Inventors: Maruti Gupta Hyde; Eve M. Schooler; Srikathyayani Srikanteswara; Hassnaa Moustafa; Jeffrey Christopher Sedayao
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2016-11-21
Filing date: 2017-04-14
Publication date: 2018-05-24
Also published as: CN109863734B; US20180146071A1; US20190349445A1; US10805418B2; US20180146060A1; DE112017005885T5; US20180146058A1; US10785341B2; US20180145927A1; US20180146059A1; US10681166B2; US10979522B2; WO2018093813A1; US10848584B2; US11316946B2; US10244071B2; US11601522B2; CN109863734A; US20200059529A1; US10681167B2

Abstract

Systems and techniques for information centric network (ICN) island bridging are described herein. A request at an island domain node in an information centric network may be received. The request may include a data identifier. AN inter-domain discovery may be used to identify a destination domain corresponding to the data identifier. The request may be modified to create an inter-domain request. The inter-domain request may then be communicated to an inter-domain information centric network.

Description

CLAIM OF PRIORITY

This patent application claims the benefit of priority, under 35 U.S.C. § 119, to U.S. Provisional Application Ser. No., 62/424,985, titled “INFORMATION-CENTRIC NETWORKING METHODS AND APPARATUSES” and filed on Nov. 21, 2016, the entirety of which is hereby incorporated by reference herein.

TECHNICAL FIELD

Embodiments described herein generally relate to computer network communications and more specifically to information centric network (ICN) island bridging.

BACKGROUND

The Internet of Things (IoT) is an emerging class of devices and connections. Generally, IoT devices integrate components that may have previously lacked communication mechanisms with each other and other networked entities to widely provide access to the IoT device. Example IoT devices may include sensors, such as cameras, thermometers, moisture sensors, light sensors, motion sensors, and the like. Other IoT devices may include appliances (e.g., a refrigerator, oven, washing machine, dryer, water heater, water softener, etc.), home automation components (e.g., lights, thermostats, locks, doors, etc.), industrial automation e.g., machinery, lights, access mechanisms, etc.), and even furniture.
Some IoT installations are part of larger functional solutions and bundled as a product. For example, a security company may offer cameras, motion sensors, electronic locks, etc. as part of a security product in a home or business. Other products may include home automation (e.g., lights, thermostats, etc.), inventory management (e.g., radio frequency identification (RFID) readers), or workplace health and safety systems (e.g., equipment monitors, employee activity monitors, etc.). Several of these IoT based products may be installed in a single location or may have overlapping areas of operation (e.g., a security system and a home automation system may coexist in the same home).

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings, which are not necessarily drawn to scale, like numerals may describe similar components in different views. Like numerals having different letter suffixes may represent different instances of similar components. The drawings illustrate generally, by way of example, but not by way of limitation, various embodiments discussed in the present document.

FIG. 1 is a block diagram of an example of an environment including a system for ICN island bridging, according to an embodiment.

FIG. 2 illustrates an example of ICN island bridging, according to an embodiment.

FIG. 3 illustrates an example of an ICN and routing table, according to an embodiment.

FIG. 4 illustrates an example of an ICN and routing table, according to an embodiment,

FIG. 5 illustrates a flow diagram of an example of a method for ICN island bridging, according to an embodiment.

FIG. 6 is a block diagram illustrating an example of a machine upon which one or more embodiments may be implemented.

DETAILED DESCRIPTION

Different types of IoT installations (e.g., applications, products, functional domains, etc.) may exist within a single larger entity such as a business or a home for different purposes such as security, lighting, heating and cooling, etc. Although such systems may be physically located in the same building and belong to the same owner, they are often unable to interact directly with each other. That is, an IoT system providing a service, such as smart lighting, is typically designed as a vertically integrated system comprising the entire hardware and software stack. Thus, the system typically includes underlying sensing or actuating devices connected using either a wireless or a wired technology as appropriate with a user interface to allow users to interact with the system. Even if the system comprises multiple applications (e.g., light and temperature sensors in the same IoT system), it is commonly proprietary and closed.
The cause of inter-system interoperability is often a lack of a common framework to share data from one system to another. To address this issue, some have implemented application layer solutions using a customized application for interaction between the systems. This application layer approach generally involves designing interoperation between specific higher level application and involves more computational resources resulting in constrained (e.g., not general) or inefficient operations. A more general and lower-level (e.g., at the network layer) solution may result in better performance and efficiency than would otherwise be achieved. The Open Connectivity Consortium (OCF) is working to create an interoperability layer to work with different types of sensors. However, OCF is focusing on abstracting the underlying sensors to the IoT applications and there is little effort to bridge different IoT systems.
Achieving efficient IoT system interoperability may provide several benefits. For example, given a surveillance system that detects intrusion in a certain area of the home, the surveillance system may benefit from increased lighting in that area for better video quality. In this example, the surveillance system would benefit from being able to inform the lighting system about its requirements and coordinate activities such as increasing or decreasing the light intensity for a surveillance camera. The current lack of interoperability of disparate systems impedes this inter-system cooperation because details of the lighting system and its controls are not generally available to the surveillance system. It would, however, be significantly more efficient if such data were available within the network, as opposed to an application layer. An Information Centric Network (ICN) may be used to provide the missing interoperability functionality from current installations. If the data (e.g., control data or sensing data) were available at the ICN layer rather than at the application layer, efficiency and scalability of using this data between different IoT systems would be improved.
ICNs are emerging as a solution to some data congestion issues that wide-spread IoT device deployments may bring. ICN is an umbrella term for a new networking paradigm in which information itself is named and requested from the network instead of hosts (e.g., machines that provide information). In a host-based networking paradigm, such as used in the Internet protocol (IP), a device locates a host and requests content from the host. The network understands how to route (e.g., direct) packets based on the address specified in the packet. In contrast, ICN does not include a request for a particular machine, and does not use addresses. Instead, to get content, a device requests named content from the network itself. The content request may be called an interest and transmitted via an interest packet. As the interest packet traverses network devices (e.g., routers), a record of the interest is kept, for example, in a pending interest table. When a device with content matching the name in the interest is encountered, that device may send a data packet in response to the interest packet. Typically, the data packet is tracked back through the network to the source by following the traces of the interest left in the network devices.
Matching the named data in an ICN may follow several strategies. Generally, the data is named hierarchically, such as with a universal resource identifier (URI). For example, a video may be named www.somedomain.com/videos/v8675309. Here, the hierarchy may be the publisher, “www.somedomain.com,” a sub-category, “videos,” and the canonical identification “v8675309.” As an interest traverse an ICN, ICN equipment will generally attempt to match the name to a greatest degree. Thus, if an ICN device has a cached item or route for both “www.somedomain.com/videos” and “www.somedomain.com/videos/v8675309,” the ICN device will match the later for an interest packet specifying “www.somedomain.com/videos/v8675309.” In an example, an expression may be used in matching by the ICN device. For example, the interest packet may specify “www.somedomain.com/videos/v8675*” where ‘*’ is a wildcard. Thus, any cached item or route that includes the data other than the wildcard will be matched. In an example, additional meta-data may be attached to the interest packet, the cached data, or the route, to provide an additional level of matching. For example, the data name may be specified as “www.somedomain.com/videos/v8675309,” but also include a version number or timestamp, time range, endorsement, etc. In this example, the interest packet may specify the name and also the version number, or version range, desired, The matching may then locate routes or cached data matching the name and then perform the additional comparison of meta-data or the like to arrive at an ultimate decision as to whether data or a route matches the interest packet for responding to the interest packet or forwarding the interest packet respectively.
ICN has advantages over host-based networking because the data segments are individually named. This permits aggressive caching throughout the network as a network device may provide a data packet in response to an interest as easily as an original author. Accordingly, it is less likely that the same segment of a network will transmit duplicates of the same data requested by different devices. Such an architecture is useful when a network branches from a central information provider to many leaves, such as occurs in many IoT deployments.
Fine grained encryption is another feature of many ICNs. A typical data packet includes a name for the data that matches the name in the interest packet. Further, the data packet includes the requested data and may include additional information that may, for example, be used to filter similarly named data (e.g., by creation time, expiration time, version, etc.). To address malicious entities providing false information under the same name, the data packet may also encrypt its contents with a publisher key or provide a cryptographic hash of the data and the name. Thus, knowing the key (e.g., from a certificate of an expected publisher) allows the recipient to ascertain whether the data is from that publisher. This technique also allows the aggressive caching of the data packets throughout the network because each data packet is self-contained and secure. This contrasts with many host-based networks that rely on encrypting a connection between two hosts to securely communicate. With connection encryption, the network devices have no access to the data to cache the data.
Example ICNs include content centric networking (CCN), as specified in the Internet Engineering Task Force (IETF) draft specifications for CCNx 0.x and CCN. 1.x, and named data networking (NDN), as specified in the NDN technical report DND-0001.
IoT system interoperability is not simply solved by using standard ICN implementations. The problem of bridging between two or more independent IoT systems configured as ICN islands (e.g., domains or other logical encapsulations within an ICN that may be within the same subnet or different subnets). ICN naming domains that support an IoT context or application as well as ICN island attribute exposure are described to uniquely identify and characterize the capabilities of an ICN island as a logical or functional entity to support bridging.
To use an ICN based information plane to bridge multiple ICN islands (e.g., that may be built on networks of heterogeneous functions with either the same or heterogeneous connectivity), participating ICN islands identify the various types of information that a given ICN island is willing to expose to other ICN islands as a logical functional entity.
In an example, the exposed attributes include content generated within the ICN island. Such content may include raw sensor data, processed metrics, or analytics, among others.
In an example, the exposed attributes include attributes of the ICN island itself. Such attributes may include the ICN island's name, functions (e.g., lighting, security, etc.), scope of operation (e.g., does it span a home, a building, a park, a business, etc.), among others.
In an example, the exposed attributes include metrics (e.g., demographics) about the devices that are in the ICN island. Such metrics may include attributes of the number of devices (e.g., sensors, actuators, etc.) within the ICN island, device locations within the ICN island, a mapping of device physical locations to a logical naming (e.g., addressing) plan (e.g., and its relationship to the namespace domain), the radio technology used by the various devices, or specific permission levels for the various types of functions supported by the different devices within the ICN island, among others.
In an example, the exposed attributes include connectivity information about other connected ICN islands. This connectivity information may be used to construct routes to direct traffic, such as how to reach distant or disconnected ICN islands.
In an example, the exposed attributes include access policies for the ICN island, for the devices within the ICN island, devices in different ICN islands, or data available (e.g., generated or derived) from the entities within each island. Access policies may take several forms, such as access control lists (ACLs), entry via a clearinghouse, etc.
Within an ICN island, standard ICN communication is sufficient—intra-island communication may use ICN style publish-subscribe models to communicate. Inter-island communication however, is achieved via one or more enhancements to the standard ICN communications model. In an example, a mapping from one network (e.g., a wireless network for lighting or surveillance systems) to another is implemented using a single naming hierarchy. Here, the network plane (e.g., name-based routing) bridges islands with heterogeneous network connectivity and without modification. In an example, name spaces from a first ICN island are mapped to work in a second ICN island. This mapping addresses potential name space collisions. For example, the name of an entity in the first ICN island is mapped to the second ICN island by prepending a value corresponding to the first IC island (e.g., a prefix of the first ICN island is present whenever the entity is named outside of the first ICN island).
In an example, entities within an island are named based on physical or logical node or system clusters as well as entity data features. For example, nodes that have similar attributes describing their location, functions, other criteria for bridging or group formation have names representing these relationships.
In an example, ICN discovery (e.g., search) mechanisms are modified to allow the ICN islands to be discovered based on their exposed attributes. In an example, ICN islands advertise their connectivity or the connectivity of other connected or nested ICN islands. This allows construction of ICN routes to connect ICN islands that are not directly connected.
In an example, a new publication-subscription model including new “discovery” packets analogous to interest packets allows ICN island discovery in terms of what type of systems are connected (e.g., light management, security, temperature, etc.). In an example, the discovery (e.g., subscription request) is directed to a centralized system (e.g., a database) to serve as an efficient clearinghouse of ICN island capabilities and interfaces. In an example, advertisement packets (e.g., analogous to ICN publish or service advertisement packets) may be used to maintain the central system's records.
ICN island bridging offers an efficient and universal mechanism to permit interoperability between different IoT systems. The ICN modifications described throughout enable ICN island interactions without resorting to application layer work-grounds, resulting in a robust networking solution to a variety of IoT installations. Variations and examples of these ICN improvements to support ICN islands and ICN island bridging are discussed below.
FIG. 1 is a block diagram of an example of an environment 100 including a system 105 for ICN island bridging, according to an embodiment. The environment 100 includes a first ICN island 140 (e.g., a home automation system) and a second ICN island 150 (e.g., a security system). The first ICN island includes a content router communicating with an upstairs light and a downstairs light. The second ICN island includes two content routers, one of which communicates with an upstairs camera and a downstairs camera, the second of which communicates with an offsite security data center 155.
The system 105 includes a network interface 110, a controller 125, and a data store 130. The components of the system 105 are implemented in computer hardware, such as circuitry. As illustrated, the system 105 is a content router that is in both the first and the second ICN islands. Thus, in an example, the system 105 belongs to multiple domains. This, however, is not required. In an example, the system 105 is part of only one ICN island with a communication pathway external to the ICN island. As part of an ICN island, the system 105 is called an island domain node. For example, as illustrated, the system 105 is communicatively coupled via a content router to a non-island server 160. Thus, the system 105 is positioned to enable inter-ICN island communications. As noted above, intra-island communications may operate on standard ICN principles. However, as detailed below, the system 105 interfaces with intra-island nodes to provide inter-island data in some examples.
The network controller 110 is arranged to receive a request that includes a data identifier. The data identifier, which may also be called a data name, is an ICN convention whereby data is identified rather than a host from which the data is to be obtained.
The controller 125 is arranged to use an inter-domain discovery to identify a destination domain corresponding to the data identifier in the request. Standard ICN communication may reveal that the data of the data identifier is available within an ICN island (e.g., island 140 or island 150). However, the system 105 has inter-island communication capabilities and thus may look outside of a given island. In an example, the controller 125 is arranged to query a local store 130 of domain capabilities with the data identifier to produce search results. The local store may be a database, cache, or other data structure to maintain capabilities or attributes of one or more ICN islands. The result of the query include a set of domain identifiers. That is, the data identifier is used as a key, index, or search term to the data store 130 to return domain identifiers (e.g., names, numbers, or identifiers of one or more ICN islands). The ICN islands corresponding to the domain identifiers thus are likely to be able to satisfy the request.
In an example, the controller 125 is arranged to obtain a service set of a different domain than the domain to which the system 105 belongs. The controller 125 may then update the local store 130 with the service set. By this mechanism the controller 125 maintains knowledge of the other ICN islands. In an example, to obtain the service set of the different domain, the controller 125 queries an inter-domain service 160. The inter-domain service 160 operates as a clearinghouse for ICN island information. The inter-domain service 160 may implement access control or other permissions to flexibly control what information is available based on the source and requester. The inter-domain service 160 may maintain connections (e.g., interests) to its ICN islands such that changes to those islands' attributes are propagated as data packets to the inter-domain service 160.
In an example, to obtain the service set of the different domain, the controller 125 is arranged to place (e.g., via the network interface 110) a discovery interest on an inter-island information centric network. This is an example of ad-hoc discovery or direct inter-island discovery performed by the system 105. In an example, the discovery interest includes a services filter. The services filter includes one or more filters to refine the discovery request. Thus, if the system 105 is interested in sensors at the home and no others, a discovery interest to the ICN island 150 may include a service filter to limit responses to the house. In an example, a response to the discovery interest has contents based on the services filter. Thus, although the data center 155 may have attributes or services to expose to the system 105, those attributes or services will not be returned because they do not pertain to the house. However, the cameras that are in the house may be exposed to the system 105 as a response to the discovery interest.
In an example, the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest. Thus, the discovery interest is persistent in the ICN. This permits multiple responses from different ICN islands to pass through the same content routers. In an example, the discovery interest includes a time-to-live (TTL). Here, the discovery interest may be removed from the pending interest structure (e.g., in content routers) based on the TTL. This allows cleanup of persistent discovery interests. In an example, the discovery interest includes a total count. Here, the discovery interest may be removed from the pending interest structure based on a number of responses received to the discovery interest and the total count. Thus, instead of being persistent for a period of time, the interest may be persistent until a certain number of responses are achieved. This technique permits the discovery interest to be cleaned up more quickly if the number of responses are predictable by the system 105. In an example, the discovery interest is sent at regular intervals. This is a “refresh” of the discovery interest. By regularly removing and refreshing discovery interests, the system 105 may maintain an efficient and continuous discovery of ICN islands without becoming stale.
The controller 125 is arranged to modify the request to create an inter-domain request. In an example, to modify the request to create the inter-domain request, the controller is arranged to add the destination domain to the data identifier. In an example, the data identifier is hierarchical and the domain identifier is added to the top of the hierarchy. For example, if data is named ‘lighting-system/upstairs/control/intensity’, where ‘/’ is the hierarchical delimiter and moving from left-to-right moves down the hierarchy, the domain identifier ‘lighting-system’ appears at the left-most position. This approach allows an easy naming convention for nested domains. For example, if ICN island ‘lighting-system’ is completely embedded in an ICN island ‘home-control’, the inner domain identifier is placed first and the out domain identifier placed second, resulting in a name ‘/home-control/lighting-system/upstairs/control/intensity’. In an example, the domain identifier is flagged in the data identifier. For example, the data name ‘upstairs/d:lighting-system/control/intensity’ or ‘/upstairs/control/intensity[lighting-system]’ illustrate additional techniques to identify the domain identifier.
The network controller 110 is arranged to communicate the inter-domain request to an inter-domain information centric network. Once the inter-domain request is communicated to the inter-domain ICN, the request may be satisfied by an entity outside of the requester's ICN island. The modification of the request in this manner permits intra-island naming conventions and to be separated from inter-island naming requirements. This reduces name collisions and permits data naming to be tailored to different environments. Further, the goal of network-layer bridging is achieved, allowing differing IoT installations to communicate with each other while continuing to communicate internally without modification.
The discovery and use of other ICN islands described above has the system 105 in the role of a user of other ICN islands. The system 105, however, may also serve other ICN islands. In an example, the network interface 110 is arranged to receive a discovery interest from an inter-island information centric network. The controller 125 is arranged to provide a response to the discovery interest based on selectors in the discovery interest and a database (e.g., housed in the local store 130) of intra-island services. The intra-island services may include services provided directly by the system 105 as well as those provided by other entities in the system's ICN island. For example, the data center 155 may send a discovery interest with a selector for the location of the house and lighting services. The system 105 may return a service corresponding to the lights of the ICN island 140. As part of the response, the system 105 may include the domain identifier for the ICN island 140. Thus, upon a subsequent interest to a light of ICN island 140, for example, the appropriate ICN island identifier is applied to the data identifier such that the inter-island ICN correctly routes the interest. Once the interest reaches the destination domain, it may be handled in a variety of ways. In an example, the system 105 operates as a gateway, translating the inter-domain data identifier into an appropriate intra-domain identifier. In an example, intra-domain entities know their domain identifier and thus may ignore it in an interest. This permits a simple pass-through model of communication whereby the system 105 need not be involved in routing the interest.
The system 105 maintains a record of service provided by the ICN island to which it belongs. This record may operate similarly to the inter-island discovery discussed above directed to intra-island entities (e.g., discovery interests, etc.). In an example, the system 105 may perform ad-hoc querying of intra-island entities upon receipt of the inter-island discovery request. Thus, in an example, the controller 125 is arranged to communicate (e.g., via the network interface 110 or via a separate network interface (not shown) dedicated to intra-island communication) a second discovery interest to the intra-island information centric network. The system 105 may then receive service metrics from other intra-island nodes in response to the second discovery interest. The controller 125 is arranged to then update the database of intra--island services based on the received service metrics.
An aspect of inter-system communication not yet addressed is security. A security apparatus permits flexible mixing of different ICN islands. Access control lists (ACLs), based on device or domain identifiers may be implemented. Beyond specifically identifying what entities may receive discovery responses, the security may he based on keys. In this example, the contents of the response are based on a key presented in the discovery interest. Thus, in an example, to provide the response to the discovery interest based on selectors in the discovery interest and the database of intra--island services, the controller 125 is arranged to extract a security identifier from the discovery interest and filter entries of the database of intra-island services based on the security identifier. In an example. The granularity of the response based on an ACL, key, or combination of both, may be as refined as a single attribute, to the entire ICN
FIG. 2 illustrates an example of ICN island bridging 200, according to an embodiment. The bridging 200 described below provides additional examples of the environment 100 described above. The following discussion is in the context of a home lighting system ICN island 205 and a home security system ICN island 215. Entities within the home security system ICN island 215 may use the request handler 220 to make inter-domain requests to the home lighting system ICN island 205. To perform its functions, the request handler 220 queries the network information database 210 of the home lighting system ICN island 205 to discover what services, data, or attributes are accessible to the home security system ICN island 215.
As noted earlier, currently, there are no solutions to the problem of accessing to private clouds of individual IoT applications. Further, there is no framework that supports the sharing of IoT application system information at the networking layer (e.g., plane). Here, however, is described a framework to define IoT subsystems as ICN islands with the ability to share data between each other. The bridging 200 includes a naming scheme to allow inter-island information sharing. Depending on ICN islands cluster configurations (e.g., whether the ICN islands are recursively clustered, hierarchically clustered, or peers), the naming scheme reflects the clustering organization. ICN islands that are recursively clustered have a namespace domain that reflects the nesting nature of the deployments. For example, if two ICN islands are part of the same domain (e.g. they are both in the same home), then the naming scheme reflects the relationship by attaching a common domain name space identifier (e.g., domain identifier) to the ICN islands.
The bridging 200 uses a modified ICN Island research and discovery mechanism. The mechanism is modified in the sense that it operates differently than standard ICN messaging. For example, the publication-subscription procedure may be changed into a distributed scheme for discovering different ICN islands and sending requests to these ICN islands. To achieve his, the bridging 200 uses a new type of interest packet for “discovering” other (e.g., adjacent) ICN islands. Here, ICN islands may be logically related or physically related. The discovery packets may be called discovery interest packets.
A discovery interest packet indicates a request for details of ICN islands (e.g., adjacent ICN islands or others). The “selector” section of the discovery interest packet specifies whether the discovery pertains to information about a particular type of island or all the islands within a certain vicinity, for example. The selector section of the discovery interest packet may also contain the physical or logical domain from which the discovery interest originates. For instance, a node may communicate a discovery interest packet requesting details of all ICN islands that are located within a particular building specified by the selector section of the discovery interest packet.
Discovery packets are forwarded through an inter-domain ICN until they reach a node that is able to respond to the request. The responding node may first check whether the discovery interest packet has permission to access the requested information. If the permissions permit disclosure (e.g., the requesting node, domain, or discovery interest is authorized), the responding node may then determine what level of information it is permitted to provide to the requestor. Once these issues are resolved, the responding node provides, to the extent permitted, the requested information. In an example, the responding node may not actually respond to the discovery interest packet itself. Instead, the responding node may forward the discovery interest packet to a local gateway or coordinator that provides the response. In an example, the response (e.g., data packet)contains details of all nodes within the responding ICN island. In an example, the response also includes details specifying how to control or request changes of the entities in the responding ICN island.
In an example, the discovery interest packet may include a threshold distance (e.g., logical hops, geographic location, etc.). If the discovery packet reaches a location that is beyond the threshold distance, an inter-domain node (e.g., content router, other node, etc.) may refrain from forwarding the discovery interest packet.
In an example, to facilitate discovery among several ICN islands, multiple responses are permitted for a single discovery interest packet. To achieve this end, in an example, the response packet has a name that includes the name provided in the discovery interest packet along with a suffix that is unique to the ICN island. Thus any data packet that includes the name in the discovery interest packet will be considered a response and forwarded to the node that sent out the discovery interest packet. In an example, time-out threshold (e.g., TTL) is included in the discovery interest packet. After the time-out expires, the discovery interest packet may be removed from pending interest tables (PITS) in inter-domain ICN nodes instead of when a response to the discovery interest packet passes through a node as it is traditionally done.
Once the requesting (e.g., subscribing) node receives details of the other ICN islands, the requesting node may use this information to request data, control, services, or adjustments from entities within the responding ICN island or the responding ICN island itself. For example, the requesting node may transmit a request to a manager or coordinator of the responding ICN island in the form of a data packet with a name that includes source and destination node. The ICN island manager or coordinator is then responsible for sending out periodic interest packets to ensure that discovery requests are routed to it. This technique may also be used to signal when the responding ICN island is not accepting requests. For example, if there is some maintenance going on in the home lighting system ICN island 205, it may refrain from sending the interest packets, indicating that it is not able to take any requests at this time. In an example, once a node sends out a request to an adjacent island, it also immediately subscribes (e.g., transmits an interest packet) to any ACK packets that originate from the adjacent island.
In an example, NID 210 is used to store information about a given ICN island. In an example, the discovery interest packet is forwarded to the NID 210. The NID 210 may then apply the security techniques discussed above and provide an appropriate response based on the discovery interest packet and security measures. To perform these functions, the NM 210 includes a registry of information that is consistent and contains information on the ICN island, such as size of the network, other ICN islands with which it connects, the type of nodes installed in it, their geographical location, their permissions (e.g., which determines their accessibility to external nodes of the ICN island, or to internal nodes inside the same ICN island), the possibility of acceptance of commands from external networks—for example, the ability of the home security system ICN island 215 sending actuation commands to the home lighting system ICN island 205, the network technology that links them together, etc. In an example, the NID 210 is located within a gateway device that provides connectivity to the different IoT systems in the ICN island and may also act as a proxy to other ICN islands or networks (e.g., the Internet).
Although the NID 210 is illustrated within the home lighting system ICN island 205, in an example, the NID 210 may reside in a hierarchy above the various ICN islands that access it. In this example, the NID 210 may provide query and update services to several ICN islands. An inter-domain NID 210 may be located at a node accessible by more than one ICN island be it a physical node or a logical node in a cloud. In an example, the NID 210 placement may be changed on-demand (e.g., transferred from one node to another) assist a variety of scenarios, such as mobility scenarios.
To permit effective NID 210 operation by, for example, the request handler 220, the NID 220 may implement a standard application programing interface (API). In an example, the API includes one or more of a query call, an update call, a record new data call, an authorization call (e.g., permissions based access). A common API allows multiple vendors or generations of products to interoperate, be they residential or commercial, because there is a standardized way to interoperate and share information between the systems without compromising on security.
The techniques described above result in a self-learning and updating inter-island communication network. This is an important feature as network participation by various nodes change over time, including small time scales, such as every minute or every hour. The self-learning elements of discovery described above permit the NID 210 to accurately reflect the ICN island throughout these changes.
FIG. 3 illustrates an example of an ICN 300 and routing table 305, according to an embodiment. The ICN 300 follows a traditional peer-based relationship between different ICN islands A, B, C, and D. The routing table 305 is from the perspective of ICN island D and illustrates the network, route, and naming prefix used to access entities within a particular ICN island. Thus, to communicate with a lighting control in ICN island A, an entity from the ICN island D may preface the data name with ‘A’ (e.g., ‘A/light/lighting-control’). Because no entity in D has the ‘A’ preface, the interest is routed outside of D to C where it may be routed directly to A or through B to A.
FIG. 4 illustrates an example of an ICN 400 and routing table 405, according to an embodiment. It cannot be assumed that all ICN islands that bridge will peer directly, some will be contained within other ICN islands. In these scenarios, name spaces may be modified to avoid name space collisions. In an example, a hierarchical prefix may be used for each ICN island. Thus, as layers of embedded networks are added, the domain identifier of the outermost layer is prepended to a data identifier.
The ICN 400 includes ICN islands E, F, G, H, and I. ICN islands F and G are embedded inside of H. Thus, any communication to or from F and G to E or I must pass through H. The routing table 405, from the perspective of ICN island E, illustrates the routing and naming used to permit communication with embedded domains F and G. This same concept may be extended to bridging logical ICN islands as well as physically separated ICN islands.
FIG. 5 illustrates a flow diagram of an example of a method 500 for ICN island bridging, according to an embodiment. The operations of the method 500 are implemented in computer hardware, such as that described above, or described below with respect to FIG. 6 (e.g., circuitry). The method 500 may be executed in an ICN by an island domain node. In an example, the island domain node belongs to multiple domains.
At operation 505, a request is received at an island domain node in an information centric network, the request including a data identifier.
At operation 510, an inter-domain discovery is used to identify a destination domain corresponding to the data identifier. In an example, inter-domain discovery includes querying a local store of domain capabilities with the data identifier to produce search results and returning a set of domain identifiers from the search results. In an example, the method 500 is extended to include obtaining a service set of a different domain than the domain and updating the local store of the island domain node with the service set. In an example, obtaining the service set of the different domain includes querying an inter-domain service.
In an example, obtaining the service set of the different domain includes placing a discovery interest on an inter-island information centric network. In an example, the discovery interest includes a services filter. In an example, a response to the discovery interest has contents based on the services filter. In an example, the discovery interest is sent at regular intervals.
In an example, the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest. In an example, the discovery interest includes a TTL. In an example, the discovery interest is removed from the pending interest structure based on the TTL. In an example, the discovery interest includes a total count. In an example, the discovery interest is removed from the pending interest structure based on a number of responses received to the discovery interest and the total count.
At operation 515, the request is modified to create an inter-domain request. In an example, modifying the request to create the inter-domain request includes adding the destination domain to the data identifier. In an example, the data identifier is hierarchical. In an example, the domain identifier is at a top of the hierarchy. In an example, the domain identifier is flagged in the data identifier.
At operation 520, the inter-domain request is communicated to an inter-domain information centric network.
The method 500 may be extended to include receiving a discovery interest from an inter-island information centric network and providing a response to the discovery interest based on selectors in the discovery interest and a database of intra-island services. In an example, providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes extracting a security identifier from the discovery interest and filtering entries of the database of intra-island services based on the security identifier. In an example, providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes filtering entries of the database based on the selectors.
The method 500 may be extended to include communicating a second discovery interest to an intra-island information centric network from the island domain node. Service metrics from other intra-island nodes may then be received. The database of intra-island services may be updated based on the received service metrics.
The systems, devices, and techniques described above provide a variety of benefits over existing IoT networks. For example, if details of a system are exposed at the ICN level, there is no need to call up into the application layer of to find information published by its private cloud. Having such information allows for a far greater variety of interactions between different IoT systems even though they may be deployed by different vendors using different wireless technologies, greatly improving interoperability. Further, having a clearly defined interface at the ICN level allows third party analytics to be deployed across IoT installations, providing a broader view an environment than would otherwise be possible. This also permits flexibility in deploying new application. Additionally, exposing data or services across ICN islands enables a data economy allowing the combination of data across islands in new and interesting ways, which may be unanticipated by the designers of the original islands.
FIG. 6 illustrates a block diagram of an example machine 600 upon which any one or more of the techniques (e.g., methodologies) discussed herein may perform. Examples, as described herein, may include, or may operate by, logic or a number of components, or mechanisms in the machine 600. Circuitry (e.g., processing circuitry) is a collection of circuits implemented in tangible entities of the machine 600 that include hardware (e.g., simple circuits, gates, logic, etc.). Circuitry membership may be flexible over time. Circuitries include members that may, alone or in combination, perform specified operations when operating. In an example, hardware of the circuitry may be immutably designed to carry out a specific operation (e.g., hardwired). In an example, the hardware of the circuitry may include variably connected physical components (e.g., execution units, transistors, simple circuits, etc.) including a machine readable medium physically modified (e.g., magnetically, electrically, moveable placement of invariant massed particles, etc.) to encode instructions of the specific operation. In connecting the physical components, the underlying electrical properties of a hardware constituent are changed, for example, from an insulator to a conductor or vice versa. The instructions enable embedded hardware (e.g., the execution units or a loading mechanism) to create members of the circuitry in hardware via the variable connections to carry out portions of the specific operation when in operation. Accordingly, in an example, the machine readable medium elements are part of the circuitry or are communicatively coupled to the other components of the circuitry when the device is operating. In an example, any of the physical components may be used in more than one member of more than one circuitry. For example, under operation, execution units may be used in a first circuit of a first circuitry at one point in time and reused by a second circuit in the first circuitry, or by a third circuit in a second circuitry at a different time. Additional examples of these components with respect to the machine 600 follow.
In alternative embodiments, the machine 600 may operate as a standalone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine 600 may operate in the capacity of a server machine, a client machine, or both in server-client network environments. In an example, the machine 600 may act as a peer machine in peer-to-peer (P2P) (or other distributed) network environment. The machine 600 may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a mobile telephone, a web appliance, a network router, switch or bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, while only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein, such as cloud computing, software as a service (SaaS), other computer cluster configurations.
The machine (e.g., computer system) 600 may include a hardware processor 602 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), a hardware processor core, or any combination thereof), a main memory 604, a static memory (e.g., memory or storage for firmware, microcode, a basic-input-output (BIOS), unified extensible firmware interface (UEFI), etc.) 606, and mass storage 621 (e.g., hard drive, tape drive, flash storage, or other block devices) some or all of which may communicate with each other via an interlink (e.g., bus) 608. The machine 600 may further include a display unit 610, an alphanumeric input device 612 (e.g., a keyboard), and a user interface (UI) navigation device 614 (e.g., a mouse). In an example, the display unit 610, input device 612 and UI navigation device 614 may be a touch screen display. The machine 600 may additionally include a storage device (e.g., drive unit) 616, a signal generation device 618 (e.g., a speaker), a network interface device 620, and one or more sensors 621, such as a global positioning system (GPS) sensor, compass, accelerometer, or other sensor. The machine 600 may include an output controller 628, such as a serial (e.g., universal serial bus (USB), parallel, or other wired or wireless (e.g., infrared (IR), near field communication (NFC), etc.) connection to communicate or control one or more peripheral devices (e.g., a printer, card reader, etc.).
Registers of the processor 602, the main memory 604, the static memory 606, or the mass storage 616 may be, or include, a machine readable medium 622 on which is stored one or more sets of data structures or instructions 624 (e.g., software) embodying or utilized by any one or more of the techniques or functions described herein. The instructions 624 may also reside, completely or at least partially, within any of registers of the processor 602, the main memory 604, the static memory 606, or the mass storage 616 during execution thereof by the machine 600. In an example, one or any combination of the hardware processor 602, the main memory 604, the static memory 606, or the mass storage 616 may constitute the machine readable media 602. While the machine readable medium 622 is illustrated as a single medium, the term “machine readable medium” may include a single medium or multiple media (e.g., a centralized or distributed database, and/or associated caches and servers) configured to store the one or more instructions 624.
The term “machine readable medium” may include any medium that is capable of storing, encoding, or carrying instructions for execution by the machine 600 and that cause the machine 600 to perform any one or more of the techniques of the present disclosure, or that is capable of storing, encoding or carrying data structures used by or associated with such instructions. Non-limiting machine readable medium examples may include solid-state memories, optical media, magnetic media, and signals (e.g., radio frequency signals, other photon based signals, sound signals, etc.). In an example, a non-transitory machine readable medium comprises a machine readable medium with a plurality of particles having invariant (e.g., rest) mass, and thus are compositions of matter. Accordingly, non-transitory machine-readable media are machine readable media that do not include transitory propagating signals. Specific examples of non-transitory machine readable media may include: non-volatile memory, such as semiconductor memory devices (e.g., Electrically Programmable Read-Only Memory (EPROM), Electrically Erasable Programmable Read-Only Memory (EEPROM)) and flash memory devices; magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks.
The instructions 624 may be further transmitted or received over a communications network 626 using a transmission medium via the network interface device 620 utilizing any one of several transfer protocols (e.g., frame relay, internet protocol (IP), transmission control protocol (TCP), user datagram protocol (UDP), hypertext transfer protocol (HTTP), etc.). Example communication networks may include a local area network (LAN), a wide area network (WAN), a packet data network (e.g., the Internet), mobile telephone networks (e.g., cellular networks), Plain Old Telephone (POTS) networks, and wireless data networks (e.g., Institute of Electrical and Electronics Engineers (IEEE) 802.11 family of standards known as Wi-Fi®, IEEE 802.16 family of standards known as WiMax®), IEEE 802.15.4 family of standards, peer-to-peer (P2P) networks, among others, in an example, the network interface device 620 may include one or more physical jacks (e.g., Ethernet, coaxial, or phone jacks) or one or more antennas to connect to the communications network 626. In an example, the network interface device 620 may include a plurality of antennas to wirelessly communicate using at least one of single-input multiple-output (SIMO), multiple-input multiple-output (MIMO), or multiple-input single-output (MISO) techniques. The term “transmission medium” shall be taken to include any intangible medium that is capable of storing, encoding or carrying instructions for execution by the machine 600, and includes digital or analog communications signals or other intangible medium to facilitate communication of such software. A transmission medium is a machine readable medium.

Additional Notes & Examples

Example 1 is a system for information centric network island bridging, the system comprising: a network interface to receive a request at an island domain node in an information centric network, the request including a data identifier; and a controller to: use an inter-domain discovery to identify a destination domain corresponding to the data identifier; modify the request to create an inter-domain request; and communicate the inter-domain request to an inter-domain information centric network.
In Example 2, the subject matter of Example 1 optionally includes wherein the island domain node belongs to multiple domains.
In Example 3, the subject matter of any one or more of Examples 1-2 optionally include wherein, to modify the request to create the inter-domain request, the controller is to add the destination domain to the data identifier.
In Example 4, the subject matter of Example 3 optionally includes wherein the data identifier is hierarchical, and wherein the domain identifier is at a top of the hierarchy.
In Example 5, the subject matter of any one or more of Examples 3-4 optionally include wherein the domain identifier is flagged in the data identifier.
In Example 6, the subject matter of any one or more of Examples 1-5 optionally include wherein, to use the inter-domain discovery, the controller is to: query a local store of domain capabilities with the data identifier to produce search results; and return a set of domain identifiers from the search results.
In Example 7, the subject matter of Example 6 optionally includes wherein the controller is to: obtain a service set of a different domain than the domain; and update the local store of the island domain node with the service set.
In Example 8, the subject matter of Example 7 optionally includes wherein, to obtain the service set of the different domain, the controller is to query an inter-domain service.
In Example 9, the subject matter of any one or more of Examples 7-8 optionally include wherein, to obtain the service set of the different domain, the controller is to place a discovery interest on an inter-island information centric network.
In Example 10, the subject matter of Example 9 optionally includes wherein the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest.
In Example 11, the subject matter of Example 10 optionally includes wherein the discovery interest includes a time-to-live, and wherein the discovery interest is removed from the pending interest structure based on the time-to-live.
In Example 12, the subject matter of any one or more of Examples 10-11 optionally include wherein the discovery interest includes a total count, and wherein the discovery interest is removed from the pending interest structure based on a number of responses received to the discovery interest and the total count.
In Example 13, the subject matter of any one or more of Examples 9-12 optionally include wherein the discovery interest includes a services filter, and wherein a response to the discovery interest has contents based on the services filter.
In Example 14, the subject matter of any one or more of Examples 9-13 optionally include wherein the discovery interest is sent at regular intervals.
In Example 15, the subject matter of any one or more of Examples 1-14 optionally include wherein the network interface is to receive a discovery interest from an inter-island information centric network; and wherein the controller is to provide a response to the discovery interest based on selectors in the discovery interest and a database of intra-island services.
In Example 16, the subject matter of Example 15 optionally includes wherein, to provide the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services, the controller is to extract a security identifier from the discovery interest and filtering entries of the database of intra-island services based on the security identifier.
In Example 17, the subject matter of any one or more of Examples 15-16 optionally include wherein, to provide the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services, the controller is to filter entries of the database based on the selectors.
In Example 18, the subject matter of any one or more of Examples 15-17 optionally include wherein the controller is to: communicate a second discovery interest to an intra-island information centric network from the island domain node; receive service metrics from other intra-island nodes; and update the database of intra-island services based on the received service metrics.
Example 19 is a method for information centric network island bridging, the method comprising: receiving a request at an island domain node in an information centric network, the request including a data identifier; using an inter-domain discovery to identify a destination domain corresponding to the data identifier; modifying the request to create an inter-domain request; and communicating the inter-domain request to an inter-domain information centric network.
In Example 20, the subject matter of Example 19 optionally includes wherein the island domain node belongs to multiple domains.
In Example 21, the subject matter of any one or more of Examples 19-20 optionally include wherein modifying the request to create the inter-domain request includes adding the destination domain to the data identifier.
In Example 22, the subject matter of Example 21 optionally includes wherein the data identifier is hierarchical, and wherein the domain identifier is at a top of the hierarchy.
In Example 23, the subject matter of any one or more of Examples 21-22 optionally include wherein the domain identifier is flagged in the data identifier.
In Example 24, the subject matter of any one or more of Examples 19-23 optionally include wherein using the inter-domain discovery includes: querying a local store of domain capabilities with the data identifier to produce search results; and returning a set of domain identifiers from the search results.
In Example 25, the subject matter of Example 24 optionally includes obtaining a service set of a different domain than the domain; and updating the local store of the island domain node with the service set.
In Example 26, the subject matter of Example 25 optionally includes wherein obtaining the service set of the different domain includes querying an inter-domain service.
in Example 27, the subject matter of any one or more of Examples 25-26 optionally include wherein obtaining the service set of the different domain includes placing a discovery interest on an inter-island information centric network.
In Example 28, the subject matter of Example 27 optionally includes wherein the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest.
In Example 29, the subject matter of Example 28 optionally includes wherein the discovery interest includes a time-to-live, and wherein the discovery interest is removed from the pending interest structure based on the time-to-live.
In Example 30, the subject matter of any one or more of Examples 28-29 optionally include wherein the discovery interest includes a total count, and wherein the discovery interest is removed from the pending interest structure based on a number of responses received to the discovery interest and the total count.
In Example 31, the subject matter of any one or more of Examples 27-30 optionally include wherein the discovery interest includes a services filter, and wherein a response to the discovery interest has contents based on the services filter.
In Example 32, the subject matter of any one or more of Examples 27-31 optionally include wherein the discovery interest is sent at regular intervals.
In Example 33, the subject matter of any one or more of Examples 19-32 optionally include receiving a discovery interest from an inter-island information centric network; and providing a response to the discovery interest based on selectors in the discovery interest and a database of intra-island services.
In Example 34, the subject matter of Example 33 optionally includes wherein providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes extracting a security identifier from the discovery interest and filtering entries of the database of intra-island services based on the security identifier.
In Example 35, the subject matter of any one or more of Examples 33-34 optionally include wherein providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes filtering entries of the database based on the selectors.
In Example 36, the subject matter of any one or more of Examples 33-35 optionally include communicating a second discovery interest to an intra-island information centric network from the island domain node; receiving service metrics from other intra-island nodes; and updating the database of intra-island services based on the received service metrics.
Example 37 is at least one machine readable medium including instructions that, when executed by processing circuitry, cause the processing circuitry to perform any method of Examples 19-36.
Example 38 is a system comprising means to perform any method of Examples 19-36.
Example 39 is at least one machine readable medium including instructions for information centric network island bridging, the instructions, when executed by processing circuitry, cause the processing circuitry to perform operations comprising: receiving a request at an island domain node in an information centric network, the request including a data identifier; using an inter-domain discovery to identify a destination domain corresponding to the data identifier; modifying the request to create an inter-domain request; and communicating the inter-domain request to an inter-domain information centric network.
In Example 40, the subject matter of Example 39 optionally includes wherein the island domain node belongs to multiple domains.
In Example 41, the subject matter of any one or more of Examples 39-40 optionally include wherein modifying the request to create the inter-domain request includes adding the destination domain to the data identifier.
In Example 42, the subject matter of Example 41 optionally includes wherein the data identifier is hierarchical, and wherein the domain identifier is at a top of the hierarchy.
In Example 43, the subject matter of any one or more of Examples 41-42 optionally include wherein the domain identifier is flagged in the data identifier.
In Example 44, the subject matter of any one or more of Examples 39-43 optionally include wherein using the inter-domain discovery includes: querying a local store of domain capabilities with the data identifier to produce search results; and returning a set of domain identifiers from the search results.
In Example 45, the subject matter of Example 44 optionally includes wherein the operations include: obtaining a service set of a different domain than the domain; and updating the local store of the island domain node with the service set.
In Example 46, the subject matter of Example 45 optionally includes wherein obtaining the service set of the different domain includes querying an inter-domain service.
In Example 47, the subject matter of any one or more of Examples 45-46 optionally include wherein obtaining the service set of the different domain includes placing a discovery interest on an inter-island information centric network.
In Example 48, the subject matter of Example 47 optionally includes wherein the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest.
In Example 49, the subject matter of Example 48 optionally includes wherein the discovery interest includes a time-to-live, and wherein the discovery interest is removed from the pending interest structure based on the time-to-live.
In Example 50, the subject matter of any one or more of Examples 48-49 optionally include wherein the discovery interest includes a total count, and wherein the discovery interest is removed from the pending interest structure based on a number of responses received to the discovery interest and the total count.
In Example 51, the subject matter of any one or more of Examples 47-50 optionally include wherein the discovery interest includes a services filter, and wherein a response to the discovery interest has contents based on the services filter.
In Example 52, the subject matter of any one or more of Examples 47-51 optionally include wherein the discovery interest is sent at regular intervals.
In Example 53, the subject matter of any one or more of Examples 39-52 optionally include wherein the operations include: receiving a discovery interest from an inter-island information centric network; and providing a response to the discovery interest based on selectors in the discovery interest and a database of intra-island services.
In Example 54, the subject matter of Example 53 optionally includes wherein providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes extracting a security identifier from the discovery interest and filtering entries of the database of intra-island services based on the security identifier.
In Example 55, the subject matter of any one or more of Examples 53-54 optionally include wherein providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes filtering entries of the database based on the selectors.
In Example 56, the subject matter of any one or more of Examples 53-55 optionally include wherein the operations include: communicating a second discovery interest to an intra-island information centric network from the island domain node; receiving service metrics from other intra-island nodes; and updating the database of intra-island services based on the received service metrics.
Example 57 is a system for information centric network island bridging, the system comprising: means for receiving a request at an island domain node in an information centric network, the request including a data identifier; means for using an inter-domain discovery to identify a destination domain corresponding to the data identifier; means for modifying the request to create an inter-domain request; and means for communicating the inter-domain request to an inter-domain information centric network.
In Example 58, the subject matter of Example 57 optionally includes wherein the island domain node belongs to multiple domains.
In Example 59, the subject matter of any one or more of Examples 57-58 optionally include wherein the means for modifying the request to create the inter-domain request includes means for adding the destination domain to the data identifier.
In Example 60, the subject matter of Example 59 optionally includes wherein the data identifier is hierarchical, and wherein the domain identifier is at a top of the hierarchy.
In Example 61, the subject matter of any one or more of Examples 59-60 optionally include wherein the domain identifier is flagged in the data identifier.
In Example 62, the subject matter of any one or more of Examples 57-61 optionally include wherein the means for using the inter-domain discovery includes: means for querying a local store of domain capabilities with the data identifier to produce search results; and means for returning a set of domain identifiers from the search results.
In Example 63, the subject matter of Example 62 optionally includes means for obtaining a service set of a different domain than the domain; and means for updating the local store of the island domain node with the service set.
In Example 64, the subject matter of Example 63 optionally includes wherein the means for obtaining the service set of the different domain includes means for querying an inter-domain service.
In Example 65, the subject matter of any one or more of Examples 63-64 optionally include wherein means for obtaining the service set of the different domain includes means for placing a discovery interest on an inter-island information centric network.
In Example 66, the subject matter of Example 65 optionally includes wherein the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest.
In Example 67, the subject matter of Example 66 optionally includes wherein the discovery interest includes a time-to-live, and wherein the discovery interest is removed from the pending interest structure based on the time-to-live.
In Example 68, the subject matter of any one or more of Examples 66-67 optionally include wherein the discovery interest includes a total count, and wherein the discovery interest is removed from the pending interest structure based on a number of responses received to the discovery interest and the total count.
In Example 69, the subject matter of any one or more of Examples 65-68 optionally include wherein the discovery interest includes a services filter, and wherein a response to the discovery interest has contents based on the services filter.
In Example 70, the subject matter of any one or more of Examples 65-69 optionally include wherein the discovery interest is sent at regular intervals.
In Example 71, the subject matter of any one or more of Examples 57-70 optionally include means for receiving a discovery interest from an inter-island information centric network; and means for providing a response to the discovery interest based on selectors in the discovery interest and a database of intra-island services.
In Example 72, the subject matter of Example 71 optionally includes wherein the means for providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes means for extracting a security identifier from the discovery interest and filtering entries of the database of intra-island services based on the security identifier.
In Example 73, the subject matter of any one or more of Examples 71-72 optionally include wherein the means for providing the response to the discovery interest based on selectors in the discovery interest and the database of intra-island services includes means for filtering entries of the database based on the selectors.
In Example 74, the subject matter of any one or more of Examples 71-73 optionally include means for communicating a second discovery interest to an intra-island information centric network front the island domain node; means for receiving service metrics from other intra-island nodes; and means for updating the database of intra-island services based on the received service metrics.
Example 75 is at least one machine-readable medium including instructions, which when executed by a machine, cause the machine to perform operations of any of the operations of Examples 1-74.
Example 76 is an apparatus comprising means for performing any of the operations of Examples 1-74.
Example 77 is a system to perform the operations of any of the Examples 1-74.
Example 78 is a method to perform the operations of any of the Examples 1-74.
The above detailed description includes references to the accompanying drawings, which form a part of the detailed description. The drawings show, by way of illustration, specific embodiments that may be practiced. These embodiments are also referred to herein as “examples.” Such examples may include elements in addition to those shown or described. However, the present inventors also contemplate examples in which only those elements shown or described are provided. Moreover, the present inventors also contemplate examples using any combination or permutation of those elements shown or described (or one or more aspects thereof), either with respect to a particular example (or one or more aspects thereof), or with respect to other examples (or one or more aspects thereof) shown or described herein.
All publications, patents, and patent documents referred to in this document are incorporated by reference herein in their entirety, as though individually incorporated by reference. In the event of inconsistent usages between this document and those documents so incorporated by reference, the usage in the incorporated reference(s) should be considered supplementary to that of this document; for irreconcilable inconsistencies, the usage in this document controls.
In this document, the terms “a” or “an” are used, as is common in patent documents, to include one or more than one, independent of any other instances or usages of “at least one” or “one or more.” In this document, the term “or” is used to refer to a nonexclusive or, such that “A or B” includes “A but not B,” “B but not A,” and “A and B,” unless otherwise indicated. In the appended claims, the terms “including” and “in which” are used as the plain-English equivalents of the respective terms “comprising” and “wherein.” Also, in the following claims, the terms “including” and “comprising” are open-ended, that is, a system, device, article, or process that includes elements in addition to those listed after such a term in a claim are still deemed to fall within the scope of that claim. Moreover, in the following claims, the terms “first,” “second,” and “third,” etc. are used merely as labels, and are not intended to impose numerical requirements on their objects.
The above description is intended to be illustrative, and not restrictive. For example, the above-described examples (or one or more aspects thereof) may be used in combination with each other. Other embodiments may be used, such as by one of ordinary skill in the art upon reviewing the above description. The Abstract is to allow the reader to quickly ascertain the nature of the technical disclosure and is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Also, in the above Detailed Description, various features may be grouped together to streamline the disclosure. This should not be interpreted as intending that an unclaimed disclosed feature is essential to any claim. Rather, inventive subject matter may lie in less than all features of a particular disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, with each claim standing on its own as a separate embodiment. The scope of the embodiments should be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

What is claimed is:

1. A system for information centric network island bridging, the system comprising:

a network interface to receive a request at an island domain node in an information centric network, the request including a data identifier; and

a controller to:

use an inter-domain discovery to identify a destination domain corresponding to the data identifier;

modify the request to create an inter-domain request; and

communicate the inter-domain request to an inter-domain information centric network.

2. The system of claim 1, wherein, to modify the request to create the inter-domain request, the controller is to add the destination domain to the data identifier.

3. The system of claim 1, wherein, to use the inter-domain discovery, the controller is to:

query a local store of domain capabilities with the data identifier to produce search results; and

return a set of domain identifiers from the search results.

4. The system of claim 3, wherein the controller is to:

obtain a service set of a different domain than the domain; and

update the local store of the island domain node with the service set.

5. The system of claim 4, wherein, to obtain the service set of the different domain, the controller is to place a discovery interest on an inter-island information centric network.

6. The system of claim 5, wherein the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest.

7. The system of claim 1, wherein the network interface is to receive a discovery interest from an inter-island information centric network; and

wherein the controller is to provide a response to the discovery interest based on selectors in the discovery interest and a database of intra-island services.

8. The system of claim 7, wherein the controller is to:

communicate a second discovery interest to an intra-island information centric network from the island domain node;

receive service metrics from other intra-island nodes; and

update the database of intra-island services based on the received service metrics.

9. A method for information centric network island bridging, the method comprising:

receiving a request at an island domain node in an information centric network, the request including a data identifier;

using an inter-domain discovery to identify a destination domain corresponding to the data identifier;

modifying the request to create an inter-domain request; and

communicating the inter--domain request to an inter-domain information centric network.

10. The method of claim 9, wherein modifying the request to create the inter-domain request includes adding the destination domain to the data identifier.

11. The method of claim 9, wherein using the inter-domain discovery includes:

querying a local store of domain capabilities with the data identifier to produce search results; and

returning a set of domain identifiers from the search results.

12. The method of claim 11, comprising:

obtaining a service set of a different domain than the domain; and

updating the local store of the island domain node with the service set.

13. The method of claim 12, wherein obtaining the service set of the different domain includes placing a discovery interest on an inter-island information centric network.

14. The method of claim 13, wherein the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest.

15. The method of claim 9, comprising:

receiving a discovery interest from an inter-island information centric network; and

providing a response to the discovery interest based on selectors in the discovery interest and a database of intra-island services.

16. The method of claim 15, comprising:

communicating a second discovery interest to an intra-island information centric network from the island domain node;

receiving service metrics from other intra-island nodes; and

updating the database of intra-island services based on the received service metrics.

17. At least one non-transitory machine readable medium including instructions for information centric network island bridging, the instructions, when executed by processing circuitry, cause the processing circuitry to perform operations comprising:

modifying the request to create an inter-domain request; and

communicating the inter-domain request to an inter-domain information centric network.

18. The at least one machine readable medium of claim 17, wherein modifying the request to create the inter-domain request includes adding the destination domain to the data identifier.

19. The at least one machine readable medium of claim 17, wherein using the inter-domain discovery includes:

returning a set of domain identifiers from the search results.

20. The at least one machine readable medium of claim 19, wherein the operations include:

obtaining a service set of a different domain than the domain; and

updating the local store of the island domain node with the service set.

21. The at least one machine readable medium of claim 20, wherein obtaining the service set of the different domain includes placing a discovery interest on an inter-island information centric network.

22. The at least one machine readable medium of claim 21, wherein the discovery interest is different than other interests of the inter-island information centric network such that a node of the inter-island information centric network does not remove the discovery interest, from a pending interest structure, in response to a single response to the discovery interest.

23. The at least one machine readable medium of claim 17, wherein the operations include:

receiving a discovery interest from an inter-island information centric network: and

24. The at least one machine readable medium f claim 23, wherein the operations include:

receiving service metrics from other intra-island nodes; and