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

Versions: 00 draft-ietf-avt-tcrtp

Audio/Video Transport Working Group                          Tmima Koren
Internet Draft                                             Patrick Ruddy
June 25, 1999                                             Bruce Thompson
Expires December 1999                                       Alex Tweedly
draft-wing-avt-tcrtp-00.txt                                     Dan Wing
                                                           Cisco Systems


             Tunneled multiplexed Compressed RTP ("TCRTP")


Status of this memo

   This document is an Internet Draft and is in full conformance with
   all provisions of Section 10 of RFC 2026. 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. Internet Drafts may be updated, replaced, or obsoleted by
   other documents at any time. It is not appropriate 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.txt

   This draft is being submitted as a possible work item to the IETF
   Audio/Video Transport working group.  To subscribe to the mailing
   list send a message to rem-conf-request@es.net with the line
   "subscribe" in the body of the message.  Archives are available from
   ftp://ftp.es.net/pub/mail-archive/rem-conf

Copyright Notice

   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document describes a mechanism which improves the end-to-end
   bandwidth utilization of RTP streams over an IP network by
   compressing the UDP and RTP headers and allowing the packets of
   multiple RTP streams to be multiplexed into one IP packet.




Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 1]

Internet Draft               Tunneled CRTP                     June 1999


   This new protocol is useful in low-bandwidth environments, such as
   dialup modems, ISDN, cellular, and G.Lite which wish to reduce the
   encapsulation overhead of normal RTP packets through the entire
   network.  The protocol provides mechanisms to ensure synchronization
   at certain points to reduce the requirement for the receiver to
   communicate synchronization loss to the sender.

1.  Introduction

   This document describes a new protocol which compresses RTP [RTP]
   streams.  The new protocol is based on RFC2508 [CRTP] and RFC2507
   [IPHCOMP].

   Readers should be familiar with RFC2508 [CRTP] and RFC2507 [IPHCOMP].

1.1. Background

   Existing methods for compression of RTP [RTP] streams, such as
   [CRTP], are per-hop instead of end-to-end which places a processing
   burden on ingress routers and, if the bandwidth savings are desired
   in the network core, an additional processing burden on core routers.

   [CRTP] includes features such as negative acknowledgements when the
   decompressor becomes unsynchronized with the compressor.  [CRTP] was
   designed to operate hop-by-hop, but Negative acknowledgements are
   unsuitable as the primary mechanism to re-synchronize the
   decompressor in an end-to-end protocol because the round-trip time is
   longer than the useful life of the data being sent with RTP.

1.2. Overview

   [CRTP] relies on a number of link-level protocol (such as PPP)
   features including: packet length indication, packet type indication,
   good error detection, lack of reordering.

   The protocol described by this document is an application-level
   protocol, not a strict link-layer protocol.  The end-to-end tunnel is
   built using IP, with a new protocol number.  Multiple packets with
   compressed IP/UDP/RTP headers are carried by this, each preceded by a
   type and length indication.

   This scheme transports multiple independent UDP/RTP streams between a
   pair of IP endpoints, i.e. the streams retain independent UDP source
   and destination ports, and RTP timestamps and sequence numbers.

   TCRTP capability notification can be out-of-band, using the same
   mechanism to establish an RTP stream -- H.245 [H.245], SIP [SIP],
   SGCP [SGCP], or similar protocols.



Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 2]

Internet Draft               Tunneled CRTP                     June 1999


   This document assumes the reader is familiar with the protocol
   described in RFC2508 [CRTP].  Major differences from [CRTP] are:

      * Delivery between compressor and decompressor is provided by an
        IP tunnel, using a new protocol number, rather than a link-level
        protocol;
      * Multiple packets with compressed IP/UDP/RTP headers can be
        carried in a single IP packet;
      * Explicit type and length fields are provided for each subpacket;
      * The same compressed header types as RFC2508 are supported, with
        the addition of a new CRTPX type;

