Internet DRAFT - draft-ravi-ccn-notification
draft-ravi-ccn-notification
ICN Research Group R. Ravindran
Internet-Draft A. Chakraborti
Intended status: Informational S. Amin
Expires: September 22, 2016 Huawei Technologies
M. Mosko
I. Solis
PARC
March 21, 2016
Support for Notifications in CCN
draft-ravi-ccn-notification-01
Abstract
This draft proposes a new packet primitive called Notification for
CCN. Notification is a PUSH primitive and can be unicast or
multicast to multiple listening points. Notifications do not expect
a Content Object response hence only requires the use of FIB state in
the CCN forwarder. Emulating Notification as a PULL has performance
and forwarding implications. The draft proposes a new fixed header
primitive called Notification and a CCN message encoding using
Content Object primitive to transport Notifications. These
discussions are presented in the context of CCNx1.0 [1] proposal.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on September 22, 2016.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Ravindran, et al. Expires September 22, 2016 [Page 1]
Internet-Draft Interest Notification March 2016
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Notification Requirements in CCN . . . . . . . . . . . . . . 3
3. Current Approaches . . . . . . . . . . . . . . . . . . . . . 3
4. Proposed Notification Primitive in CCN . . . . . . . . . . . 5
5. Notification Message Encoding . . . . . . . . . . . . . . . . 5
6. Notification Processing . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Annex . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Routing Notifications . . . . . . . . . . . . . . . . . . 8
8.2. Notification reliability . . . . . . . . . . . . . . . . 9
8.3. Use Case Scenarios . . . . . . . . . . . . . . . . . . . 9
8.3.1. Realizing PUB/SUB System . . . . . . . . . . . . . . 9
9. Informative References . . . . . . . . . . . . . . . . . . . 10
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11
1. Introduction
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 [2]. 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
Ravindran, et al. Expires September 22, 2016 [Page 2]
Internet-Draft Interest Notification March 2016
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
[10] and XIA [11].
2. Notification Requirements in CCN
General notification requirements have been discussed in CoAP's
Observe proposal [4] 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.
o 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.
o Support Multicast: CCN network should be able to handle multicast
notifications from a producer to multiple consumers for any
service.
o 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.
o 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.
o Minimizing Processing: Notification processing in the forwarder
should be minimized considering the application's intent to PUSH
data to listening consumers.
3. Current Approaches
Recent CCN and NDN research [6] [7] 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
Ravindran, et al. Expires September 22, 2016 [Page 3]
Internet-Draft Interest Notification March 2016
current Interest and Data primitive to achieve notification
objectives. These approaches are:
o 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.
o 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.
o 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 [1]. 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).
o 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
Ravindran, et al. Expires September 22, 2016 [Page 4]
Internet-Draft Interest Notification March 2016
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.
4. Proposed Notification Primitive in CCN
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.
5. Notification Message Encoding
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.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+--------------+
| Version | PacketType= | |
| | Notification | PacketLength |
+---------------+---------------+---------------+--------------+
| HopLimit | Reserved | Flags | HeaderLength |
+---------------+---------------+---------------+--------------+
/ Optional Hop-by-hop header TLVs /
+---------------+---------------+---------------+--------------+
/ Content Object as Notification Message /
+---------------+---------------+---------------+--------------+
Figure 1: CCN Notification fixed header
Ravindran, et al. Expires September 22, 2016 [Page 5]
Internet-Draft Interest Notification March 2016
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+--------------+
|MessageType = Content Object | MessageLength |
+---------------+---------------+---------------+--------------+
| Name TLV |
+---------------+---------------+---------------+--------------+
| Optional MetaData TLVs |
+---------------+---------------+---------------+--------------+
| Message Payload Type | Message Type Length |
+---------------+---------------+---------------+--------------+
| Payload or Optional Content Object |
+---------------+---------------+---------------+--------------+
/ Optional CCNx ValidationAlgorithm TLV /
+---------------+---------------+---------------+--------------+
/ Optional CCNx ValidationPayload TLV (ValidationAlg required) /
+---------------+---------------+---------------+--------------+
Figure 2: CCN 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 [1].
o Packet Type: This new type code identifies that the packet is of
type Notification [TBD].
o 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 [1]. 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:
o 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.
o 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
Ravindran, et al. Expires September 22, 2016 [Page 6]
Internet-Draft Interest Notification March 2016
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:
o MessageType : The CCN message type is of type Content Object.
o Name TLV : Name TLV in the Content Object is used to route the
Notification.
o Optional Metadata TLV: These TLVs carry metadata used to describe
the Notification payload.
o 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].
o 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.
o Optional Security Validation data: The Content Object optionally
carries security validation payload as per CCNx1.0.
6. Notification Processing
The following steps are followed by a CCN forwarder to process the
Notification packet.
o 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.
o 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.
o As mentioned earlier, CCN forwarder MUST NOT cache the Content
Objects in the notifications.
Ravindran, et al. Expires September 22, 2016 [Page 7]
Internet-Draft Interest Notification March 2016
7. Security Considerations
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 [12]. 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.
8. Annex
8.1. Routing Notifications
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.
Ravindran, et al. Expires September 22, 2016 [Page 8]
Internet-Draft Interest Notification March 2016
o 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.
o 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 [8].
8.2. Notification reliability
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.
8.3. Use Case Scenarios
Here we provide the discussions related to the use of Notification in
different scenarios.
8.3.1. Realizing PUB/SUB System
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 [6] which include low latency,
reliability, fast recovery, scalability, security, minimizing false
(positive/negative) notifications.
Ravindran, et al. Expires September 22, 2016 [Page 9]
Internet-Draft Interest Notification March 2016
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 [6].
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.
9. Informative References
[1] CCN Wire format, CCNX1., "http://www.ietf.org/id/
draft-mosko-icnrg-ccnxmessages-00.txt.", 2013.
[2] Osseiran, A., "Scenarios for 5G Mobile and Wireless
Communications: The Vision of the METIS Project.", IEEE
Communication Magazine , 2014.
[3] DNS Security Introduction and Requirements, DNS-SEC.,
"http://www.ietf.org/rfc/rfc4033.txt.", 2005.
[4] Observing Resources in CoAp, observe.,
"https://tools.ietf.org/html/draft-ietf-core-observe-16.",
2015.
Ravindran, et al. Expires September 22, 2016 [Page 10]
Internet-Draft Interest Notification March 2016
[5] Cisco System Inc., CISCO., "Cisco visual networking index:
Global mobile data traffic forecast update.", 2009-2014.
[6] Chen, J., Arumaithurai, M., Jiao, L., Fu, X., and K.
Ramakrishnan, "COPS: An Efficient Content Oriented
Publish/Subscribe System.", ACM/IEEE Symposium on
Architectures for Networking and Communications Systems
(ANCS 2011) , 2011.
[7] Amadeo, M., Campolo, C., and A. Molinaro, "Internet of
Things via Named Data Networking: The Support of Push
Traffic", Network of the Future (NOF), 2014 International
Conference and Workshop on the , 2014.
[8] Francois et al, J., "CCN Traffic Optimization for IoT",
Proc. of NoF , 2013.
[9] CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/
ccnx-mosko-labelforwarding-01.txt.", 2013.
[10] NSF FIA project, MobilityFirst.,
"http://www.nets-fia.net/", 2010.
[11] NSF FIA project, XIA., "https://www.cs.cmu.edu/~xia/",
2010.
[12] Mosko, M., "Nameless Objects.", IETF/ICNRG, Paris
Interim 2016, 2016.
Authors' Addresses
Ravishankar Ravindran
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: ravi.ravindran@huawei.com
Asit Chakraborti
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: asit.chakraborti@huawei.com
Ravindran, et al. Expires September 22, 2016 [Page 11]
Internet-Draft Interest Notification March 2016
Syed Obaid Amin
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: obaid.amin@huawei.com
Marc Mosko
PARC
Palo Alto, California 94304
USA
Phone: +01 650-812-4405
Email: marc.mosko@parc.com
Ignacio Solis
PARC
Palo Alto, California 94304
USA
Phone: +01 650-812-4405
Email: ignacio.solis@parc.com
Ravindran, et al. Expires September 22, 2016 [Page 12]
