[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00 01                                                         
ICN Research Group                                          R. Ravindran
Internet-Draft                                            A. Chakraborti
Intended status: Informational                       Huawei Technologies
Expires: January 7, 2016                                        M. Mosko
                                                                I. Solis
                                                            July 6, 2015

                    Support for Notifications in CCN


   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 January 7, 2016.

Copyright Notice

   Copyright (c) 2015 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents

Ravindran, et al.        Expires January 7, 2016                [Page 1]

Internet-Draft            Interest Notification                July 2015

   (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.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Notification Primitive in CCN . . . . . . . . . . . . . . . .   2
   3.  Notification Message Encoding . . . . . . . . . . . . . . . .   3
   4.  Notification Processing . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   6.  Use Case Scenarios  . . . . . . . . . . . . . . . . . . . . .   6
   7.  Informative References  . . . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Motivation

   Notification is an important primitive in the Internet today widely
   used in many IoT and social applications.  The nature of
   notifications varies with 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; a good
   example is subscription to hash-tag feeds, health emergency
   notification service, 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.

2.  Notification Primitive in CCN

   CCN/NDN operates on PULL primitive catering primarily to content
   distribution applications.  Emulating PUSH operation over PULL has
   following issues: 1) it is a mismatch between application intent to
   PUSH data and PULL API currently available; 2) unless marked
   distinctly, such packets may undergo PIT/CS processing and also
   subjected to similar routing policies as PULL which is inefficient, a
   good example is when PUSH and PULL shares similar routing prefix; 3)
   another concern of treating PUSH as PULL is with respect to the

Ravindran, et al.        Expires January 7, 2016                [Page 2]

Internet-Draft            Interest Notification                July 2015

   affect of local strategy layer routing policies, where the intent to
   experiment with multiple faces applied to fetch content is not
   desirable for notification messages.

   Currently notifications in CCN/NDN is supported by overloading the
   Interest primitive by setting its lifetime to zero [1].  Overloading
   lifetime to convey notifications is not desirable.  Depending on the
   implementation, this approach may not avoid unnecessary processing of
   the notification traffic incurring packet processing delay in each
   CCN router.  Also associated issues on PIT aggregation may arise if
   Interest with the same name arrives with non-zero lifetime, opening
   up the possibility of new attack vectors.

   Treating notifications as a separate class of traffic allows
   forwarder to apply appropriate processing , routing and forwarding
   logic for such type of traffic.  Other approaches have been proposed
   such as modification to CCN transport applying new data structures as
   in [6], which complements the notification primitive proposed in this

   Also it is important to note that other FIA architectures such as
   MobilityFirst [8] and XIA [9] supports both PUSH and PULL primitive.

   To address these concerns we propose a new primitive called
   Notifications.  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 which doesn't
   expect any Content Object response, hence should not be subjected to
   PIT/CS processing.  This primitive can also be used by any other
   transactional or content distribution application applied towards
   authentication or for exchanging contextual information.

3.  Notification Message Encoding

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

Ravindran, et al.        Expires January 7, 2016                [Page 3]

Internet-Draft            Interest Notification                July 2015

                                             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   |         PacketLength         |
                        |   HopLimit    |   Reserved    |     Flags     | HeaderLength |
                        / Optional Hop-by-hop header TLVs                              /
                        /              CCN Notification Message                        /

                                  Figure 1: Notification fixed header

                                              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  |
                         |                    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 the notifications are discussed next,
   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].

   o  PacketPayload TLV: This encodes the CCN notification message.

Ravindran, et al.        Expires January 7, 2016                [Page 4]

Internet-Draft            Interest Notification                July 2015

   CCN Notification message: The CCN Notification message is a Content
   Object as in [1], which optionally encapsulates another Content
   Object.  The name in the top level Content Object is used for
   routing.  The need for an encapsulated Content Object is application
   driven.  If the Notification only includes the top level Content
   Object, the interpretation is that the producer and consumer agrees
   on the same name to transport the notification data.  With an
   encapsulated Content Object the meaning is that notification
   producers and consumers operate on different name space.  A good
   application of the encapsulation format is a PUB/SUB service, where
   the consumers learns about the notification service name offline, and
   the producers who are decoupled from the consumers generate new
   Content Objects using its own name and pushes it to the consumers.

   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

   o  Optional Metadata TLV: These TLVs carry metadata used to describe
      the Notification payload.

   o  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, 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.

4.  Notification Processing

   The following steps are followed by a CCN forwarder processing
   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).

Ravindran, et al.        Expires January 7, 2016                [Page 5]

Internet-Draft            Interest Notification                July 2015

      Novel strategy layer routing techniques catering to the
      notification traffic can be applied here.

   o  Optional metadata associated with the Notification meant for the
      network is processed by the forwarder, for e.g., mission critical
      notifications can be given priority over all other traffic.

   o  As suggested earlier, Content Objects in the notifications
      shouldn't be cached by the intermediate forwarders.

5.  Security Considerations

   The proposed processing logic of Notifications bypassing the PIT/CS
   has following security implications:

   Flow Balance : The PIT state maintains per-hop flow balance over all
   faces by enforcing one Content Object for an Interest send over a
   face.  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.
   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 application intent to PUSH data and latency introduced
   due to processing such traffic if PULL primitive is used.  Also PIT
   offers a natural defense mechanism by throttling traffic at the
   network edge considering the provisioned PIT size, 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 this helps
   in increasing the availability of notification information in the
   network.  We leave this possibility of applying policy based caching
   of Notification Content Objects for future exploration.  The
   recommendation for not caching these Content Object 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.

6.  Use Case Scenarios

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

Ravindran, et al.        Expires January 7, 2016                [Page 6]

Internet-Draft            Interest Notification                July 2015

7.  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]        Azgin, A., Ravindran, R., and G. Wang, "A Scalable
              Mobility-Centric Architecture for Named Data Networking.",
              ICCCN (Scene Workshop) , 2014.

   [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]        CCNx Label Forwarding, CCNLF., "http://www.ccnx.org/pubs/
              ccnx-mosko-labelforwarding-01.txt.", 2013.

   [8]        NSF FIA project, MobilityFirst.,
              "http://www.nets-fia.net/", 2010.

   [9]        NSF FIA project, XIA., "https://www.cs.cmu.edu/~xia/",

Authors' Addresses

   Ravishankar Ravindran
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: ravi.ravindran@huawei.com

Ravindran, et al.        Expires January 7, 2016                [Page 7]

Internet-Draft            Interest Notification                July 2015

   Asit Chakraborti
   Huawei Technologies
   2330 Central Expressway
   Santa Clara, CA  95050

   Email: asit.chakraborti@huawei.com

   Marc Mosko
   Palo Alto, California  94304

   Phone: +01 650-812-4405
   Email: marc.mosko@parc.com

   Ignacio Solis
   Palo Alto, California  94304

   Phone: +01 650-812-4405
   Email: ignacio.solis@parc.com

Ravindran, et al.        Expires January 7, 2016                [Page 8]