1.3. Advantages and Disadvantages of TCRTP

   Advantages

      a. TCRTP saves bandwidth over RTP, even when TCRTP is not
         multiplexing;
      b. When multiplexing, TCRTP does not require the RTP sequence
         number, SSRC, or any other RTP field to be related to the RTP
         fields in the other RTP streams in the same multiplexed packet;
      c. Unmultiplexed TCRTP incurs 4-7 bytes of header overhead, versus
         20 for normal UDP+RTP;
      d. A multiplexed TCRTP stream saves 40 bytes of header overhead
         (IP+UDP+RTP) per multiplexed packet;
      e. Compared to CRTP, TCRTP works end-to-end instead of only one
         router hop;
      f. TCRTP retains the IP source and destination, and UDP source and
         destination information in each sub-payload, which allows for:
           * easier dispatch to other processors in a distributed
             processor environment,
           * distributed compression and decompression in a distributed
             system environment,
           * better functionality with NAT [NAT],
           * multiplexing data to different destinations;
      h. TCRTP leverages CRTP;
      i. TCRTP can multiplex UDP as well as RTP streams.

   Disadvantages
      a. Each TCRTP packet isn't self-contained and loss of
         'significant' packets or several successive packets can cause
         the TCRTP decompressor to temporarily lose synchronization.

1.4. Requirements Notation

   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 RFC2119 [KEYW].



Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 3]

Internet Draft               Tunneled CRTP                     June 1999


2. Encapsulation Format

   The TCRTP packet uses a new IP protocol.  This protocol will be named
   TCRTP and is not yet registered with IANA.

   A TCRTP packet consists of:
     1. an IP header, with the new TCRTP protocol type.
     2. a set of packets with compressed IP/UDP/RTP headers, those
        headers replaced with a TCRTP header of variable length as
        described below.

   Every TCRTP header starts with type and length fields.  A detailed
   description follows:

        Element         Bytes         Description
      --------------------------------------------------------------
      Type/CID/length     1    3 bits Type (see below)
                               1 bit CID-length indicator
                               1 reserved bit
                               3 bits high-order payload length
      Length              1    8 bits low-order payload length
      RTP Timestamp       4    RTP Timestamp (only present if Type = CRTPX)
      RTP Sequence        2    RTP Sequence (only present if Type = CRTPX)
      RTP Type            1    RTP Type (only present if type = CRTPX)
      RTP DeltaT          1    RTP Delta time (only present if type = CRTPX)
      Context ID        1/2    Unique per-source context value
      MSTI/Sequence       1    Changed-field bitmask plus 4 bit sequence
                               number (see RFC2508)
      Checksum          0/2    Optional Checksum
      delta fields      0-3    encoded delta values, which are present
                               if the associated bit is "1" in MSTI, above
      RTP Payload      varies

   Multiple TCRTP packets can be concatenated together in one IP packet.
   The IP 'length' field can be compared to the TCRTP length field to
   determine if multiple TCRTP packets are contained in one IP packet.

2.1. Description of Elements

2.1.1. Type/CID/Length Field

   Type/CID/Length - this 8-bit field is divided as follows:

      bit 0,1,2  = TCRTP Type (see below for values)
      bit 3      = length of Context-ID.  0=one byte, 1=two bytes
      bit 4      = reserved.  must be 0.
      bit 5,6,7  = high-order length bits




Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 4]

Internet Draft               Tunneled CRTP                     June 1999


   There are six values for the 3-bit Type field, all of which are from
   RFC2508 [CRTP], except CRTPX which is a new Type field defined in
   this document.

      0b000  reserved
      0b001  FH        Full Header
      0b010  CUDP      Compressed UDP
      0b011  CNTCP     Compressed Non-TCP
      0b100  CRTP      Compressed RTP
      0b101  CRTPX     Compressed RTP with Extra Fields
      0b110  CS        Context State
      0b111  reserved

