[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Nits]

Versions: 00

Internet Engineering Task Force                               R. Herrero
Internet-Draft                                   Northeastern University
Intended status: Informational                              C. St.Pierre
Expires: December 23, 2019                                          L7TR
                                                           June 21, 2019


           RTP Payload Format for CCSDS Compressed Image Data
                       draft-herrero-avt-ccsds-00

Abstract

   This memo describes an RTP payload format for the Consultative
   Committee for Space Data Systems (CCSDS) Compressed Image Data
   standard [CCSDS122.0].  The compression is typically applied to two-
   dimensional and three-dimensional data cubes resulting from
   multispectral and hyperspectral imagining instruments.

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 https://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 December 23, 2019.

Copyright Notice

   Copyright (c) 2019 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
   (https://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




Herrero & St.Pierre     Expires December 23, 2019               [Page 1]


Internet-Draft       CCSDS Image RTP Payload Format            June 2019


   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Header Format . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  RTP Fixed Header Usage  . . . . . . . . . . . . . . . . .   3
     3.2.  RTP Payload Header Format . . . . . . . . . . . . . . . .   4
   4.  RTP Packetization . . . . . . . . . . . . . . . . . . . . . .   5
   5.  SDP Parameters  . . . . . . . . . . . . . . . . . . . . . . .   6
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   7.  Normative References  . . . . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The CCSDS compressed image data standard can be used to produce both
   lossy and lossless compression in a scenario that targets high-rate
   instruments used on board of spacecraft.  Moreover it provides a
   trade-off between compression performance and complexity with
   particular emphasis on spacecraft applications.  As a low complexity
   mechanism it supports fast and low power hardware implementations.

   The compressor consists of two functional parts, shown in Figure 1, a
   Discrete Wavelet Transform module that performs decorrelation and a
   Bit-Plane Encoder which encodes the decorrelated data.  It is outside
   the scope of this document to further describe in detail this
   procedure.  Please refer to [CCSDS122.0] for more information.

                 +----------+    +----------+
                 | Discrete |    |   Bit    |
   Raw Image ==> |   Wave   |--->|  Plane   | ==> Compressed Image
                 | Transform|    |  Encoder |
                 +----------+    +----------+

              Block diagram of the CCSDS encoder[CCSDS122.0].

                                 Figure 1

   The coded data that results from each CCSDS compressed image is
   composed of a sequence of self-contained and self-defined segments.
   Depending on the size of the segments several RTP packetization
   scenarios are possible; (1) Each RTP packet transports a single
   segment, (2) Each RTP packet transports several fragments or (3) Each
   fragment is transported across several RTP packets.  In particular,
   for cases (2) and (3), if segments are packetized directly over RTP



Herrero & St.Pierre     Expires December 23, 2019               [Page 2]


Internet-Draft       CCSDS Image RTP Payload Format            June 2019


   there is potential for corruption that extends beyond segments
   affected by packet loss.

              Packet #1: [RTP Header][1][2][3]
              Packet #2: [RTP Header][3]
              Packet #3: [RTP Header][3][4][5]

                          Five Segments over RTP

                                 Figure 2

   For example, Figure 2 shows five segments being transported over
   three RTP packets.  If RTP packet #2 is lost due to network packet
   loss, not only segment 3 in RTP packet #2 is lost but also subsequent
   segments 3 and 4 carried in received RTP packet #3 are lost due to
   the fact the decoder cannot determine the beginning of either one of
   these segments.

   This document specifies a payload format for packetization of CCSDS
   compressed images that relies on identifying the boundaries between
   segments inside RTP packets.

2.  Conventions

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

3.  Header Format

3.1.  RTP Fixed Header Usage

   For each RTP packet, the RTP fixed header is followed by the CCSDS
   Image RTP payload header.  This header is, in turns, followed by the
   image payload consisting of a full or partial sequence of segments.
   The RTP header fields that have a meaning specific to a CCSDS image
   are described as follows:

      Marker bit (M): The marker bit of the RTP fixed header MUST be set
      to 1 for the last RTP packet of an image frame; otherwise, it MUST
      be 0.  When transmission is performed by multiple RTP sessions,
      this bit is 1 in the last packet of the frame in each session.

      Payload type (PT): The payload type is dynamically assigned by
      means outside the scope of this document.  A payload type in the
      dynamic range shall be chosen by means of an out-of-band signaling
      protocol (i.e., Real Time Streaming Protocol (RTSP), SIP, etc.).




Herrero & St.Pierre     Expires December 23, 2019               [Page 3]


Internet-Draft       CCSDS Image RTP Payload Format            June 2019


      Timestamp: Timestamp indicates the presentation time of the frame
      contained in the RTP packet.  The same timestamp value MUST appear
      in each RTP packet carrying a fragment of a given frame.
      Following the RTP specification RFC 3550 [RFC3550], the initial
      value of the timestamp should be randomly chosen.

      As for the clock rate, senders and receivers MUST support the
      90kHz RTP timestamp rate, and MAY support other rates.  RTP
      timestamp rates below 1000 Hz SHOULD NOT be used because they will
      result in insufficient resolution for RTP Control Protocol (RTCP)
      measurements based on the RTP timestamp, such as the interarrival
      jitter.  The clock rate MUST be negotiated at the start of the
      session.  When using the Session Description Protocol (SDP), it
      MUST be expressed using the "rtpmap" attributes.  If a non-90kHz
      clock rate is to be used, it is RECOMMENDED to present not only a
      preferable clock rate but also 90kHz clock rate with a different
      RTP payload type.

3.2.  RTP Payload Header Format

   The RTP payload header format for CCSDS compressed images indicates
   the offset to the beginning of the first new segment carried in the
   packet.  If the packet doesn't contain the beginning of a new
   segment, the offset is 0.  The offset is specified as byte and bit
   units.  If the byte offset is between 0 and 15 bytes the format of
   the header is as shown in Figure 3

                              0 1 2 3 4 5 6 7
                             +-+-+-+-+-+-+-+-+
                             |0|  btos | bos |
                             +-+-+-+-+-+-+-+-+

                                 Figure 3

   If the byte offset is larger than 16 bytes the format of the header
   is as shown in Figure 4.

                      0                   1
                      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |1|          btos         | bos |
                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                                 Figure 4

      btos (byte offset): 4 or 12 bits
      This field indicates the number of offset byte units to the first
      segment (if any).



Herrero & St.Pierre     Expires December 23, 2019               [Page 4]


Internet-Draft       CCSDS Image RTP Payload Format            June 2019


      bos (bit offset): 3 bits
      This field indicates the number of offset bit units to the first
      segment (if any).

4.  RTP Packetization

   The sender must packetize the CCSDS compressed images appropriately
   according to initial media type parameters.  A sender divides the
   codestream into segments by parsing the codestream or by getting
   information from the encoder, and packs the segments into RTP
   packets.  A sender can put an arbitrary number of segments into an
   RTP packet, but it MUST preserve the codestream order.  An example of
   this kind of RTP packet format is shown in Figure 5

             +------+-------+---------------+---------------+
             |RTP   |payload|     image     |     image     |
             |header|header |    segment    |    segment    |
             +------+-------+---------------+---------------+

                     An example with multiple segments

                                 Figure 5

   If a segment is larger than the MTU size, it MAY be fragmented as
   shown in Figure 6

    +------+-------+-------------------------------------------------+
    |RTP   |payload|                  image segment                  |
    |header|header |                     fragment                    |
    +------+-------+-------------------------------------------------+
    +------+-------+-------------------------------------------------+
    |RTP   |payload|                  image segment                  |
    |header|header |                     fragment                    |
    +------+-------+-------------------------------------------------+
    .
    .
    .
    +------+-------+------------------------------------+
    |RTP   |payload|            image segment           |
    |header|header |            end fragment            |
    +------+-------+------------------------------------+

                     An example with multiple segments

                                 Figure 6






Herrero & St.Pierre     Expires December 23, 2019               [Page 5]


Internet-Draft       CCSDS Image RTP Payload Format            June 2019


5.  SDP Parameters

   The MIME media type image/ccsds string is mapped to fields in the
   Session Description Protocol (SDP) as follows:

   The media name in the "m=" line of SDP MUST be image.

   The encoding name in the "a=rtpmap" line of SDP MUST be ccsds (the
   MIME subtype).

6.  Security Considerations

   RTP packets using the payload format defined in this specification
   are subject to the security considerations discussed in the RTP
   specification RFC 3550 [RFC3550].

7.  Normative References

   [CCSDS122.0]
              Consultative Committee for Space Data Systems, "CCSDS
              122.0-B-2: Image Data Compression", September 2017.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

Authors' Addresses

   Rolando Herrero
   Northeastern University
   Boston, MA
   US

   Email: r.herrero@northeastern.edu


   Claude St.Pierre
   L7TR
   Manchester, NH
   US

   Email: claude@l7tr.com



Herrero & St.Pierre     Expires December 23, 2019               [Page 6]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/