+---------------------------------------------------------------+
| NetInf Core Network                                           |
|                   +--------+                                  |
|                   | NetInf |                     +-----+      |
|           +-------+ Router +-------+             | NRS |      |
|           |       +--------+       |             |     |      |
|           |                        |             +-----+      |
|       +---+----+              +----+---+                      |
|       | NetInf |              | NetInf |                      |
|       | Router |              | Router +---------+            |
|       +---+----+              +--------+         |            |
|           |                                      |            |
+---------------------------------------------------------------+
            |                                      |
            |                        +--------------------------+
 XXXXXXXXXXX+XXXXXXXXXXXXXXXXXXXXXX  | NetInf      |            |
 X                                X  | Access +----+---+        |
 X             Internet           X  | Network| NetInf |        |
 X                                X  | at     | Router |        |
 XXXXXXX+XXXXXXXXXXXXXXXX+XXXXXXXXX  | event  ++------++        |
        |                |           | venue   |      |         |
        |                |           |         |      |         |
 XXXXXXX+XXXXXXX  XXXXXXXXXXXXXXXXX  |  +------+-+  +-+------+  |
 X WiFi Access X  X Mobile Access X  |  | NetInf |  | NetInf |  |
 XXXXXXX+XXXXXXX  XXXX+XXXXXX+XXXXX  |  | Router |  | Router |  |
        |             |      |       |  +----+---+  +----+---+  |
        |             |      |       |       |           |      |
        |             |      |       |  XXXXX+XXXXXXXXXXX+XXX   |
      +-+-+         +-+-+    |       |  X    WiFi Access    X   |
      | P |         | P |    |       |  XXXXXXX+XXXXXX+XXXX+X   |
      +---+         +---+    |       |         |      |    |    |
                             |       | +---+ +-+-+  +-+-+ ++--+ |
                             +---------+ R | | P |  | R | | P | |
  R:   Recording client              | +---+ +---+  +---+ +---+ |
  P:   Playing client                |                          |
  NRS: Name Resolution Service       +--------------------------+

	

Figure 1: System architecture

Recording and playing clients at the event venue can connect to the system using local WiFi or mobile internet (3G/4G). Before a client can start publishing or playing, it first connects to a NetInf router. Consequently this router acts as the first hop NetInf node for the client. Clients on local WiFi at the event venue connect to a NetInf router in the local access network. Clients on the internet connect to a NetInf router in the NetInf core network.

The NetInf core network hosts a Name Resolution Service (NRS). This service is responsible for resolving object names into locators. It also provides search function for the registered Named Data Objects (NDOs).

ICN employs ubiquitous caching. Therefore every NetInf router in the architecture is coupled with a local cache. These routers cache NDOs on-path and serve them to corresponding GET requests when there is a cache hit. This ensures that clients are served data from the local network (if the data is cached) and that the edge links (like the one between the NetInf access network and the NetInf core network as seen in Figure 1) are not choked with traffic.

3. Video Format

The transport of video chunks using NetInf described in this specification can be used for video with any type of encoding. As an example we describe the mpeg4/H.264 encoding used at the above referenced events.

When transporting video over an best effort network, such an ICN network, there are two main goals: to minimize the delay and to avoid rebuffering events. Unfortunately the means to achieve these goals are conflicting. Small buffers are needed to minimize delay, large buffers are needed to minimize the risk of rebuffering.

At the events referenced above the video generated by the recording device were encoded using H.264/AVC video format and had the mime type "video/avc". The video is split into chunks so that each chunk fits into an NDO. Chunking is done at I-frames in order to ensure that video chunks are independent of each other. The H.264 encoded chunks are packaged into MP4 containers. The frame rate and I-frame intervals are configurable. The parameters can be tweaked to achieve different tradeoffs between the playback latency and the NDO header overhead. The I-frame interval controls the size of the generated video chunks. A typical setting of 30 fps and 2 seconds, respectively, was used with the largest available 16:9 resolution less than 864x480, resulting in a video data rate of about 1 Mbps. Each chunk corresponds, in this case, to a video playout of 2 seconds. To avoid rebuffering the playing application buffers of video data was typically set to 10 seconds.

4. Video Transport using NetInf Protocol

This section describes how NetInf named data objects (NDOs) are created from the video chunks in the previous section, and how the NDOs are made available to clients using the NetInf protocol [I-D.kutscher-icnrg-netinf-proto] with extensions for subscriptions using the NetInf SUBSCRIBE and NOTIFY messages. As described in the NetInf protocol specification, a NetInf NDO consists of the object's data and, optionally, associated JSON-encoded meta-data.

Two kinds of NetInf NDOs are created for a video stream: one carrying the video chunks, and another carrying a "header", or manifest, that describes the stream of video chunks. The latter is described in the next section.

4.1. Video chunk NDOs

Each video chunk is turned into one NetInf NDO. The bytes of the video chunk are directly put into the data content of the NDO.

The following meta-data items MUST be supplied with video chunk NDOs:

chunk_number

The sequence number of the chunk in the video starting with zero. (Integer)

video_name

The name (ni hash [RFC6920]) of the video stream header NDO encoded with the URL-SAFE variant of BASE64 without padding. (ASCII string)