2.1.2. Length Field

   The length indicates the length of the payload (not including the
   Type and Length bytes themselves).

   The length of the payload is expressed in 11 bits.  The lower 8 of
   these bits are in the Length field, and the upper 3 bits are in the
   Type/CID/Length field.

   The 11 bit length field limits RTP payload length to 2048 bytes, but
   this should cover nearly all cases, and in any case, header
   compression is of little worth on long packets.

2.1.3. RTP Timestamp Field

   This field is taken from the RTP header and placed in the TCRTP
   payload.

2.1.4. RTP Sequence Field

   This field is taken from the RTP header and placed in the TCRTP
   payload.

2.1.5. RTP Type Field

   This field is taken from the RTP header and placed in the TCRTP
   payload.

2.1.6. RTP DeltaT Field

   This field is the first-order time increment and is used by the
   decompressor to re-compute the RTP timestamp.

   This field is inherited from RFC2508 [CRTP].




Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 5]

Internet Draft               Tunneled CRTP                     June 1999


2.1.7. Context ID Field

   This field defines the unique per-destination stream.  This value is
   chosen by the sender and MUST be unique per each IP destination.

   If the associated bit in the Type field is 0, the Context-ID is one
   byte long; if 1, the Context-ID is two bytes long.

   This field is inherited from RFC2508 [CRTP].

2.1.8. MSTI/Sequence Field

   The MSTI bits indicate if the 'delta fields' are present.

   The Sequence bitfield is incremented sequentially for each TCRTP
   packet transmitted and is used by the decompressor to determine if a
   packet was lost or delivered out-of-sequence.  It is used in
   conjunction with the 'twice algorithm', described below.

   Both the MSTI and Sequence are inherited from RFC2508 [CRTP].

2.1.9. Checksum Field

   This is the UDP checksum of what would have been the originally-sent
   UDP packet, had there been no TCRTP compression or multiplexing.

   The checksum field is necessary to verify the payload was not
   corrupted and is especially useful with the 'twice algorithm',
   described below, to verify the 'twice algorithm' has re-synchronized
   the decompressor.

   The presence of this field is REQUIRED if the UDP checksum was
   present in the Full Header (FH) synchronization packet for this
   Context-ID.  Note that the compressor can freely choose to provide
   checksums on some streams and no checksums on other streams, even in
   the same multiplexed packet -- however, the existence of a checksum
   must agree with the original synchronizing FH packet.

   This field is inherited from RFC2508 [CRTP].

2.1.10. Delta Fields

   These fields are only present if their associated bits are turned on
   in the MSTI field (described above).  See RFC2508 [CRTP] for a
   description of these fields.

   This field is inherited from RFC2508 [CRTP].




Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 6]

Internet Draft               Tunneled CRTP                     June 1999


2.1.11. RTP Payload Field

   This is the RTP payload itself.

2.2. Payload Formats

   The six payload types are diagrammed below.  In all cases the 'delta
   fields' are shown, but note that the 'delta fields' are actually only
   present if their associated MSTI bits are set.  See RFC2508 [CRTP]
   for details on the 'delta fields' and the MSTI bits.

2.2.1. Full-Header (FH) Payload Format

   This is contained in the payload of an IP packet:

        0   1   2   3   4   5   6   7
      +-------------------------------+
      | 0 | 0 | 1 | C | 0 |  Length   |  (Opcode FH = 001, C=1 long CID,
      |   |   |   |   |   |           |   E=1 non-multiplexed)
      +...............................+
      :           Length              :
      +-------------------------------+
      |                               |
      /         IP Header             /
      /  With altered Length field    /
      /                               /
      /                               /
      |                               |
      +-------------------------------+
      |                               |
      /        UDP Header             /
      /  With altered Length field    /
      |                               |
      +-------------------------------+
      |           UDP data            |
      :   (uncompressed RTP header)   :
      +-------------------------------+














Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 7]

Internet Draft               Tunneled CRTP                     June 1999


