Support for Notifications in CCN

Notification is a PUSH primitive used in the Internet today by many IoT and social applications. The nature of notifications varies with the application scenario, ranging from being mission critical to one that is best effort. Notifications can be unicast or multicast depending on whether the notification service is aware of all the consumers or not. A notification service is preceded by a consumer subscribing to a specific event such as, subscription to hash-tag feeds, health emergency notification service, or temperature sensor reading from a room in a building; following this subscription the service pushes notifications to consuming entities. It has to be noted that certain IoT applications expects notification end-to-end latency of few milliseconds . Industrial IoT applications have more stringent requirement in terms of QoS, timeliness, and reliability of message delivery. Though we term it as a Notification, this primitive can also be used for transactional exchange between two points. CCN optimizes networking around efficiently distributing already published content which the consumers learn through mechanisms like manifests containing the names of published content chunks and their locations. Applications relying on notifications requires event driven data to be pushed from multiple producers to multiple subscribers for which the current Interest/Data primitive is inefficient. This draft proposes to extend CCN's current primitives set with a new notification primitive that can be processed in a new way by the CCN forwarder to serve notification objectives. Notification here implies a PUSH semantic that is available with IP today and supported by other FIA architectures like MobilityFirst and XIA .

General notification requirements have been discussed in CoAP's Observe proposal to push notifications from the server to the clients. Here we discuss basic notification requirements from CCN's network layer perspective. Other requirements related to reliability, low latency, flow control can be engineered by the application or through more network layer state once the following requirements are met. Supporting PUSH Intent: CCN should provide efficient support for PUSH, where application's intent is able to PUSH content to listening application without expecting any data in return. Support Multicast: CCN network should be able to handle multicast notifications from a producer to multiple consumers for any service. Security: Just as a content object in the context of Interest/Data primitive provides data authentication and privacy, similar features should also be offered to notification objects. Routing/Forwarding Support: Name prefixes over which multicast notifications are managed should be handled in a different manner from the name prefixes over which Interest/Data primitive is used for content distribution. This differentiation applies both to the control as well as the forwarding plane. Minimizing Processing: Notification processing in the forwarder should be minimized considering the application's intent to PUSH data to listening consumers.

Recent CCN and NDN research have studied the problem of handling notifications and have proposed several solutions to handle this. However these approaches are not satisfactory as they use the current Interest and Data primitive to achieve notification objectives. These approaches are: Polling: This is a straight forward application of the Interest and Data primitive, where consumers periodically checks the producers for any new information. The efficiency of this approach depends on the frequency of polling. In this case, very low frequency may result in missing critical updates, and large frequency could result in high PIT occupancy by such polling Interests and overall higher traffic overhead. This scheme is inefficient particularly for event driven and asynchronous updates. Long lived Interests: As the name suggests, applications can issue Interests set to a high lifetime to the producing nodes. Considering the increasing social networking and IoT application traffic, the number of such PIT Interests can be very large occupying valuable resources. Interest overloading: Small notifications such as actuating commands can be send by overloading the Interest primitive by adding information as suffixes to the name or including signed and/or encrypted data as a Interest payload . As these Interests are used as notifications, their lifetime is set to zero. Overloading Interests to convey notifications may not be desirable, as today the Interests are treated as a content request primitive by forwarders incurring unnecessary PIT/CS incurring unnecessary overhead. This also opens the possibility of new attack vectors, such as the notifications can be blocked by malicious consumers who may express Interests with the same name (assuming names are easily derivable). Interest Trigger: Another way to use Interest is to first notify the consumers about a produced data, and then have the data pulled by the consumers. This use of Interest for notification is also inefficient as Interest (that intends notification) is processed as a content fetch request by the router, incurring additional round trip delay before the produced data arrives at the listening consumer. To be more specific it incurs a minimum of 4 messages, but more messages for the same reliability and robustness as TCP. To summarize CCN and NDN operates on PULL primitive optimized for content distribution applications. Emulating PUSH operation over PULL has the following issues: 1) it is a mismatch between an application's intent to PUSH data and the PULL APIs currently available; 2) unless Interests are marked distinctly, overloading Interests with notification data will undergo PIT/CS processing and are also subjected to similar routing and forwarding policies as regular Interests which is inefficient; 3) another concern in treating PUSH as PULL is with respect to the effect of local strategy layer routing policies, where applying the intent to experiment with multiple faces to fetch content is not required for notification messages. This motivates the need for treating notifications as a separate class of traffic which would allow a forwarder to apply the appropriate processing, routing and forwarding processing in the network.

