Internet Engineering Task Force A/V Transport Working Group Internet Draft B. Fairman Document: draft-fairman-rtp-61883-00.txt SONY-PTCA-NSA Expires: November 2003 June 2003 RTP Payload Format for 1394/61883 Isochronous Streams Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or made obsolete 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. For potential updates to the above required-text see: http://www.ietf.org/ietf/1id-guidelines.txt Abstract This document describes a payload format for transporting IEC 61883-1[2] (CIP) compliant IEEE1394 isochronous transport data using RTP. A 1394[3] CIP isochronous transport may carry a stream format, such as DV[4], AM824[5] or MPEG[6], that has been packetized for isochronous transport by the source. The format is opaque to the transport mechanism. The isochronous transport clock is derived from the 1394 cycle timer clock. This protocol may be used to transport 1394 61883 streams between 1394 buses by IP, specifically Ethernet/IP. Conventions used in this document 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[7]. Table of Contents 1. Introduction 3 1.1 Overview of 61883-1 Isochronous Transport 3 1.2 The 1394 Cycle Master, Cycle Timer and Bandwidth 4 1.3 Brief Description of 1394 Isochronous Traffic 5 1.4 Cycle time use by 61883-1 5 1.5 Missing Cycles, under-runs and over-runs 6 1.6 Maintaining Cycle timing across non-isochronous networks 6 1.7 All Participating endpoints are Isochronous 6 2. Structure of the RTP Packet 7 3. 61883-1 Isochronous Streams Packaging for RT 8 3.1 1394 Isochronous Packet 8 Fairman Expires - December 2003 page [1] RTP Payload for 1394/61883 Isochronous Streams June 2003 4. Security Considerations 10 Acknowledgments 10 Author's Addresses 10 References 10 Fairman Expires - December 2003 page [2] RTP Payload for 1394/61883 Isochronous Streams June 2003 1. Introduction The ability to transport 61883-1 (CIP) isochronous streams, originated on IEE1394 networks (buses), over IP networks is important for multi- media applications centered around the consumer digital Audio/Video space. There are some unique characteristics of 61883-1 that must be addressed in order to use RTP as the transport protocol. The issue of resource management (bandwidth, delay) to ensure temporal reliability is not addressed. This draft specifies an RTP[8] payload format for transporting 1394 transported 61883-1 isochronous data streams. Familiarity with 1394 and 61883-1 details is assumed. The benefits of using RTP for 61883-1 isochronous stream transport include: i. Ability to deliver 61883-1 isochronous streams on distinct IEEE1394 buses. ii. Typically, a number of 1394 isochronous interval's data can be transmitted in one RTP packet (based on the MTU), improving the efficiency of using an IP network. iii. IP based applications can access 1394 isochronous streams by implementing CIP processing of the RTP stream. 1.1 Overview of 61883-1 Isochronous Transport The transport of IEC 61883-1 compliant isochronous data is based on an isochronous clock at the source that is used to packetize application streams (i.e., source packets) that are, in turn, based on their applications' source clocks. The 61883-1 isochronous packets are called data blocks. The sender application clocks are not inherently synchronized to the isochronous clock. The receivers' isochronous clock is synchronized with sender's isochronous clock (that is, on the same bus with the same cycle master).The per isochronous cycle bit rate of the isochronous packet transport is generally not constant. For the 1394 bus, bandwidth is allocated based on the maximum data rate and the sender transmits truncated or null packets such that the average data rate requirement of the application is met. Packets never exceed the allocated bus bandwidth. The isochronous nature of 61883-1 makes RTCP [8] unnecessary since the data rate of the isochronous source may not be directly adjusted. Application level protocols may accomplish this end, if needed. Further, there is a 61883-1 defined connection control method called Connection Management Procedures/Plug Control Registers (CMP/PCR). This method allows an observer to determine the state of a particular connection. 1.2 The 1394 Cycle Master, Cycle Timer and Bandwidth The 1394 cycle master is the provider of the bus-wide clock on which isochronism is based. The cycle master function is always operating on an isochronous capable 1394 bus. The cycle master is selected by the self-id process and is always the root (which controls arbitration). The cycle timer value is written to all nodes by a broadcast write (cycle start transaction) of the contents of the cycle master's cycle timer Fairman Expires - December 2003 page [3] RTP Payload for 1394/61883 Isochronous Streams June 2003 register when isochronous arbitration is successful. Isochronous arbitration is initiated upon the cycle count incrementing in the cycle master's cycle count. The bus cycle clock's period is nominally 125us (8Khz). It is derived from the 24.576Mhz PHY clock (40.690 nsec granularity) which increments the cycle timer. The tolerance of the clock used to derive the master cycle clock is +/-100PPM. However, due to the 1394 arbitration and bus occupancy mechanism, there is a maximum delay of 78 usec[9]for the occurrence of a cycle start transaction. The maximum delay for the recurrence of a particular stream (channel ID) is 185.5 usec - (channel's bandwidth in use). The cycle clock is used to packetize the application generated source packets, such that the bandwidth allocated for the application is never exceeded. The well- defined maximum delay allows applications to have well defined and limited buffering for 61883 streams. Bandwidth is allocated as time on the bus, rather than data rate per unit time. The IRM is responsible for managing the bandwidth available register, from which bandwidth units are subtracted by nodes requiring bandwidth. Bandwidth units are a time of 20 nsec (approximately). Each cycle consists of 6144 bandwidth units, of which 4915 may be used for isochronous traffic. 1 usec is about 49 bandwidth allocation units. The 1394 specification states that the cycle timer 'never moves backwards'. This does not account for bus resets that select a new cycle master (e.g. joining 2 buses). In this case, there will likely be a discontinuity in the cycle timer value. This discontinuity is not relevant to the actual timing, as long as arbitrated bus resets are used. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cycle sec | cycle count | cycle offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1 - 1394 Cycle Timer cycle offset: counter incremented by PHY clock ticks with rollover at a count of 3071 (125 usec with 40.69 nsec tick). cycle count: counter incremented by cycle offset rollover with a rollover at a count of 7999 (1 sec/8 KHz). cycle sec: counter incremented by cycle count rollover with a rollover at a count of 127 (128 sec). As mentioned above, 1394 arbitration can introduce jitter to the start time of an isochronous period (the time following the first isochronous arbitration grant). This is accommodated by the cycle master transmitting its cycle timer (which includes cycle offset) at the actual transmission of the cycle start transaction. 1.3 Brief Description of 1394 Isochronous Traffic An isochronous stream on 1394 is identified by the channel number contained in its isochronous header. This is a unique identifier managed by the Isochronous Resource Manager (IRM) function. It is possible for a given program to occupy multiple channels. The channel number has meaning only on the particular 1394 bus on which it is used. These factors lead to a need to allow for multiple channels to be mapped into a single RTP session. Briefly, for each isochronous cycle (nominally, Fairman Expires - December 2003 page [4] RTP Payload for 1394/61883 Isochronous Streams June 2003 125 usec), there are zero or one occurrences of data for a given channel. The order in which channels occur in an isochronous cycle is not guaranteed. Also, packets may be shorter than the maximum allowed by the bandwidth allocated to the channel. It is possible for a node to miss a cycle start to be "missed" if there is a transmission problem with the cycle start packet. However, there may be nodes on the bus that that successfully receive the cycle start. This can cause a situation wherein isochronous traffic is observed without a node being in an isochronous mode. 1.4 Cycle time use by 61883-1 The IEC 61883-1 specification for the two-quadlet CIP header defines two uses of a value derived from the cycle timer: the SYT field and the source packet header (SPH). The values in these fields are a function of the cycle timer on the bus where the packets exist. These fields usually relate to timing of the delivery of the ensuing data block to the consuming application. These fields are absolute values tied to the value of the cycle timer. The function which generates the value is tied to the kind of data block being transported and typically is the presentation time to the receiver application. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| SID | DBS |FN | QPC |S|RSV| DBC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|0| FMT | FDF | SYT | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2 - Two-quadlet CIP header with SYT 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0| SID | DBS |FN | QPC |S|RSV| DBC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|0|1| FMT | FDF | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - Two-quadlet CIP header without SYT The SYT field contains a value derived from the lower 16 bits of the cycle timer. The SYT value derivation is from 4 bits of cycle count and 12 bits of cycle offset. The SYT field spans 16 cycles (approx. 2ms). It is typically some absolute time in the future, cycle timer based. If the S bit == 1 then the quadlet following the CIP header contains the Source Packet Header (SPH) timestamp. The SPH consists of the lower 25 bits of the cycle counter and spans 8000 cycles (one second). It is typically some absolute time in the future, cycle timer based. Fairman Expires - December 2003 page [5] RTP Payload for 1394/61883 Isochronous Streams June 2003 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved | SPH Time Stamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Data Block | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - Source packet header 1.5 Missing Cycles, under-runs and over-runs The IEEE1394 bus has a very low error rate. That said, it is still possible to have an error. For isochronous traffic, there is no retransmission, so there should be a strategy implemented to allow for recovery from missing cycle start packets or missing or corrupted data packets. 1.6 Maintaining Cycle timing across non-isochronous networks Cycle time is local to a IEEE1394 bus. It cannot be used by another IEEE1394 bus directly. By communicating the absolute value of the local cycle timer, the relative passage of time at the sender can be observed at the receivers. It would also be possible to detect cycle timer discontinuities at the transmitter. Any imbedded reference to absolute cycle time is adjusted to relative offset by the transmitter (SPH, SYT) to avoid dependence on the sender's cycle timer. The problem of synchronizing distinct IEE1394 buses is not addressed here. 1.7 All Participating endpoints are Isochronous In RFC1257, the argument is made that bounded delay and guaranteed bandwidth are the only requirements of the network transporting time based data (streams), when the applications are isochronous. The need to consider jitter is demonstrated to be unnecessary. When 61883-1 isochronous streams are transported by RTP, all participants are, by definition, isochronous. Thus the protocols used to manage network resources such that there is timely delivery (bounded maximum delay) of transported isochronous streams is simplified because jitter is not a problem. The receivers will have to accommodate the maximum delay in the sense that buffering is needed to accommodate the maximum delay. There is also a minimum delay associated with the flow. Thus, it can be conceptualized that the receivers will see an average jitter of .5(max delay - min delay) in the clock implied by the rate of delivery of packets on the non-isochronous transport. Fairman Expires - December 2003 page [6] RTP Payload for 1394/61883 Isochronous Streams June 2003 2. Structure of the RTP Packet 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC=1 |M| PT | sequence number | RTP +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | Hdr +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | contributing source (CSRC) identifier | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | RTP | 61883-1 isochronous streams(quadlet aligned) | Pay- / / load . . . / / | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - An RTP packet for 61883-1 isochronous stream Padding (P): 0 Extension (X) bit: the extension bit is set to zero. CSRC count (CC): the CSRC count is set to 1. Marker (M) bit: the marker bit is set to zero. Synchronization source (SSRC): the high order 32 bits of the sources EUI64. Contributing source (CSRC: the low order 32 bits of the sources EUI64. Payload Type (PT): the assignment of the RTP payload type for this packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile for a particular class of applications will assign a payload type for this encoding, or if that is not done then a payload type in the dynamic range SHALL be chosen by means of an out of band signaling protocol (e.g., UPnP, etc). Sequence Number: incremented by the number of isochronous cycles in the RTP data packet, starting, for security reasons, with a random initial value. Timestamp: The timestamp is the value of the isochronous cycle start transaction corresponding to the receipt of the first isochronous packet contained in the RTP packet. 61883-1 isochronous streams: the content of the isochronous channels for this session. The format of this data is covered in the next section. 3. 61883-1 Isochronous Streams Packaging for RTP 3.1 1394 Isochronous Packet Below is a representation of a 1394 isochronous packet detailing the header fields. An isochronous period may contain multiple packets, each occurring at most once for a channel. Fairman Expires - December 2003 page [7] RTP Payload for 1394/61883 Isochronous Streams June 2003 Thus a unit of information recorded for an isochronous cycle consists of information about the cycle (cycle start) and information for each of the desired channels. Typically, the CRCs are stripped by the 1394 interface. 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 | data length (bytes) |tag| channel |1 0 1 0| sy | hdr +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | header CRC | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | | | isochronous payload | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | : zero padding as needed | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | data CRC | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 6 - 1394 Isochronous packet Isochronous packets for 61883-1 use the tag field to indicate the presence of CIP header quadlets. 00b means no CIP header while 01b means CIP header quadlets are present. Combining this information with cycle start information yields a record for an isochronous cycle. Some of the fields are processed by the sender to introduce a degree of independence from local conditions. Figure 7 represents the record for a particular cycle, containing at least the cycle mark and ACC. The example shows that there may be more than one 61883-x stream captured per cycle. Fairman Expires - December 2003 page [8] RTP Payload for 1394/61883 Isochronous Streams June 2003 0 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ cycle |1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 1 0 0 1 0 1 1 0 1 1 1 1 1 1| mark +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjusted Cycle Counter (ACC) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 1394 | data length (bytes) |tag| xchannel0 |1 0 1 0| sy | hdr +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 61883-1 payload | / / . . . / / | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | data length (bytes) |tag| xchannel1 |1 0 1 0| sy | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | 61883-1 payload | / / . . . / / | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | subsequent isochronous cycle packets | / / . . . / / | | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ Figure 7 - RTP Isochronous cycle record Cycle mark: a constant value for synchronization purposes. Adjusted cycle counter: this is the cycle counter that represents the cycle containing the subsequent isochronous packets. It is derived from the cycle start packet (unless it has to be derived from the local cycle counter). The ACC cycle count (and the cycle seconds) is 0 for the first cycle transmitted and is increased by one cycle per isochronous cycle. The cycle offset is recorded as received in the cycle start packet. If a missing cycle start causes synthesis of a cycle mark, the offset is captured from the local cycle counter. xchanneln: the number mapped to the received 1394 isochronous channel. It identifies the 1394 channel assigned to the isochronous payload for transmission purposes. The protocol for determining the mapping is beyond the scope of this document. tag: from the isochronous packet (00b or 01b). sy: from the isochronous packet. isochronous payload: from the packet. Since the payload is by definition 61883-1 compliant, if the CIP headers are present, then the SYT (if present) and SPH (if present) are adjusted to relative values, based on the current cycle timer. This is accomplished by subtracting the current cycle start cycle count/cycle seconds value from the fields such that the cycle difference is the result, preserving the cycle offset of the input SYT or SPH. Fairman Expires - December 2003 page [9] RTP Payload for 1394/61883 Isochronous Streams June 2003 4. Security Considerations RTP packets using the payload format defined in this specification are subject to the security considerations discussed in the RTP specification, and any appropriate RTP profile. This implies that confidentiality of the media streams is achieved by encryption. Because the data compression used with this payload format is applied to end-to- end, encryption may be performed after compression so there is no conflict between the two operations. A potential denial-of-service threat exists for data encodings using compression techniques that have non-uniform receiver-end computational load. The attacker can inject pathological datagrams into the stream which are complex to decode and cause the receiver to be overloaded. However, this encoding does not exhibit any significant non-uniformity. As with any IP-based protocol, in some circumstances a receiver may be overloaded simply by the receipt of too many packets, either desired or undesired. Network-layer authentication may be used to discard packets from undesired sources, but the processing cost of the authentication itself may be too high. In a multicast environment, pruning of specific sources may be implemented in future versions of IGMP and in multicast routing protocols to allow a receiver to select which sources are allowed to reach it. Acknowledgments The author thanks Scott Smyers, Richard Bardini, Thomas Swidler and Glen stone of Sony for their inputs to this document. Author's Addresses Bruce Fairman Sony Electronics, Inc. PTCA-NSA 3300 Zanker Road San Jose, CA 95134 Phone: 408-955-5739 Email: bruce.fairman@am.sony.com Fairman Expires - December 2003 page [10] RTP Payload for 1394/61883 Isochronous Streams June 2003 References 1 Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996. 2 IEC 61883-1:1998 "Consumer audio/video equipment - Digital interface -Part 1:General" 3 IEEE1394-2000 "IEEE Standard for a High Performance Serial Bus" 4 IEC 61883-2,-3,-5:1998 "Consumer audio/video equipment - Digital interface -Part 2, Part 3, Part 5" 5 IEC IEC 61883-6:1998 "Consumer audio/video equipment - Digital interface - Part 6: Audio and music data transmission protocol" 6 IEC 61883-4:1998 "Consumer audio/video equipment - Digital interface - Part 4: MPEG2-TS data transmission" 7 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 8 Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson "RTP: A Transport Protocol for Real Time Applications", RFC 1889, January 1996. 9 Smyers, S. "Scott's ppt presentation re: jitter" Fairman Expires - December 2003 page [11]