2.2.2. Compressed UDP (CUDP) Payload Format

   This is contained in the payload of an IP packet:

        0   1   2   3   4   5   6   7
      +-------------------------------+
      | 0 | 1 | 0 | C | 0 |  Length   |  (Opcode CUDP = 010, C=1 long CID,
      |   |   |   |   |   |           |   E=1 non-multiplexed)
      +...............................+
      :           Length              :
      +...............................+
      :   msb of session context ID   :  (if 16-bit CID   (Flag bit C=1))
      +-------------------------------+
      |   lsb of session context ID   |
      +---+---+---+---+---+---+---+---+
      | 0 | 0 | 0 | I | link sequence |
      +---+---+---+---+---+---+---+---+
      :                               :
      +         UDP checksum          +  (if nonzero in context)
      :                               :
      +...............................+
      :                               :
      +        "RANDOM" fields        +  (if encapsulated)
      :                               :
      +...............................+
      :         delta IPv4 ID         :  (if I = 1)
      +-------------------------------+
      |           UDP data            |
      +-------------------------------+

2.2.3. Compressed (CNTCP) Non-TCP Payload Format

   This is the Compressed UDP (CUDP) format for IPv6 and is identical to
   CUDP, described above.

















Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 8]

Internet Draft               Tunneled CRTP                     June 1999