Notification is a new type of packet hence can be subjected to different processing logic by a forwarder. By definition, a notification message is a PUSH primitive, hence is not subjected to PIT/CS processing. This primitive can also be used by any other transactional or content distribution application towards service authentication or exchanging contextual information between end points and the service.

The wire packet format for a Notification is shown in Fig. 1 and Fig. 2. Fig. 1 shows the Notification fixed header considering the CCNx1.0 encoding, and Fig. 2 shows the format for the CCN Notification message, which is used to transport the notification data. We next discuss these two packet segments of the Notification message.

Notification Fixed Header: The fields in the fixed header that have new meaning in the context of notifications are discussed next, while the other fields follow the definition in . Packet Type: This new type code identifies that the packet is of type Notification [TBD]. Optional Hop-by-hop header TLVs : Encodes any new hop-by-hop headers relevant to notifications [TBD]. CCN Notification message: The CCN Notification message is a Content Object as in . Notifications are always routed on the top level Content Object (outer CO) name. Notification itself can be encoded in two forms depending on the application requirement: Notification with single name: In this case the notification contains a single content object. Here the producer generates notification using the same name used by consumers on which they listen on. Notification with two names: In this case the notification contains a top level Content Object (outer CO), that encapsulates another Content Object (inner CO). With an encapsulated Content Object, the meaning is that notification producers and consumers operate on different name-spaces requiring separate name-data security binding. A good application of the encapsulation format is a PUB/SUB service, where the consumer learns about the notification service name offline, and the producer who is decoupled from the consumer generates a new Content Object using its own name and pushes the notification to the consumer. The interpretation of the fields shown in Fig. 2 are as follows: MessageType : The CCN message type is of type Content Object. Name TLV : Name TLV in the Content Object is used to route the Notification. Optional Metadata TLV: These TLVs carry metadata used to describe the Notification payload. Message Payload Type: This is of type T_PAYLOADTYPE defined in CCNx.1.0 or a new encapsulation type (T_ENCAP) that indicates the presence of another encapsulated Content Object [TBD]. Optional Encapsulated Content Object: This is an optional encapsulated Content Object newly defined for the Notification primitive. The name in the encapsulated Content Object corresponds to the producer's name-space, or anything else based on the application logic. The rational for an encapsulated Content Object was discussed earlier. Optional Security Validation data: The Content Object optionally carries security validation payload as per CCNx1.0.

The following steps are followed by a CCN forwarder to process the Notification packet. Notification packet type is identified in the fixed header of a CCN packet with a new type code. The Notification carries a Content Object, whose name is used for routing. This name is matched against the FIB entries to determine the next hop(s). Novel strategy layer routing techniques catering to the notification traffic can be applied here. CCN forwarder also processes the optional metadata associated with the Notification meant for the network to help with the forwarding strategy, for e.g., mission critical notifications can be given priority over all other traffic. As mentioned earlier, CCN forwarder MUST NOT cache the Content Objects in the notifications.

