[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

draft-hc-requirements-delta-01.txt



Hello All,

Here is a draft describing some proposed additions/modifications to the
existing header compression requirements draft,
draft-degermark-hc-requirements-00.txt
http://search.ietf.org/internet-drafts/draft-degermark-hc-requirements-00.tx
t.   I am submitting on behalf of several authors (see draft) .

My apologies for the delay in posting this material.  Comments are welcome!

Regards,
Chris Clanton
Nokia Research Center - Dallas
Mobile Networks Lab

 <<draft-hc-requirements-delta-01.txt>> 






IETF ROHC Working Group                                    Chris Clanton
INTERNET-DRAFT                                                  Khiem Le
                                                             Zhigang Liu
22 March 2000                                      Nokia Research Center
Expires 22 Sepember 2000                             Mohammad Mahloujian
                                               Ericsson Radio Systems AB
                                                 Nat Natarajan, Motorola
                                                            Donglin Shen
                                                  AT&T Wireless Services
                                                  James Womack, Motorola


   IP/UDP/RTP Header Compression Proposed Modifications and Additions
                  <draft-hc-requirements-delta-01.txt>



Status of This Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.

   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 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."

   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.


Abstract

   This contribution proposes a set additions/modifications to the
   current ROHC draft requirements for IP/UDP/RTP header compression
   [1].







Clanton, etc.           Expires 22 Sepember 2000                [Page i]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


                           Table of Contents


Status of This Memo  . . . . . . . . . . . . . . . . . . . . . . . .   i

Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .   i

1. Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . .   1

2. PROPOSED MODIFICATIONS TO EXISTING REQUIRMENTS  . . . . . . . . .   2
   2.1. Performance/Spectral Efficiency  . . . . . . . . . . . . . .   2
   2.2. IPv6 or IPv4 . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.3. Ubiquity . . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.4. Cellular HO  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.5. Integrity  . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.6. Error Propogation  . . . . . . . . . . . . . . . . . . . . .   3
   2.7. Delay  . . . . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.8. Packet Loss  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.9. Media Supported  . . . . . . . . . . . . . . . . . . . . . .   4
   2.10. Independence With Respect to Call Type  . . . . . . . . . .   4

3. PROPOSED NEW REQUIREMENTS . . . . . . . . . . . . . . . . . . . .   5
   3.1. Packet Misordering . . . . . . . . . . . . . . . . . . . . .   5
   3.2. Operation on Unidirectional Links  . . . . . . . . . . . . .   5
   3.3. Configurable Header Size Fluctuation . . . . . . . . . . . .   5
   3.4. Processing Delay . . . . . . . . . . . . . . . . . . . . . .   6
   3.5. Complexity . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.6. Generic Applicability  . . . . . . . . . . . . . . . . . . .   6
   3.7. Compatibility with Other Schemes . . . . . . . . . . . . . .   6

4. References  . . . . . . . . . . . . . . . . . . . . . . . . . . .   7

5. Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8


















Clanton, etc.           Expires 22 Sepember 2000               [Page ii]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


1.  Introduction

   This contribution proposes a set additions/modifications to the
   current ROHC draft requirements for IP/UDP/RTP header compression
   [1].  Those requirements are based on requirements in [2].  Section 2
   describes proposed modifications to the existing requirements in [1].
   Section 3 describes a set of new requirements which we believe should
   be added.

   It is a fundamental requirement for both GERAN (specified by ETSI
   SMG2 standards group) and UTRAN (specified by 3GPP standards
   organization) to support end-to-end IP real time services, such as
   voice over IP and real time data in their respective Release 2000
   specifications.  In order to achieve the required spectral
   efficiency, it is mandatory to develop/standardize an effective
   IP/UDP/RTP header compression scheme that is suitable for cellular
   applications before completion of the Release 2000 standards.  The
   current IETF ROHC charter timeline indicates milestones/goals which
   we believe would be in line with the completion schedules of both
   ETSI and 3GPP.  Due to the fact that this work is a critical part of
   Release 2000 standardization, it should be reiterated that it is
   imperative for this work to be completed on schedule.





























Clanton, etc.           Expires 22 Sepember 2000                [Page 1]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


2.  PROPOSED MODIFICATIONS TO EXISTING REQUIRMENTS

   We address each existing requirement in order below.  In each case,
   requirement name, actual requirement text, and/or the associated
   justification text may have a proposed change.


2.1.  Performance/Spectral Efficiency

   Requirement:    "Must provide low relative overhead under expected
                   operating conditions; compression efficiency should
                   be better than RFC2508 under similar error
                   conditions"

   Justification:  "In general, a primary goal is high spectral
                   efficiency.  Reduction of overhead has direct impact.
                   Notes: Relative overhead is the header overhead
                   relative to the payload; performance should take into
                   account usage of any auxiliary (e.g. control or
                   feedback) channels during operation of the scheme."


2.2.  IPv6 or IPv4

   Justification:  "Ipv4 and Ipv6 terminals are expected to coexist for
                   some time.  Note: compression efficiency when
                   processing IPv6 packets may not be the same as IPv4."


2.3.  Ubiquity

   No change.


2.4.  Cellular HO

   Requirement:    "Must support the cellular handoff operation; the
                   disruption when the header compression scheme is
                   present shall not be longer than when there is no
                   header compression; loss of compression efficiency,
                   even temporary, shall be minimized; must be lossless
                   after handoff"


   Justification:  "A target application is adaptation of user plane
                   traffic transmitted on cellular air interfaces;
                   therefore this operation must be supported.  Minimum
                   disruption of the compression process is desired



Clanton, etc.           Expires 22 Sepember 2000                [Page 2]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


                   because there can otherwise be negative impacts on
                   spectral efficiency and voice quality."


2.5.  Integrity

   Justification:  "Would like to maintain the end-to-end integrity of
                   IP.  Lossless here refers to ability to reconstruct
                   the transmitted header exactly at the receiver."


2.6.  Error Propogation

   Requirement:    "Error propagation due to header compression should
                   be kept to an absolute minimum; error propagation is
                   defined as the loss of packets subsequent to the one
                   where the error actually occurred, even when those
                   subsequent packets contain no errors."


2.7.  Delay

   Name:           Delay and Jitter

   Requirement:    "Must operate under all expected delay/jitter
                   conditions."

   Justification:  "The user may be in different types of network
                   environments with different characteristics."


2.8.  Packet Loss

   Requirement:    "Must operate under all expected packet loss
                   conditions; prefer that header compression efficiency
                   is as independent of packet loss rate as possible;
                   the packet loss could occur prior to, or after the
                   compressor."

   Justification:  "The user may be in different types of environments
                   with different characteristics, e.g., packet loss
                   could occur prior to the compressor on the downlink
                   if there is loss in the IP network.  Ability to
                   adjust scheme parameters should be possible in order
                   to enable optimizations for specific operating
                   conditions (e.g., if it is known that with particular
                   radio technology there is seldom loss of several
                   consecutive packets in a row,  compressed sequence



Clanton, etc.           Expires 22 Sepember 2000                [Page 3]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


                   number may require fewer bits to prevent wrap-around
                   ambiguity)."


2.9.  Media Supported

   No change.


2.10.  Independence With Respect to Call Type

   Requirement:    "Must function for mobile-to-mobile, landline to
                   mobile and mobile-to-landline calls; performance in
                   each case should be comparable to existing cellular
                   (in terms of both quality and spectral efficiency)"

   Justification:  change the word "both" to "All".


































Clanton, etc.           Expires 22 Sepember 2000                [Page 4]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


3.  PROPOSED NEW REQUIREMENTS

   The requirements below are being proposed as additions to the current
   list.


3.1.  Packet Misordering

   Requirement:    "Compressor must be able to function without failure
                   even when packets are misordered."

   Justification:  "Packet misordering may occur upstream relative to
                   the compressor; this is especially true on the
                   downlink in cellular systems employing header
                   compression, since packets are arriving from an IP
                   network; it should be possible to adjust relevant
                   scheme parameters in order to enable optimizations
                   for specific operating conditions (e.g., if it is
                   known that there is significant misordering prior to
                   compressor, a smaller compressed sequence number
                   might suffice)."


3.2.  Operation on Unidirectional Links

   Requirement:    "Must include some provision for operation on links
                   which do not have a corresponding feedback channel."

   Justification:  "The header compression scheme should be capable of
                   functioning on simplex links; however, use of a
                   feedback channel should not be precluded (likely
                   performance increase)."


3.3.  Configurable Header Size Fluctuation

   Requirement:    "Scheme should support various degrees of header size
                   fluctuation."

   Justification:  "Depending on the radio technology in use, various
                   levels of header size fluctuation may be supported in
                   an optimal way; efficiency gained through the use of
                   more flexible radio bearer architecture should not be
                   precluded."







Clanton, etc.           Expires 22 Sepember 2000                [Page 5]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


3.4.  Processing Delay

   Requirement:    "Processing delay and related delay jitter should be
                   minimized; the delay/jitter introduced by the header
                   compression process should not cause the target
                   system delay budget to be exceeded."

   Justification:  "The service quality of conversation applications is
                   very sensitive to processing/propagation delay and
                   delay jitter.  Processing delay should be independent
                   of round-trip time/transmission bandwidth available."


3.5.  Complexity

   Requirement:    "Implementation complexity should be minimized."

   Justification:  "Implementation complexity should be such that the
                   scheme can execute in a processing power-limited
                   device (mobile phone), but still be easily scaled up
                   for use in devices which handle multiple flows
                   (infrastructure)."


3.6.  Generic Applicability

   Requirement:    "The algorithm must be independent of the link
                   capabilities of the various radio technologies."

   Justification:  "Header compression is envisioned for radio
                   technologies with differing capabilities, e.g., EDGE,
                   WCDMA, CDMA 2000 etc."


3.7.  Compatibility with Other Schemes

   Requirement:    "Header compression scheme should not preclude the
                   coexistence of other header adaptation schemes."

   Justification:  "Several different header adaptation schemes may
                   operate within the same system. The particular scheme
                   selected is negotiated at set-up time.  Its selection
                   will depend upon the transport protocol, e.g.
                   RTP/UDP/IP, UDP/IP, TCP/IP, etc."







Clanton, etc.           Expires 22 Sepember 2000                [Page 6]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


4.  References

   [1] 3GPP Requirements for Header Compression, <draft-degermark-hc-
       requirements-00.txt>

   [2] 3rd Generation Partnership Project, Services and Systems Aspects
       Technical Specification Group, "Architecture for All-IP
       Networks", 3G TR 23.922 version 1.00.

   [3] S. Casner, V. Jacobson. "Compressing IP/UDP/RTP Headers for Low-
       Speed Serial Links", Internet Engineering Task Force (IETF) RFC
       2508, February 1999.







































Clanton, etc.           Expires 22 Sepember 2000                [Page 7]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


5.  Authors' Addresses


   Chris Clanton
   Nokia
   6000 Connection Drive
   Irving, Texas 75039
   USA

   Phone:  +1 972-894-4886
   Fax:    +1 972-894-4589
   Email:  christopher.clanton@nokia.com


   Khiem Le
   Nokia
   6000 Connection Drive
   Irving, Texas 75039
   USA

   Phone:  +1 972-894-4882
   Fax:    +1 972-894-4589
   Email:  khiem.le@nokia.com


   Zhigang Liu
   Nokia
   6000 Connection Drive
   Irving, Texas 75039
   USA

   Phone:  +1 972-894-5935
   Fax:    +1 972-894-4589
   Email:  zhigang.liu@nokia.com


   Mohammad Mahloujian
   Ericsson Radio Systems AB
   S-164 80 Stockholm, Sweden

   Phone:  +46 (0)8 585 321 13
   Fax:    +46 (0)8 404 46 13
   Email:  mohammad.mahloujian@era.ericsson.se








Clanton, etc.           Expires 22 Sepember 2000                [Page 8]





INTERNET-DRAFT        HC Requirement Modifications         22 March 2000


   Nat Natarajan
   Motorola
   Arlington Heights, IL 60004

   Phone:  +1 847-632-6303
   Email:  ann004@email.mot.com


   Donglin Shen
   AT&T Wireless Services
   P.O. Box 97061
   Redmond WA 98073
   USA

   Phone:  +1 425-580-7614
   Fax:    +1 425-580-6765
   Email:  donglin.shen@attws.com


   Jim Womack, Ph.D.
   Motorola
   Advanced Technology & Software Organization

   Phone:  +1 817-245-2853
   Email:  James.Womack@motorola.com


























Clanton, etc.           Expires 22 Sepember 2000                [Page 9]