2.2.4. Compressed RTP (CRTP) Payload Format

   This is the 'typical' payload for most data, with the exceptions for
   significant events as described in section 3.

   This is contained in the payload of an IP packet.

        0   1   2   3   4   5   6   7
      +-------------------------------+
      | 1 | 0 | 0 | C | 0 |  Length   |  (Opcode CRTP = 100, C=1 long CID,
      |   |   |   |   |   |           |   E=1 non-multiplexed)
      +...............................+
      :           Length              :
      +...............................+
      :   msb of session context ID   :  (if 16-bit CID   (Flag bit C=1))
      +-------------------------------+
      |   lsb of session context ID   |
      +---+---+---+---+---+---+---+---+
      | M | S | T | I | link sequence |
      +---+---+---+---+---+---+---+---+
      :                               :
      +         UDP checksum          +  (if nonzero in context)
      :                               :
      +...............................+
      :                               :
      +        "RANDOM" fields        +  (if encapsulated)
      :                               :
      +...............................+
      : M'| S'| T'| I'|      CC       :  (if MSTI = 1111)
      +...............................+
      :         delta IPv4 ID         :  (if I or I' = 1)
      +...............................+
      :      delta RTP sequence       :  (if S or S' = 1)
      +...............................+
      :      delta RTP timestamp      :  (if T or T' = 1)
      +...............................+
      :                               :
      :           CSRC list           :  (if MSTI = 1111
      :                               :   and CC nonzero)
      :                               :
      +...............................+
      :                               :
      :      RTP header extension     :  (if X set in context)
      :                               :
      :                               :
      +-------------------------------+
      |                               |
      |            RTP data           |



Koren, Ruddy, Thompson, Tweedly, Wing        Expires Dec 1999  [Page 9]

Internet Draft               Tunneled CRTP                     June 1999


      /                               /
      /                               /
      |                               |
      +-------------------------------+
      :            padding            :  (if P set in context)
      +...............................+













































Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 10]

Internet Draft               Tunneled CRTP                     June 1999


2.2.5. Compressed RTP with Extra Fields (CRTPX)

   The payload used to re-establish the full state of the receiver is
   typically as follows.  This would only be sent when a major event
   occurs.

        0   1   2   3   4   5   6   7
      +-------------------------------+
      | 1 | 0 | 1 | C | 0 |  Length   |  (Opcode CRTPX = 101, C=1 long CID,
      |   |   |   |   |   |           |   E=1 non-multiplexed)
      +...............................+
      :           Length              :
      +-------------------------------+
      |                               |
      |         RTP timestamp         |  (From RTP header)
      |                               |
      |                               |
      +-------------------------------+
      |         RTP sequence          |  (From RTP header)
      |                               |
      +-------------------------------+
      |       RTP payload type        |  (From RTP header)
      +-------------------------------+
      |         RTP deltaT            |  (The current second order time
      |                               |   difference from CRTP )
      +...............................+
      :   msb of session context ID   :  (if 16-bit CID   (Flag bit C=1))
      +-------------------------------+
      |   lsb of session context ID   |
      +---+---+---+---+---+---+---+---+
      | M | S | T | I | link sequence |
      +---+---+---+---+---+---+---+---+
      :                               :
      +         UDP checksum          +  (if nonzero in context)
      :                               :
      +...............................+
      :                               :
      +        "RANDOM" fields        +  (if encapsulated)
      :                               :
      +...............................+
      : M'| S'| T'| I'|      CC       :  (if MSTI = 1111)
      +...............................+
      :         delta IPv4 ID         :  (if I or I' = 1)
      +...............................+
      :      delta RTP sequence       :  (if S or S' = 1)
      +...............................+
      :      delta RTP timestamp      :  (if T or T' = 1)
      +...............................+



Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 11]

Internet Draft               Tunneled CRTP                     June 1999


      :                               :
      :           CSRC list           :  (if MSTI = 1111
      :                               :   and CC nonzero)
      :                               :
      +...............................+
      :                               :
      :      RTP header extension     :  (if X set in context)
      :                               :
      :                               :
      +-------------------------------+
      |                               |
      |            RTP data           |
      /                               /
      /                               /
      |                               |
      +-------------------------------+
      :            padding            :  (if P set in context)
      +...............................+

































Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 12]

Internet Draft               Tunneled CRTP                     June 1999


2.2.6. Context State (CS) Payload Format

   There are two CS payload formats: one with long CID, one with short
   CID.  Both are diagrammed below.

   CS payload format with short CID:

        0   1   2   3   4   5   6   7
      +-------------------------------+
      | 1 | 1 | 0 | 0 | 0 |  Length   |  (Opcode CS = 110, C=0 short CID,
      |   |   |   |   |   |           |   E=1 non-multiplexed)
      +...............................+
      :           Length              :
      +---+---+---+---+---+---+---+---+
      | 1 = IP/UDP/RTP with 8-bit CID |
      +---+---+---+---+---+---+---+---+
      |         context count         |
      +---+---+---+---+---+---+---+---+
      +---+---+---+---+---+---+---+---+
      |       session context ID      |
      +---+---+---+---+---+---+---+---+
      | I | 0 | 0 | 0 |    sequence   |
      +---+---+---+---+---+---+---+---+
      | 0 | 0 |       generation      |
      +---+---+---+---+---+---+---+---+
                     ...
      +---+---+---+---+---+---+---+---+
      |       session context ID      |
      +---+---+---+---+---+---+---+---+
      | I | 0 | 0 | 0 |    sequence   |
      +---+---+---+---+---+---+---+---+
      | 0 | 0 |       generation      |
      +---+---+---+---+---+---+---+---+


















Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 13]

Internet Draft               Tunneled CRTP                     June 1999


   CS payload format with long CID:

        0   1   2   3   4   5   6   7
      +-------------------------------+
      | 1 | 1 | 0 | 1 | 0 |  Length   |  (Opcode CS = 110, C=1 long CID,
      |   |   |   |   |   |           |   E=1 non-multiplexed)
      +...............................+
      :           Length              :
      +---+---+---+---+---+---+---+---+
      | 2 = IP/UDP/RTP with 16-bit CID|
      +---+---+---+---+---+---+---+---+
      |         context count         |
      +---+---+---+---+---+---+---+---+
      +---+---+---+---+---+---+---+---+
      |                               |
      +       session context ID      +
      |                               |
      +---+---+---+---+---+---+---+---+
      | I | 0 | 0 | 0 |    sequence   |
      +---+---+---+---+---+---+---+---+
      | 0 | 0 |       generation      |
      +---+---+---+---+---+---+---+---+
                     ...
      +---+---+---+---+---+---+---+---+
      |                               |
      +       session context ID      +
      |                               |
      +---+---+---+---+---+---+---+---+
      | I | 0 | 0 | 0 |    sequence   |
      +---+---+---+---+---+---+---+---+
      | 0 | 0 |       generation      |
      +---+---+---+---+---+---+---+---+

3. Operation of the Protocol

   Generally, the operation of TCRTP is similar to RFC2508 [CRTP].

   The Full Header packet shall consist of the full IP/UDP/RTP packet
   covering the CRTP Header and RTP Payload sections.

   Compression of non-RTP UDP Packets: As with CRTP, TCRTP can also be
   used to compress non-RTP UDP packets: in this case the encoder sends
   only Compressed UDP (CUDP) packets for that stream.

3.1. Differences from RFC2508 behavior

   As TCRTP operates end-to-end instead of hop-by-hop, some changes to
   the behavior described in RFC2508 [CRTP] are necessary.  These



Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 14]

Internet Draft               Tunneled CRTP                     June 1999


   behavior exceptions are described below.

3.1.1. Changes to RTP stream

   If the sending TCRTP determines there are any significant changes to
   the RTP fields that might cause the decompressor to lose
   synchronization if the significant change was lost (as is the case at
   the start of a voice spurt, for example) the sending TCRTP MAY ensure
   that the next N packets are all able to be fully and independently
   reconstructed by the decompressor -- for example, by sending FH, CUDP
   or CRTPX as appropriate.

   If subsequent changes occur before N packets have been generated, the
   count to N is reset.

   The transmission of non-compressed data during a significant event is
   useful for the TCRTP receiver so that it can recover in the event of
   a packet loss or corruption.  This will allow the decompressor to
   recover from the loss of any of the N packets which will be sent.  To
   actually cause the TCRTP receiver to lose state, all N packets would
   have to be dropped or corrupted.

   The value of N is implementation-dependent.  Higher values of N
   consume more bandwidth, while lower values increase the risk of the
   TCRTP decompressor losing synchronization.

   When the decompressor detects lost or out-of-order packets, it should
   continue attempting to decode subsequent packets using the 'twice'
   algorithm instead of simply invalidating the stream as specified in
   RFC2508 [CRTP].

3.1.2. Dealing with lost or out-of-order packets

   In the "normal" case where a long series of CRTP packets are sent
   (i.e.  without FH, CUDP or CRTPX), the "twice" algorithm (described
   below) may allow recovery from loss of up to 16 consecutive packets,
   or out-of-order reception of more than 16 packets.

   It may be also useful for the sender to occasionally send a CRTPX
   packet to ensure the decompressor is not out of synchronization due
   to packet loss.

3.1.3. Decompressor out-of-synchronization indication

   If the decompressor loses synchronization and can no longer decode
   packets, even using the 'twice' algorithm (described below), the
   decompressor should send a Context State packet to the sender.




Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 15]

