Internet DRAFT - draft-ietf-tsvwg-udp-lite


    Network Working Group                                        L-A. Larzon 
    INTERNET-DRAFT                            Lulea University of Technology 
    Expires: January 2003                                       M. Degermark 
                                                                     S. Pink 
                                                   The University of Arizona 
                                                       L-E. Jonsson (Editor) 
                                                       G. Fairhurst (Editor) 
                                                      University of Aberdeen 
                                                                August, 2003 
                              The UDP-Lite Protocol 
    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 cite them other than as "work in progress". 
       The list of current Internet-Drafts can be accessed at 
       The list of Internet-Draft Shadow Directories can be accessed at 
       Please direct comments to the TSV WG mailing list: 
       This document describes the UDP-Lite protocol, which is similar to 
       UDP [RFC-768], but can also serve applications that in error-prone 
       network environments prefer to have partially damaged payloads 
       delivered rather than discarded. If this feature is not used, UDP-
       Lite is semantically identical to UDP. 
    Table of Contents 
    Larzon, et al.                                                  [Page 1]  
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
       1.  Introduction...................................................2 
       2.  Terminology....................................................3 
       3.  Protocol Description...........................................3 
          3.1.  Fields....................................................3 
          3.2.  Pseudo Header.............................................4 
          3.3.  Application Interface.....................................4 
          3.4.  IP Interface..............................................5 
          3.5.  Jumbograms................................................5 
       4.  Lower Layer Considerations.....................................6 
       5.  Compatibility with UDP.........................................6 
       6.  Security Considerations........................................7 
       7.  IANA Considerations............................................8 
       8.  References.....................................................8 
          8.1.  Normative References......................................8 
          8.2.  Informative References....................................9 
       9.  Acknowledgements...............................................10 
       10.  Authors' Addresses............................................11 
       1.  Introduction 
       This document describes a new transport protocol, UDP-Lite, (also 
       known as UDPLite). This new protocol is based on three observations: 
       First, there is a class of applications that benefit from having 
       damaged data delivered rather than discarded by the network. A number 
       of codecs for voice and video fall into this class (e.g. the AMR 
       speech codec [RFC-3267], the Internet Low Bit Rate Codec [ILBRC], and 
       error resilient H.263+ [ITU-H.263], H.264 [ITU-H.264; H.264] and 
       MPEG-4 [ISO-14496] video codecs). These codecs may be designed to 
       cope better with errors in the payload than with loss of entire 
       Second, all links that support IP transmission should use a strong 
       link layer integrity check (e.g. CRC-32 [LINK]), and this MUST be 
       used by default for IP traffic. When the under-lying link supports 
       it, certain types of traffic (e.g. UDP-Lite) may benefit from a 
       different link behavior that permits partially damaged IP packets to 
       be forwaded when requested [LINK]. Several radio technologies (e.g. 
       [3GPP-QoS])  support this link behavior when operating at a point 
       where cost and delay are sufficiently low. If error-prone links are 
       aware of the error sensitive portion of a packet, it is also possible 
       for the physical link to provide greater protection to reduce the 
       probability of corruption of these error sensitive bytes (e.g., the 
       use of unequal Forward Error Correction).  
       Third, intermediate layers (i.e., IP and the transport layer 
       protocols) should not prevent error-tolerant applications from 
       running well in the presence of such links. IP is not a problem in 
       this regard, since the IP header has no checksum that covers the IP 
       payload. The generally available transport protocol best suited for 
    Larzon, et al.                                                  [Page 2] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
       these applications is UDP, since it has no overhead for 
       retransmission of erroneous packets, in-order delivery, or error 
       correction. In IPv4 [RFC-791], the UDP checksum covers either the 
       entire packet or nothing at all. In IPv6 [RFC-2460], the UDP checksum 
       is mandatory and must not be disabled. The IPv6 header does not have 
       a header checksum and it was deemed necessary to always protect the 
       IP addressing information by making the UDP checksum mandatory. 
       A transport protocol is needed that conforms to the properties of 
       link layers and applications described above [LDP99]. The error-
       detection mechanism of the transport layer must be able to protect 
       vital information such as headers, but also to optionally ignore 
       errors best dealt with by the application. The set of octets to be 
       verified by the checksum is best specified by the sending 
       UDP-Lite provides a checksum with an optional partial coverage. When 
       using this option, a packet is divided into a sensitive part (covered 
       by the checksum) and an insensitive part (not covered by the 
       checksum). Errors in the insensitive part will not cause the packet 
       to be discarded by the transport layer at the receiving end host.  
       When the checksum covers the entire packet, which should be the 
       default, UDP-Lite is semantically identical to UDP. 
       Compared to UDP, the UDP-Lite partial checksum provides extra 
       flexibility for applications that want to define the payload as 
       partially insensitive to bit errors. 
    2.  Terminology 
       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]. 
    3.  Protocol Description 
       The UDP-Lite header is shown in figure 1. Its format differs from  
       UDP in that the Length field has been replaced with a Checksum 
       Coverage field. This can be done since information about UDP packet 
       length can be provided by the IP module in the same manner as for TCP 
    Larzon, et al.                                                  [Page 3] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
                        0              15 16             31 
                       |     Source      |   Destination   | 
                       |      Port       |      Port       | 
                       |    Checksum     |                 | 
                       |    Coverage     |    Checksum     | 
                       |                                   | 
                       :              Payload              : 
                       |                                   | 
                          Figure 1: UDP-Lite Header Format 
    3.1.  Fields 
       The fields Source Port and Destination Port are defined as in the UDP 
       specification [RFC-768]. UDP-Lite uses the same set of port number 
       values as those assigned by the IANA for use by UDP. 
       Checksum Coverage is the number of octets, counting from the first 
       octet of the UDP-Lite header, that are covered by the checksum. The 
       UDP-Lite header MUST always be covered by the checksum. Despite this 
       requirement, the Checksum Coverage is expressed in octets from the 
       beginning of the UDP-Lite header, in the same way as for UDP. A 
       Checksum Coverage of zero indicates that the entire UDP-Lite packet 
       is covered by the checksum. This means that the value of the Checksum 
       Coverage field MUST be either 0 or at least 8. A UDP-Lite packet with 
       a Checksum Coverage value of 1 to 7 MUST be discarded by the 
       receiver. Irrespective of the Checksum Coverage, the computed 
       Checksum field MUST include a pseudo-header, based on the IP header 
       (see below). UDP-Lite packets with a Checksum Coverage greater than 
       the IP length MUST also be discarded. 
       The Checksum field is the 16-bit one's complement of the one's 
       complement sum of a pseudo-header of information collected from the 
       IP header, the number of octets specified by the Checksum Coverage 
       (starting at the first octet in the UDP-Lite header), virtually 
       padded with a zero octet at the end (if necessary) to make a multiple 
       of two octets [RFC-1071]. Prior to computation, the checksum field 
       MUST be set to zero. If the computed checksum is 0, it is transmitted 
       as all ones (the equivalent in one's complement arithmetic).  
       Since the transmitted checksum MUST NOT be all zeroes, an application 
       using UDP-Lite that wishes to have no protection of the packet 
       payload, should use a Checksum Coverage value of 8. This differs from 
       the use of UDP over IPv4, in that the minimal UDP-Lite checksum 
       always covers the UDP-Lite protocol header, which includes the 
       Checksum Coverage field. 
    Larzon, et al.                                                  [Page 4] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
    3.2.  Pseudo Header 
       UDP and UDP-Lite use the same conceptually prefixed pseudo header 
       from the IP layer for the checksum. This pseudo header is different 
       for IPv4 and IPv6. The pseudo header of UDP-Lite is different from 
       the pseudo header of UDP in one way: The value of the Length field of 
       the pseudo header is not taken from the UDP-Lite header, but rather 
       from information provided by the IP module. This computation is done 
       in the same manner as for TCP [RFC-793], and implies that the Length 
       field of the pseudo header includes the UDP-Lite header and all 
       subsequent octets in the IP payload. 
    3.3.  Application Interface 
       An application interface should allow the same operations as for  
       UDP. In addition to this, it should provide a way for the sending 
       application to pass the Checksum Coverage value to the UDP-Lite 
       module. There should also be a way to pass the Checksum Coverage 
       value to the receiving application, or at least let the receiving 
       application block delivery of packets with coverage values less than 
       a value provided by the application. 
       It is RECOMMENDED that the default behavior of UDP-Lite be to mimic  
       UDP by having the Checksum Coverage field match the length of the 
       UDP-Lite packet, and verify the entire packet. Applications that wish 
       to define the payload as partially insensitive to bit errors (e.g. 
       error tolerant codecs using RTP [RFC-1889]) should do this by an 
       explicit system call on the sender side. Applications that wish to 
       receive payloads that were only partially covered by a checksum 
       should inform the receiving system by an explicit system call. 
       The characteristics of the links forming an Internet path may vary 
       greatly. It is therefore difficult to make assumptions about the 
       level or patterns of errors that may occur in the corruption 
       insensitive part of the UDP-Lite payload. Applications that use UDP-
       Lite should not make any assumptions regarding the correctness of the 
       received data beyond the position indicated by the Checksum Coverage 
       field, and should if necessary introduce their own appropriate 
       validity checks. 
    3.4.  IP Interface 
       As for UDP, the IP module must provide the pseudo header to the UDP-
       Lite protocol module (known as the UDPLite module). The UDP-Lite 
       pseudo header contains the IP addresses and protocol fields of the IP 
       header, and also the length of the IP payload, which is derived from 
       the Length field in the IP header. 
       The sender IP module MUST NOT pad the IP payload with extra octets, 
       since the length of the UDP-Lite payload delivered to the receiver 
       depends on the length of the IP payload. 
    Larzon, et al.                                                  [Page 5] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
    3.5.  Jumbograms 
       The Checksum Coverage field is 16 bits and can represent a Checksum 
       Coverage value of up to 65535 octets. This allows arbitrary checksum 
       coverage for IP packets, unless they are Jumbograms. For Jumbograms, 
       the checksum can cover either the entire payload (when the Checksum 
       Coverage field has the value zero), or else at most the initial 65535 
       octets of the UDP-Lite packet. 
    4.  Lower Layer Considerations 
       Since UDP-Lite can deliver packets with damaged payloads to an 
       application that wishes to receive them, frames carrying UDP-Lite 
       packets need not be discarded by lower layer protocols when there are 
       errors only in the insensitive part. For a link that supports partial 
       error detection, the Checksum Coverage field in the UDP-Lite header 
       MAY be used as a hint of where errors do not need to be detected. 
       Lower layers MUST use a strong error detection mechanism [LINK] to 
       detect at least errors that occur in the sensitive part of the 
       packet, and discard damaged packets. The sensitive part consists of 
       the octets between the first octet of the IP header and the last 
       octet identified by the Checksum Coverage field. The sensitive part 
       would thus be treated in exactly the same way as for a UDP packet. 
       Link layers that do not support partial error detection suitable for 
       UDP-Lite, as described above, MUST detect errors in the entire UDP-
       Lite packet, and MUST discard damaged packets [LINK]. The whole UDP-
       Lite packet is thus treated in exactly the same way as a UDP packet.  
       It should be noted that UDP-Lite would only make a difference to an 
       application if partial error detection, based on the partial checksum 
       feature of UDP-Lite, is implemented also by link layers, as discussed 
       above. Partial error detection at the link layer would only make a 
       difference when implemented over error-prone links. 
    5.  Compatibility with UDP 
       UDP and UDP-Lite have similar syntax and semantics. Applications 
       designed for UDP may therefore use UDP-Lite instead, and will by 
       default receive the same full packet coverage. The similarities also 
       ease implementation of UDP-Lite, since only minor modifications are 
       needed to an existing UDP implementation. 
       UDP-Lite has been allocated a separate IP protocol identifier, XXXX  
       receiver to identify whether UDP or UDP-Lite is used. A destination 
       end host that is unaware of UDP-Lite will, in general, return an ICMP 
    Larzon, et al.                                                  [Page 6] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
       "Protocol Unreachable" or an ICMPv6 "Payload Type Unknown" error 
       message (depending on the IP protocol type). This simple method of 
       detecting UDP-Lite unaware systems is the primary benefit of having 
       separate protocol identifiers. 
       The remainder of this section provides the rationale for allocating a 
       separate IP protocol identifier for UDP-Lite, rather than sharing the 
       IP protocol identifier with UDP. 
       There are no known interoperability problems between UDP and UDP-Lite 
       if they were to share the protocol identifier with UDP. Specifically, 
       there is no case where a potentially problematic packet is delivered 
       to an unsuspecting application; a UDP-Lite payload with partial 
       checksum coverage cannot be delivered to UDP applications, and UDP 
       packets that only partially fill the IP payload cannot be delivered 
       to applications using UDP-Lite. 
       However, if the protocol identifier were to have been shared between 
       UDP and UDP-Lite, and a UDP-Lite implementation was to send a UDP-
       Lite packet using a partial checksum to a UDP implementation, the UDP 
       implementation would silently discard the packet, because a 
       mismatching pseudo header would cause the UDP checksum to fail. 
       Neither the sending nor the receiving application would be notified. 
       Potential solutions to this could have been: 
         1) explicit application in-band signaling (while not using the 
            partial checksum coverage option) to enable the sender to learn 
            whether the receiver is UDP-Lite enabled or not, or 
         2) use of out-of-band signaling such as H.323, SIP, or RTCP to 
         convey whether the receiver is UDP-Lite enabled. 
       Since UDP-Lite has been assigned its own IP protocol identifier, 
       there is no need to consider this possibility of delivery of a UDP-
       Lite packet to an unsuspecting UDP port. 
       6.  Security Considerations 
       The security impact of UDP-Lite is related to its interaction with 
       authentication and encryption mechanisms. When the partial checksum 
       option of UDP-Lite is enabled, the insensitive portion of a packet 
       may change in transit. This is contrary to the idea behind most 
       authentication mechanisms: authentication succeeds if the packet has 
       not changed in transit. Unless authentication mechanisms that operate 
       only on the sensitive part of packets are developed and used, 
       authentication will always fail for UDP-Lite packets where the 
       insensitive part has been damaged. 
       The IPSec integrity check (Encapsulation Security Protocol, ESP, or 

    Larzon, et al.                                                  [Page 7] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
       Authentication Header, AH) is applied (at least) to the entire IP 
       packet payload. Corruption of any bit within the protected area will 
       then result in the IP receiver discarding the UDP-Lite packet. 
       When IPSEC is used with ESP payload encryption, a link can not  
       determine the specific transport protocol of a packet being forwarded 
       by inspecting the IP packet payload. In this case, the link MUST 
       provide a standard integrity check covering the entire IP packet and 
       payload. UDP-Lite provides no benefit in this case. 
       Encryption (e.g., at the transport or application levels) 
       may be used.  Note that omitting an integrity check can, under 
       certain circumstances, compromise confidentiality [Bell98]. 
       If a few bits of an encrypted packet are damaged, the decryption 
       transform will typically spread errors so that the packet becomes 
       too damaged to be of use.  Many encryption transforms today exhibit 
       this behavior.  There exist encryption transforms, stream ciphers, 
       which do not cause error propagation.  Proper use of stream ciphers 
       can be quite difficult, especially when authentication-checking is 
       omitted [BB01].  In particular, an attacker can cause predictable 
       changes to the ultimate plaintext, even without being able to 
       decrypt the ciphertext. 
    7.  IANA Considerations 
       A new IP protocol number, XXXX [INSERT NUMBER BEFORE PUBLICATION], 
       has been assigned for UDP-Lite.  The name associated with this 
       protocol number is "UDPLite".  This ensures compatibility across a 
       wide range of platforms, since on some platforms the "-" character 
       may not form part of a protocol entity name. 
       IANA assignment instruction: 
           The IANA must reserve an IP protocol number for UDP-Lite. 
           IANA - Please NOTE the name of the registry entry MUST be 
           "UDPLite", as detailed above. 
       [END OF NOTE] 

    Larzon, et al.                                                  [Page 8] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
    8.  References 
    8.1.  Normative References 
       [RFC-768]   Postel, J., "User Datagram Protocol", RFC 768 (STD6), 
                   August 1980. 
       [RFC-791]   Postel, J., "Internet Protocol", RFC 791 (STD5), 
                   September 1981. 
       [RFC-793]   Postel, J., "Transmission Control Protocol", RFC 793 
                   (STD7), September 1981. 
       [RFC-1071]  Braden, R., Borman, D., and C. Partridge, "Computing the 
                   Internet Checksum", RFC 1071, September 1988. 
       [RFC-2119]  Bradner, S., "Key words for use in RFCs to Indicate 
                   Requirement Levels", RFC 2119 (BCP15), March 1997. 
       [RFC-2460]  Deering, S., and R. Hinden, "Internet Protocol, Version 6 
                   (IPv6) Specification", RFC 2460, December 1998. 
    8.2.  Informative References 
       [Bell98]    Bellovin, S.M., "Cryptography and the Internet", 
                   Proceedings of CRYPTO 98, August, 1988. 
       [BB01]      Bellovin, S.M., and M. Blaze, "Cryptographic Modes of 
                   Operation for the Internet", 2nd  NIST Workshop on Modes 
                   of Operation, August 2001. 
       [3GPP]      "Technical Specification Group Services and System  
                   Aspects; Quality of Service (QoS) concept and 
                   architecture", TS 23.107 V5.9.0, Technical Specification 
                   3rd  Generation Partnership Project, June 2003. 
       [H.264]     Hannuksela, M.M., T. Stockhammer, M. Westerlund. And 
                   D. Singer, "RTP payload Format for H.264 Video", Internet 
                   Draft, Work in Progress, March 2003. 
       [ILBRC]     S.V. Andersen, et. al., "Internet Low Bit Rate Codec",  
                   draft-ietf-avt-ilbc-codec-01.txt, Internet Draft, Work in 
                   Progress, March 2003. 
       [ISO-14496] ISO/IEC International Standard 1446 (MPEG-4),  
                   "Information Technology  Coding of Audio-Visual 
                   Objects", January 2000. 
       [ITU-H.263] "Video Coding for Low Bit Rate Communication," ITU-T 
                   Recommendation H.263, January 1998.     
    Larzon, et al.                                                  [Page 9] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 

       [ITU-H.264] "Draft ITU-T Recommendation and Final Draft International 
                   Standard of Joint Video Specification", 
                   ITU-T Recommendation H.264, May 2003. 
       [LINK]      Phil Karn, Editor, "Advice for Internet Subnetwork  
                   Designers", Work in Progress, IETF. 
       [RFC-1889]  Schulzrinne, H., Casner, S., Frederick, R., and 
                   V. Jacobson, "RTP: A Transport Protocol for Real-Time 
                   Applications", RFC 1889, January 1996.  
       [RFC-2026]  Bradner, S., "The Internet Standards Process", RFC 2026, 
                   October 1996. 
       [RFC-2402]  Kent, S., and R. Atkinson, "IP Authentication Header", 
                   RFC 2402, November 1998. 
       [RFC-2406]  Kent, S., and R. Atkinson, "IP Encapsulating Security 
                   Payload (ESP)", RFC 206, November 1998. 
       [RFC-3267]  Sjoberg, J., M. Westerlund, A. Lakeaniemi, and Q. Xie, 
                   "Real-Time Transport Protocol (RTP) Payload Format and  
                   File Storage Format for the Adaptiove Multi-Rate (AMR)  
                   and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs",  
                   RFC 3267, June 2002. 
       [LDP99]     Larzon, L-A., Degermark, M., and S. Pink, "UDP Lite for 
                   Real-Time Multimedia Applications", Proceedings of the 
                   IEEE International Conference of Communications (ICC), 
    9.  Acknowledgements 
       Thanks to Ghyslain Pelletier for significant technical and editorial 
       comments. Thanks also to Steven Bellovin, Elisabetta Carrara, and 
       Mats Naslund for reviewing the security considerations chapter, and 
       to Peter Eriksson for a language review and thereby improving the 
       clarity of this document. 

    Larzon, et al.                                                 [Page 10] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
    10.  Authors' Addresses 
       Lars-Ake Larzon 
       Department of CS & EE 
       Lulea University of Technology 
       S-971 87 Lulea, Sweden 
       Mikael Degermark 
       Department of Computer Science 
       The University of Arizona 
       P.O. Box 210077 
       Tucson, AZ 85721-0077, USA 
       Stephen Pink 
       The University of Arizona 
       P.O. Box 210077 
       Tucson, AZ 85721-0077, USA 
       Lars-Erik Jonsson 
       Ericsson AB 
       Box 920 
       S-971 28 Lulea, Sweden 
       Godred Fairhurst 
       Department of Engineering 
       University of Aberdeen 
       Aberdeen, AB24 3UE, UK 

    Larzon, et al.                                                 [Page 11] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
    Full Copyright Statement 
       Copyright (C) The Internet Society (2002). 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 
       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 
    This Internet-Draft expires December, 2003. 

    Larzon, et al.                                                 [Page 12] 
    INTERNET-DRAFT                   UDP-Lite                   August, 2003 
       Document History 02j - This section is intended to assist the AD in 
       review of the document. It must be deleted by the RFC Editor. 
       (1)  IANA Assignemnet Name chnage UDP-Lite renamed UDPLite to 
            increase the portability of the code to operating systems that 
            use the "-" character as a part of the mapping function (i.e. 
            not allowed in the protocol ID). 
            Having done this, I now worry a little that this may now divorce 
            the RFC from the previous published work --- should we also 
            refer people to UDP-Lite?  
       (2) Text added to 2nd para, section 3.1 to say pseudo header always 
       (3) Text added to 2nd para, section 3.1 to say initial checksum value 
       is zero. 
       (4) Section 5, added IPv6 text: A destination end host that is 
       unaware of UDP-Lite will, in general, return an ICMP "Protocol 
       Unreachable" or an ICMPv6 "Payload Type Unknown" error message 
       (depending on the IP protocol type). 
       (5) BSD Code behaviour? This is a protocol problem with a BSD 
       implementation, not a spec fault.  
       (6) Examples added of applications 
       (7) Examples of systems that would use it 
       (8) Security issues (text requested by IESG). 
       (9) Minor NiTs with written English corrected. 
       (10) Introduction starts rather strangely - can we fix this? 
       (11) Security AD Text Revised, and now OK. 
       (12) Revised security note: 
       When IPSEC is used with ESP payload encryption, there is no 
       visibility of the transport header, and therefore a link can not 
       determine which transport layer protocol is used, and would not be 
       able to determine the value of the Checksum Coverage field. UDP-Lite 
       provides no benefit in this case, and the link MUST provide a 
       standard integrity check. 
       [END OF NOTE] 
    Larzon, et al.                                                 [Page 13]