idnits 2.17.1 draft-herrero-avt-ccsds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 21, 2019) is 1742 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 99 -- Looks like a reference, but probably isn't: '2' on line 99 -- Looks like a reference, but probably isn't: '3' on line 101 -- Looks like a reference, but probably isn't: '4' on line 101 -- Looks like a reference, but probably isn't: '5' on line 101 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force R. Herrero 3 Internet-Draft Northeastern University 4 Intended status: Informational C. St.Pierre 5 Expires: December 23, 2019 L7TR 6 June 21, 2019 8 RTP Payload Format for CCSDS Compressed Image Data 9 draft-herrero-avt-ccsds-00 11 Abstract 13 This memo describes an RTP payload format for the Consultative 14 Committee for Space Data Systems (CCSDS) Compressed Image Data 15 standard [CCSDS122.0]. The compression is typically applied to two- 16 dimensional and three-dimensional data cubes resulting from 17 multispectral and hyperspectral imagining instruments. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on December 23, 2019. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Header Format . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3.1. RTP Fixed Header Usage . . . . . . . . . . . . . . . . . 3 57 3.2. RTP Payload Header Format . . . . . . . . . . . . . . . . 4 58 4. RTP Packetization . . . . . . . . . . . . . . . . . . . . . . 5 59 5. SDP Parameters . . . . . . . . . . . . . . . . . . . . . . . 6 60 6. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 7. Normative References . . . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6 64 1. Introduction 66 The CCSDS compressed image data standard can be used to produce both 67 lossy and lossless compression in a scenario that targets high-rate 68 instruments used on board of spacecraft. Moreover it provides a 69 trade-off between compression performance and complexity with 70 particular emphasis on spacecraft applications. As a low complexity 71 mechanism it supports fast and low power hardware implementations. 73 The compressor consists of two functional parts, shown in Figure 1, a 74 Discrete Wavelet Transform module that performs decorrelation and a 75 Bit-Plane Encoder which encodes the decorrelated data. It is outside 76 the scope of this document to further describe in detail this 77 procedure. Please refer to [CCSDS122.0] for more information. 79 +----------+ +----------+ 80 | Discrete | | Bit | 81 Raw Image ==> | Wave |--->| Plane | ==> Compressed Image 82 | Transform| | Encoder | 83 +----------+ +----------+ 85 Block diagram of the CCSDS encoder[CCSDS122.0]. 87 Figure 1 89 The coded data that results from each CCSDS compressed image is 90 composed of a sequence of self-contained and self-defined segments. 91 Depending on the size of the segments several RTP packetization 92 scenarios are possible; (1) Each RTP packet transports a single 93 segment, (2) Each RTP packet transports several fragments or (3) Each 94 fragment is transported across several RTP packets. In particular, 95 for cases (2) and (3), if segments are packetized directly over RTP 96 there is potential for corruption that extends beyond segments 97 affected by packet loss. 99 Packet #1: [RTP Header][1][2][3] 100 Packet #2: [RTP Header][3] 101 Packet #3: [RTP Header][3][4][5] 103 Five Segments over RTP 105 Figure 2 107 For example, Figure 2 shows five segments being transported over 108 three RTP packets. If RTP packet #2 is lost due to network packet 109 loss, not only segment 3 in RTP packet #2 is lost but also subsequent 110 segments 3 and 4 carried in received RTP packet #3 are lost due to 111 the fact the decoder cannot determine the beginning of either one of 112 these segments. 114 This document specifies a payload format for packetization of CCSDS 115 compressed images that relies on identifying the boundaries between 116 segments inside RTP packets. 118 2. Conventions 120 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 121 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 122 document are to be interpreted as described in RFC 2119 [RFC2119]. 124 3. Header Format 126 3.1. RTP Fixed Header Usage 128 For each RTP packet, the RTP fixed header is followed by the CCSDS 129 Image RTP payload header. This header is, in turns, followed by the 130 image payload consisting of a full or partial sequence of segments. 131 The RTP header fields that have a meaning specific to a CCSDS image 132 are described as follows: 134 Marker bit (M): The marker bit of the RTP fixed header MUST be set 135 to 1 for the last RTP packet of an image frame; otherwise, it MUST 136 be 0. When transmission is performed by multiple RTP sessions, 137 this bit is 1 in the last packet of the frame in each session. 139 Payload type (PT): The payload type is dynamically assigned by 140 means outside the scope of this document. A payload type in the 141 dynamic range shall be chosen by means of an out-of-band signaling 142 protocol (i.e., Real Time Streaming Protocol (RTSP), SIP, etc.). 144 Timestamp: Timestamp indicates the presentation time of the frame 145 contained in the RTP packet. The same timestamp value MUST appear 146 in each RTP packet carrying a fragment of a given frame. 147 Following the RTP specification RFC 3550 [RFC3550], the initial 148 value of the timestamp should be randomly chosen. 150 As for the clock rate, senders and receivers MUST support the 151 90kHz RTP timestamp rate, and MAY support other rates. RTP 152 timestamp rates below 1000 Hz SHOULD NOT be used because they will 153 result in insufficient resolution for RTP Control Protocol (RTCP) 154 measurements based on the RTP timestamp, such as the interarrival 155 jitter. The clock rate MUST be negotiated at the start of the 156 session. When using the Session Description Protocol (SDP), it 157 MUST be expressed using the "rtpmap" attributes. If a non-90kHz 158 clock rate is to be used, it is RECOMMENDED to present not only a 159 preferable clock rate but also 90kHz clock rate with a different 160 RTP payload type. 162 3.2. RTP Payload Header Format 164 The RTP payload header format for CCSDS compressed images indicates 165 the offset to the beginning of the first new segment carried in the 166 packet. If the packet doesn't contain the beginning of a new 167 segment, the offset is 0. The offset is specified as byte and bit 168 units. If the byte offset is between 0 and 15 bytes the format of 169 the header is as shown in Figure 3 171 0 1 2 3 4 5 6 7 172 +-+-+-+-+-+-+-+-+ 173 |0| btos | bos | 174 +-+-+-+-+-+-+-+-+ 176 Figure 3 178 If the byte offset is larger than 16 bytes the format of the header 179 is as shown in Figure 4. 181 0 1 182 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 |1| btos | bos | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 Figure 4 189 btos (byte offset): 4 or 12 bits 190 This field indicates the number of offset byte units to the first 191 segment (if any). 193 bos (bit offset): 3 bits 194 This field indicates the number of offset bit units to the first 195 segment (if any). 197 4. RTP Packetization 199 The sender must packetize the CCSDS compressed images appropriately 200 according to initial media type parameters. A sender divides the 201 codestream into segments by parsing the codestream or by getting 202 information from the encoder, and packs the segments into RTP 203 packets. A sender can put an arbitrary number of segments into an 204 RTP packet, but it MUST preserve the codestream order. An example of 205 this kind of RTP packet format is shown in Figure 5 207 +------+-------+---------------+---------------+ 208 |RTP |payload| image | image | 209 |header|header | segment | segment | 210 +------+-------+---------------+---------------+ 212 An example with multiple segments 214 Figure 5 216 If a segment is larger than the MTU size, it MAY be fragmented as 217 shown in Figure 6 219 +------+-------+-------------------------------------------------+ 220 |RTP |payload| image segment | 221 |header|header | fragment | 222 +------+-------+-------------------------------------------------+ 223 +------+-------+-------------------------------------------------+ 224 |RTP |payload| image segment | 225 |header|header | fragment | 226 +------+-------+-------------------------------------------------+ 227 . 228 . 229 . 230 +------+-------+------------------------------------+ 231 |RTP |payload| image segment | 232 |header|header | end fragment | 233 +------+-------+------------------------------------+ 235 An example with multiple segments 237 Figure 6 239 5. SDP Parameters 241 The MIME media type image/ccsds string is mapped to fields in the 242 Session Description Protocol (SDP) as follows: 244 The media name in the "m=" line of SDP MUST be image. 246 The encoding name in the "a=rtpmap" line of SDP MUST be ccsds (the 247 MIME subtype). 249 6. Security Considerations 251 RTP packets using the payload format defined in this specification 252 are subject to the security considerations discussed in the RTP 253 specification RFC 3550 [RFC3550]. 255 7. Normative References 257 [CCSDS122.0] 258 Consultative Committee for Space Data Systems, "CCSDS 259 122.0-B-2: Image Data Compression", September 2017. 261 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 262 Requirement Levels", BCP 14, RFC 2119, 263 DOI 10.17487/RFC2119, March 1997, 264 . 266 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 267 Jacobson, "RTP: A Transport Protocol for Real-Time 268 Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550, 269 July 2003, . 271 Authors' Addresses 273 Rolando Herrero 274 Northeastern University 275 Boston, MA 276 US 278 Email: r.herrero@northeastern.edu 280 Claude St.Pierre 281 L7TR 282 Manchester, NH 283 US 285 Email: claude@l7tr.com