Internet Draft               Tunneled CRTP                     June 1999


   Upon receipt of a Context State packet, the sender MAY send a FH
   packet followed by a count of N-1 CRTPX packets.

   Due to the round-trip delay between the sender and receiver this
   mechanism should not be relied upon as the only mechanism for the
   decompressor to recover when it has lost synchronization.  The other
   mechanisms described in this section are usually preferred.

3.2. Description of the "'Twice' Algorithm"

   From RFC2508 [CRTP], section 3.3.5:

        In the case where UDP checksums are being transmitted, the
        decompressor MAY attempt to use the "twice" algorithm described
        in section 10.1 of RFC2507 [IPHCOMP].

        In this algorithm, the delta is applied more than once on the
        assumption that the delta may have been the same on the missing
        packet(s) and the one subsequently received.  Success is
        indicated by a checksum match.  For the scheme defined here, the
        difference in the 4-bit sequence number tells number of times
        the delta must be applied.  Note, however, that there is a
        nontrivial risk of an incorrect positive indication.  It may be
        advisable to request a FULL_HEADER or COMPRESSED_NON_TCP packet
        even if the "twice" algorithm succeeds.

3.3. Transmitting CRTPX instead of FH or CUDP

   RFC2508 [CRTP] defines FH and CUDP as the mechanisms to synchronize
   the CRTP receiver.  TCRTP allows FH and CUDP to continue to perform
   this synchronization function, but also defines a new type, CRTPX,
   which does not reset some fields.

   CRTPX is superior to FH and CUDP because:
     *  A CRTPX packet is shorter than a FH or a CUDP packet;
     *  FH and CUDP have the side effect of causing the Delta-T and the
        IP Identification fields to be reset.