start_time

The starting time of the chunk in microseconds since the start of the video. (Long integer)

duration

The duration of the video chunk in microseconds. (Long integer)

signature

A digital signature for the chunk. The signature is an RSA signature on the SHA-256 hash of the content as defined in the PKCS #1: RSA Cryptography Standard. The result is BASE64 encoded without padding or wrapping, using the URL-SAFE encoding variant. (ASCII string)

4.2. Publishing video chunk NDOs

Video chunk NDOs are published using NetInf PUBLISH as described in the NetInf protocol specification [I-D.kutscher-icnrg-netinf-proto]. The JSON-encoded meta-data is supplied as a "meta" item of the "ext" parameter in the PUBLISH message.

In addition, a NetInf NOTIFY message MUST be sent for each successfully published video chunk. The NOTIFY message contains the ni URI [RFC6920] of the stream header NDO and the ni URI of the just published video chunk NDO. It also contains the sequence number and signature of the video chunk NDO.

The destination for both of these messages is normally a designated next-hop NetInf router for the client. How the client finds this destination is out of scope for this specification.

4.3. Receiving video chunk NDOs

Clients that wish to receive video chunks MAY register to receive the above notifications using the NetInf SUBSCRIBE extension. They will then receive the NetInf NOTIFY, and can then issue a NetInf GET to retrieve the newly published video chunk.

5. Video Manifest

This section describes the video stream header and how it is encoded and published as a NetInf NDO.

5.1. Video stream header NDOs

Each video stream MUST be described and identified by publishing a stream header NDO. It contains various information about the stream and a public key that can be used by clients to verify the authenticity of the video chunk NDOs. The hash part the NetInf "ni" name of the header NDO is used to name the video stream. That hash is included as meta-data of the video chunk NDOs.

The NDO data (content) MUST be constructed by concatenating the bytes of the following items in binary form:

MAGIC

The ASCII character sequence "ENS0".

Public key length

Four-byte integer with the length of the public key. (Note: needs to be network byte order/big endian, but the implementation likely uses little endian.)

Public key

The public key for the stream encoded according to X.509 ASN.1 SubjectPublicKeyInfo.

Contents

Any additional data provided by the client. (optional)

The following JSON-encoded meta-data MUST be included with header NDOs:

title

A title for the video stream as provided by the client. (ASCII string)

description

A descriptive text provided by the client. (ASCII string)

region

A short text description of the location where the video is recorded. (ASCII string)

stream-start

The time of the start of the stream in Unix time in milliseconds. (Long integer)

The following JSON-encoded meta-data SHOULD be included with header NDOs:

stream-end

The time of the end of the stream in Unix time in milliseconds. The NDO SHOULD be updated with this item when the recording has completed. (Long integer)

gps-x

The X coordinate (longitude) of the location of the recorded video in degrees. (Double floating point number)

gps-y

The Y coordinate (latitude) of the location of the recorded video in degrees. (Double floating point number)

5.2. Publishing video header NDOs

Video header NDOs are published using NetInf PUBLISH as described in the NetInf protocol specification [I-D.kutscher-icnrg-netinf-proto]. The JSON-encoded meta-data is supplied as a "meta" item of the "ext" parameter in the PUBLISH message.

5.3. Browsing available video streams

Clients can use the NetInf SEARCH message to collect information about the published video stream headers, and with the result populate a browser listing in the user interface. The user can with that choose a video to play.

6. Security Considerations

TBD

7. Acknowledgements

The work behind and the writing of this document are supported by the activity `14082 Networks for Future Media Distribution' within EIT Digital (formerly EIT ICT labs).

8. References

8.1. Normative References

[I-D.kutscher-icnrg-netinf-proto]	Kutscher, D., Farrell, S. and E. Davies, "The NetInf Protocol", Internet-Draft draft-kutscher-icnrg-netinf-proto-01, February 2013.
[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC6920]	Farrell, S., Kutscher, D., Dannewitz, C., Ohlman, B., Keranen, A. and P. Hallam-Baker, "Naming Things with Hashes", RFC 6920, DOI 10.17487/RFC6920, April 2013.

8.2. Informative References

[Dannewitz2013]	Dannewitz, C., Kutscher, D., Ohlman, B., Farrell, S., Ahlgren, B. and H. Karl, "Network of Information (NetInf) - An Information-Centric Networking Architecture", Computer Communications 36 (7). pp. 721-735. ISSN 0140-3664, April 2013.
[Malik2015a]	Malik, A., Ahlgren, B., Ohlman, B., Lindgren, A., Ngai, E., Klingsbo, L. and M. Lång, "Experiences from a field test using ICN for live video streaming", Proc. Workshop on Multimedia Streaming in Information-Centric Networks, in conjunction with ICME 2015, Turin, Italy, July 2015.
[Malik2015b]	Malik, A., Ahlgren, B. and B. Ohlman, "NetInf Live Video Streaming for Events with Large Crowds (demo)", Proc. 2nd ACM Conference on Information-Centric Networking (ICN), San Francisco, California, USA, Sept-Oct 2015.

Authors' Addresses