The proposed processing logic of Notifications that bypass the processing of PIT/CS has the following security implications: Flow Balance : PIT state maintains the per-hop flow balance over all the available faces by enforcing a simple rule, that is, one Content Object is send over a face for a single Interest. Bypassing PIT processing compromises this flow balancing property. For scenarios where the notification traffic volume is not high such as for IoT applications, the impact may not be significant. However, this may not be the case considering the plethora of social networking and emerging IoT applications in a general Internet scenario. This flow balance tradeoff has to be understood considering an application's intent to PUSH data and the latency introduced by processing such traffic if a PULL primitive is used. Also PIT offers a natural defense mechanism by throttling traffic at the network edge, considering the provisioned PIT size, and bypassing it could exacerbate DDOS attacks on producing end points. Cache Poisoning: This draft doesn't recommend the caching of the Content Object in the Notification payload, though doing so might help in increasing the availability of notification information in the network. A possible exception would be if the inner CO is a nameless object . as those can only be fetched from CS by hash We leave this possibility of applying policy-based caching of Notification Content Objects for future exploration. The recommendation for not caching these Content objects is that, in a regular Interest/Content Object exchange, content arrives at the forwarder and is cached as a result of per-hop active Interest expression. Unsolicited Content Objects, as in the case of the Notification, violates this rule, which could be exploited by malicious producers to generate DDOS attack against the cache resource of a CCN infrastructure.

Appropriate routing policies should be employed to ensure reliable forwarding of a notification to its one or many intended receivers. The name in the notification identifies a host or a multicast service being listened to by the multiple intended receivers. Two types of routing strategies can be adopted to handle notifications, depending on whether or not an explicit pub/sub state is maintained in the forwarder. Stateless forwarding: In this case the notification only relies on the CCN FIB state to route the notification. The FIB entries are populated through a routing control plane, which distinguishes the FIB states for the notification service from the content fetching FIB entries. Through this logical separation, Notifications can be routed by matching its name with the matching FIB policy in the CCN forwarder, hence processed as notification multicast. Stateful forwarding: In this case, specific subscription state is managed in the forwarder to aid notification delivery. This is required to scale notifications at the same time apply notification policies, such as filter notifications or to improve notification reliability and efficiency to subscribing users .

This proposal doesn't provide any form of reliability. Reliability can be realized by the specific application using the proposed notification primitive, for instance using the following potential approaches: Caching: This proposal doesn't propose any form of caching. But caching feature can be explored to improve notification reliability, and this is a subject of future study. For instance, consumers, which expect notifications and use external means (such as periodic updates or by receiving manifests) to track notifications, can recover the lost notifications using the PULL feature of CCN. Notification Acknowledgment: If the producer maintains per-receiver state, then the consumer can send back notification ACK or NACK to the producer of having received or not received them.

Here we provide the discussions related to the use of Notification in different scenarios.

A PUB/SUB system provides a service infrastructure for subscribers to request update on a set of topics of interest, and with multicast publishers publishing content on those topics. A PUB/SUB system maps the subscribers' interests to published contents and pushes them as Notifications to the subscribers. A PUB/SUB system has many requirements as discussed in which include low latency, reliability, fast recovery, scalability, security, minimizing false (positive/negative) notifications. Current IP based PUB/SUB systems suffer from interoperability challenges because of application-defined naming approach and lack of support of multicast in the data plane. The proposed Notification primitive can be used to realize large scale PUB/SUB system, as it unifies naming in the network layer and support for name-based multicasting. Depending on the routing strategy discussed earlier, two kind of PUB/SUB approaches can be realized : 1) Rendezvous style approach ; 2) Distributed approach. Each of these approaches can use the Notification primitive to implement their PUSH service. In the Rendezvous style approach, a logically centralized service maps subscriber's topic interest with the publisher's content and pushes it as notifications. If stateless forwarding is used, the routing entries contain specific application-ID's requesting a given notification, to handle scalability, a group of these application can share a multicast-ID reducing the state in the FIB. In the Distributed approach, the CCN/NDN protocol is further enhanced with new subscription primitive for the subscription interested consumers. When a consumer explicitly susbcribes to a multicast topic, its subscription request is forwarded to the upstream forwarder which manages this state mapping between subscription names to the downstream faces which has expressed interest for Notifications being pushed under that prefix. An example of the network layer based approach is the COPSS notification proposal . Here a PUB/SUB multi-cast state state, called the subscribers interest table, is managed in the forwarders. When a Notification arrives at a forwarder, the content descriptor in the notification is matched to the PUB/SUB state in the forwarder to decide the faces over which the Notification has to be forwarded.