4. Multiplexing

   Multiple TCRTP payloads may be concatenated together when they
   originate from the same source host and are being sent to the same
   destination host.  Each TCRTP payload includes its own TCRTP-type and
   TCRTP-length fields.  The IP length is used to determine if multiple
   TCRTP payloads are present.  The length of each TCRTP payload is used
   to determine the location of subsequent TCRTP payloads.

   An implementation SHOULD be able to multiplex multiple streams when



Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 16]

Internet Draft               Tunneled CRTP                     June 1999


   sending, and MUST be able to de-multiplex multiple streams when
   receiving.

4.1. Multiplexed Packet Example

   Example of a multiplexed TCRTP packet that contains 2 TCRTP payloads:
      packet 1: CRTP packet for CID 124: no special change in state
      packet 2: CRTPX packet for CID 891: new deltaT is set, CRTPX
                fields are present

        0   1   2   3   4   5   6   7
      +-------------------------------+
      |                               |
      /         IP Header             /
      /       Protocol=TCRTP          /  IP header of the multiplexed
      /                               /  packet
      /                               /
      |                               |
      +-------------------------------+
      | 1 | 0 | 0 | 0 | 0 |    0      |  Opcode CRTP = 100, C=0: short CID,
      |   |   |   |   |   |           |    E=0: multiplexed
      +-------------------------------+
      |             14                |
      +-------------------------------+
      |            124                |  Short CID: 124
      +---+---+---+---+---+---+---+---+
      | 1 | 0 | 0 | 0 |      5        |  M=1, no other flags, CRTP seq=5
      +---+---+---+---+---+---+---+---+
      |                               |
      +           0x92C1              +  UDP checksum
      |                               |
      +-------------------------------+
      |                               |
      |            RTP data           |  10 bytes of RTP payload
      /                               /
      /                               /
      |                               |
      +-------------------------------+
      | 1 | 0 | 1 | 1 | 0 |    0      |  Opcode CRTPX = 101, C=1=long CID,
      |   |   |   |   |   |           |    E=0=multiplexed
      +-------------------------------+
      |             24                |
      +-------------------------------+
      |                               |
      |          0x21BC6487           |  RTP timestamp (from RTP header)
      |                               |
      |                               |
      +-------------------------------+



Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 17]

Internet Draft               Tunneled CRTP                     June 1999


      |            0x3E29             |  RTP sequence (from RTP header)
      |                               |
      +-------------------------------+
      |             18                |  RTP payload type=18 (from
      |                               |  RTP header)
      +-------------------------------+
      |             10                |  equal to the CRTP deltaT (which
      |                               |    is set in this packet)
      +-------------------------------+
      |                               |
      +             891               +  long CID: 891
      |                               |
      +---+---+---+---+---+---+---+---+
      | 0 | 0 | 1 | 0 |      12       |  M=0, flag T=1: deltaT is
      |   |   |   |   |               |    changing, CRTP sequence=12
      +---+---+---+---+---+---+---+---+
      |                               |
      +            0x4F87             +  UDP checksum
      |                               |
      +-------------------------------+
      |             10                |  T=1
      +-------------------------------+
      |                               |
      |            RTP data           |  10 bytes of RTP payload
      /                               /
      /                               /
      |                               |
      +-------------------------------+

5. Suggested Mechanisms to Indicate Support of TCRTP

   Two mechanisms have been suggested to indicate support of TCRTP
   between two endpoints:

     1.  TCRTP negotiation between two hosts
     2.  Change session announcement protocol to advertise TCRTP
         as well as RTP.

   Method (1) does not require changes to existing session
   announcement protocols, and could be implemented with
   little or even no modifications to existing RTP implementations.
   Its disadvantage is sending unsolicited probes to determine
   if TCRTP is supported by the remote end and the associated
   setup delay.

   Method (2) requires changes to existing session announcement
   protocols.  Its advantage is faster setup than method (1).




Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 18]

Internet Draft               Tunneled CRTP                     June 1999


6. New IP Protocol Number

   TCRTP requires a new IP protocol number.  A formal request to
   IANA for a new IP protocol number assignment will be made.

7. Security Considerations

   This section describes security considerations of TCRTP.

7.1. RTP

   Security considerations that apply to RTP and RTP streams also
   apply to TCRTP streams.  These include sniffing packets to observe
   or listen to communications between two parties.

8. Acknowledgements

   The authors would like to thank the authors of RFC2508, Stephen Casner
   and Van Jacobson, and the authors of RFC2507, Mikael Degermark, Bjorn
   Nordgren, and Stephen Pink.

   The authors would also like to thank Dana Blair, Francois Le Faucheur,
   Tim Gleeson, Matt Madison, Hussein Salama, Mallik Tatipamula, Mike
   Thomas, and Herb Wildfeuer.

9. References

   [CRTP] S. Casner, V. Jacobson, "Compressing IP/UDP/RTP Headers for
   Low-Speed Serial Links", RFC2508, February 1999.

   [H.245] ITU-T Recommendation H.245 (1998), "Control of communications
   between Visual Telephone Systems and Terminal Equipment".

   [IPHCOMP] M. Degermark, B. Nordgren, S. Pink, "IP Header Compression",
   RFC2507, February 1999.

   [KEYW] S. Bradner, "Key words for use in RFCs to Indicate
   Requirement Levels", RFC2119, BCP 14, March 1997.

   [RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, "RTP: A
   Transport Protocol for Real-Time Applications", RFC1889, January 1996.

   [SDP] M. Handley, V. Jacobson, "SDP: Session Description Protocol",
   RFC2327, April 1998.

   [SGCP] M. Arango, C. Huitema, "Simple Gateway Control Protocol
   (SGCP)", Internet Draft, Work In Progress,
   draft-huitema-sgcp-v1-02.txt, Expired.



Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 19]

Internet Draft               Tunneled CRTP                     June 1999


   [SIP] M. Handley, H. Schulzrinne, E. Schooler, J. Rosenberg,
   "SIP: Session Initiation Protocol", RFC2543, March 1999.

10. Authors' Addresses

   Tmima Koren
   170 West Tasman Drive
   San Jose, CA  95134-1706
   United States of America

   Phone: +1 408 527 6169
   Email: tmima@cisco.com


   Patrick Ruddy
   3rd Floor, 96 Commercial Street
   Edinburgh
   EH6 6LX
   Scotland

   Phone: +44 131 561 3608
   Email: pruddy@cisco.com


   Bruce Thompson
   170 West Tasman Drive
   San Jose, CA  95134-1706
   United States of America

   Phone: +1 408 527 0446
   Email: brucet@cisco.com


   Alex Tweedly
   3 The Square, Stockley Park
   Uxbridge, Middlesex
   UB11 1BN
   United Kingdom

   Phone: +44 181 756 8694
   Email: agt@cisco.com










Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 20]

Internet Draft               Tunneled CRTP                     June 1999


   Dan Wing
   170 West Tasman Drive
   San Jose, CA  95134-1706
   United States of America

   Phone: +1 408 525 5314
   Email: dwing@cisco.com

11. Copyright

   Copyright (C) The Internet Society 1999.  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF

















Koren, Ruddy, Thompson, Tweedly, Wing       Expires Dec 1999  [Page 21]


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