One document matched: draft-ash-e2e-voip-hdr-comp-rqmts-01.txt

Differences from draft-ash-e2e-voip-hdr-comp-rqmts-00.txt

Network Working Group                                        Jerry Ash
Internet Draft                                               Bur Goode
<draft-ash-e2e-voip-hdr-comp-rqmts-01.txt>                    Jim Hand
Expiration Date: March 2004                                       AT&T
                                                         Raymond Zhang
                                          Infonet Services Corporation

                                                         October, 2003


   Requirements for VoIP Header Compression over Multiple-Hop Paths

           <draft-ash-e2e-voip-hdr-comp-rqmts-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:

VoIP typically uses the encapsulation voice/RTP/UDP/IP/.  When MPLS 
labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels.  For an 
MPLS VPN, the packet header is at least 48 bytes, while the voice 
payload is often no more than 30 bytes.  VoIP header compression can 
significantly reduce the VoIP overhead through various compression 
mechanisms.  This is important on access links where bandwidth is 
scarce, and can be important on backbone facilities, especially where 
costs are high (e.g., some global cross-sections).  Providing VoIP 
header compression over multiple hop paths avoids multiple 
compression/decompression cycles at each router, and thereby increases 
the processing scalability of the maximum number of simultaneous VoIP 
flows which use header compression at each router.  This draft gives a 
problem statement, example scenarios, goals, and requirements for VoIP 
header compression from compressor to decompressor over multiple-hop 
paths, possibly over MPLS.  It also discusses work items and issues for 
consideration, and highlights various solution alternatives that have 
been proposed.

Table of Contents

   1. Introduction             
   2. Example Scenarios
   3. Problem Statement, Goals, & Requirements
   4. Work Items & Issues
   5. Security Considerations                                            
   6. References
   7. Authors' Addresses
   Appendix A. Summary of Proposed Solutions
   8. Full Copyright Statement                                     

1. Introduction

Voice over IP (VoIP) typically uses the encapsulation voice/RTP/UDP/IP/. 
When MPLS labels are added, this becomes voice/RTP/UDP/IP/MPLS-labels.  
For an MPLS VPN (e.g., [MPLS-VPN], the packet header is at least 48 
bytes, while the voice payload is often no more than 30 bytes.  The 
interest in VoIP header compression is to exploit the possibility of 
significantly reducing the VoIP overhead through various compression 
mechanisms, and also to increase scalability of VoIP header compression. 
Providing VoIP header compression over multiple hop paths avoids 
multiple compression/decompression cycles at each router, and thereby 
increases the processing scalability of the maximum number of 
simultaneous VoIP flows which use header compression at each router.

The need for compression may be important on access links where 
bandwidth is more scarce, but it could be important on backbone 
facilities, especially where costs are high (e.g., some global 
cross-sections). Typically on access and international routes, VoIP will 
use voice compression mechanisms (e.g., G.729) in order to conserve 
bandwidth. With VoIP header compression, significantly more bandwidth 
could be saved. For example, carrying VoIP headers for the entire voice 
load of a large domestic network with 300 million or more calls per day 
could consume on the order of about 20-40 gigabits-per-second on the 
backbone network for headers alone. This overhead could translate into 
considerable bandwidth capacity.

The claim is often made that once fiber is in place, increasing the 
bandwidth capacity is inexpensive, nearly 'free'.  This may be true in 
some cases, however, on some international cross-sections, especially, 
facility/transport costs are very high and saving bandwidth on such 
backbone links is very worthwhile. Decreasing the backbone bandwidth is 
needed in some areas of the world where bandwidth is very expensive.  
More important in almost all locations is decreasing the access 
bandwidth.  While VoIP header compression over multiple hops clearly 
helps decrease bandwidth requirements, it also avoids 
compression-decompression cycles at access boundaries.  So although 
bandwidth is getting cheaper, the value of compression does not go 
away.  In addition, IPv6 will increase the size of headers and 
therefore increase the importance of header compression for VoIP flows.

In principle, we could use existing header compression techniques, such 
as those described in [cRTP], together with MPLS labels to make the 
transport of the RTP/UDP/IP headers more efficient over an MPLS network. 
Alternatively, if MPLS labels are not used for forwarding, mechanisms 
based on a session context ID (SCID) could be used to route compressed 
packets from compressor to decompressor over multiple hop paths.  
However, at this time, there are no standards for VoIP header 
compression from compressor to decompressor over multiple hop paths, and 
vendors have not implemented such techniques.

[cRTP] header compression is often used on the access links from the CE 
router to the PE router. However, cRTP header compression must be 
implemented on a hop-by-hop basis, and does not scale well for large 
voice traffic loads.  The maximum number of cRTP flows is about 30 for a 
typical customer premise router, but the need can exceed 300 for a 
high-end case, and 300-500 for a typical PE router.  By using VoIP 
header compression over multiple hops, routers merely forward compressed 
packets without doing a decompression/recompression cycle, thereby 
increasing the maximum number of simultaneous VoIP compressed flows that 
routers can handle. 

To implement header compression over multiple hops, the ingress 
router/gateway would have to apply the header compression to the IP 
packet, the compressed packet routed over multiple hops using MPLS 
labels, SCID switching, or some other method, and the compressed header 
would have to be decompressed at the egress router/gateway where the 
multiple hop VoIP header compression session terminates. A method is 
needed to set up a correspondence between the header compression tables 
at the ingress and egress of the multiple hop VoIP header compression 
session.

VoIP over MPLS (VoMPLS) header compression methods have been proposed 
earlier in the MPLS working group, however the relevant drafts have 
expired. George Swallow and Lou Berger proposed a 'simple' end-to-end 
compression scheme in which all first-order differences in the 
RTP/UDP/IP headers were transmitted, and in which the header compression 
context was established through RSVP signaling [RSVP, RSVP-TE]. 
Swallow's and Berger's 'simple' approach achieved about a 50 percent 
reduction in the size of the RTP/UDP/IP header. Thomas Theimer proposed 
an end-to-end header compression approach that would provide MPLS 
extensions for tunneling compressed headers over PPP links [TCRTP]. Lou 
Berger proposed MPLS-based extensions to 'hop-by-hop' header compression 
methods (e.g., [cRTP]), which could achieve about 90 percent reduction 
in the RTP/UDP/IP header. The MPLS Forum has since finalized an 
implementation/protocol for VoMPLS header compression [MPLSF-HC], 
however the technique does not provide means to interwork with IP.

This draft gives a problem statement, example scenarios, goals, and 
requirements for VoIP header compression from compressor to decompressor 
over multiple-hop paths, possibly over MPLS.  It also discusses work 
items and issues for consideration, and highlights various solution 
alternatives that have been proposed.  In Section 2 we give example 
scenarios, in Section 3 we give a problem statement, goals, and 
requirements, in Section 4 we discuss work items and issues for 
consideration, and in Appendix A we highlight various solution 
alternatives that have been proposed.

2. Example Scenarios

Scenario A:

Small customer sites with IP phones or VoIP terminal adapters connect to 
a CE routers serving as header compression gateways.  A VoIP session is 
established from CE1/HC --> PE1 --> P --> PE2 --> CE2/HD, where CE1/HC 
is the customer edge (CE) router where header compression (HC) is 
performed, and CE2/HD is the CE router where header decompression (HD) 
is done.  The voice traffic from CE1/HC to CE2/HD is typically small, on 
the order of only a few simultaneous calls in peak periods.  For 
example, cRTP compression of the RTP/UDP/IP header is performed at 
CE1/HD, and the compressed packets are routed from CE1/HC to PE1, P, 
PE2, and finally to CE2/HD, without further decompression/recompression 
cycles. The compressed packets might be routed using MPLS labels or 
perhaps use SCID switching to route the compressed packets from 
compressor CE1/HC to decompressor CE2/HD over the multiple hop path.  
The RTP/UDP/IP header is decompressed at CE2/HD and can be forwarded to 
other routers, as needed.

In the example scenario, cRTP header compression therefore takes place 
between the end-points, and in the case of an MPLS path, the MPLS path 
appears as a single link-layer to the compressor, even though it may 
traverse several routers. The MPLS path transports cRTP/MPLS-labels 
instead of RTP/UDP/IP/MPLS-labels, saving 36 octets per packet. The MPLS 
label stack and link-layer headers are not compressed. Additional 
signaling is needed to map the context for the compressed packets.

It is desirable that the packet loss rate between CE1/HC and CE2/HD not 
exceed 0.001, that packet delay variation not exceed 50 ms., and that 
packet transfer delay not exceed 400 ms.

Scenario B:

Many VoIP flows are originated from customer sites such as CE1/HC to 
several large customer call centers served by PE2, which include CE2/HD, 
CE3/HD, and CE4/HD.  It is essential that the PE2-CE2/HD, PE2-CE3/HD, 
and PE2-CE3/HD hops all use header compression to allow a maximum number 
of simultaneous VoIP flows.  To allow processing at PE2 to handle the 
volume of simultaneous VoIP flows, it is desired to use multi-hop header 
compression for these flows.  That is, with multi-hop header 
compression, PE2 does not need to do header compression/decompression 
for the flows to the call centers, enabling more scalability of the 
number of simultaneous VoIP flows with header compression at PE2.

3. Problem Statement, Goals, & Requirements

VoIP typically uses the encapsulation voice/RTP/UDP/IP/.  When MPLS 
labels are added, this becomes voice/RTP/UDP/IP/MPLS.  Typically, VoIP 
will use voice compression mechanisms (e.g., G.729) in order to conserve 
bandwidth.  For an MPLS VPN, the packet header is at least 48 bytes, 
while the compressed voice payload is typically no more than 30 bytes.  
With VoIP header compression, significantly more bandwidth could be 
saved.  Therefore, VoIP header compression from compressor to 
decompressor over multiple-hop paths, possibly over MPLS, is required in 
order to significantly reduce the VoIP overhead through compression 
mechanisms.

The goals of VoIP header compression over multiple-hop paths are as 
follows:

a. provide more efficient voice transport,
b. increase the scalability of VoIP header compression to a very large 
number of flows,
c. not significantly degrade packet delay, delay variation, or loss 
probability, and
d. allow efficient signaling of header context from compressor to 
decompressor.

The requirements for VoIP header compression from compressor to 
decompressor over multiple-hop paths, possibly over MPLS, are that it 
MUST:

a. allow VoIP header compression from compressor to decompressor over 
multiple-hop paths, possibly through an MPLS network, and thereby avoid 
hop-by-hop compression/decompression cycles ([E2E-VoMPLS], [E2E-cRTP]).
b. compress RTP/UDP/IP headers by at least 50%, to provide for efficient 
voice transport.
c. allow VoIP header compression over multiple-hop paths with delay not 
to exceed 400 ms. from compressor to decompressor [Y.1541, G.114].
d. allow VoIP header compression over multiple-hop paths with delay 
variation not to exceed 50 ms. from compressor to decompressor [Y.1541, 
G.114].
e. allow VoIP header compression over multiple-hop paths with packet 
loss not to exceed 0.001 from compressor to decompressor [Y.1541, 
G.114].
f. support various voice encoding supported by [RTP] (G.729, G.723.1, 
etc.).
g. be scalable to up to 20,000 simultaneous flows (e.g., PE/HC --> 
PE/HD).
h. use standard compress/decompress algorithms (e.g., [cRTP], [ECRTP], 
[ROHC]) to compress the RTP/UDP/IP headers.
i. allow use of standard protocols to make [cRTP] more tolerant of 
packet loss (e.g., [ECRTP]).
j. operate in non-MPLS networks (i.e., without use of MPLS labels).
k. operate in MPLS [MPLS-ARCH] networks, with use of MPLS labels, using 
either [LDP] or [RSVP] signaling.
l. operate in RFC2547 VPN context [MPLS-VPN].
m. allow use of standard protocols to signal context identification and 
control information (e.g., [RSVP], [RSVP-TE], [LDP]).
n. use standard protocols to aggregate RSVP-TE signaling (e.g., 
[RSVP-AGG]}.
o. allow use of standard protocols to prioritize packets (e.g., 
[DIFFSERV, DIFF-MPLS]).
p. allow use of standard protocols to allocate LSP bandwidth (e.g., 
[DS-TE]).

The solution space is discussed in Appendix A, and includes the 
well-established cRTP-based [cRTP] and enhanced cRTP [ECRTP] approaches, 
as specified in RFC 2508 and RFC 3545, respectively, 'Simple' header 
compression [SIMPLE] and the approaches described in [E2E-VoMPLS] and 
[E2E-cRTP]. 

4. Work Items & Issues

Based on the above requirements, there are several work items to be 
considered:

1. Extend cRTP to work from compressor to decompressor over multiple-hop 
paths with moderate delay (e.g., < 400 ms.) and moderate packet loss 
(e.g., < 2%).  We will assume enhanced cRTP [ECRTP] is sufficient for 
now.
2. How to directly route cRTP packets using SCID switching rather than 
doing a decompression/routing/compression cycle.  SCID switching is 
independent of MPLS, and a router can do this in isolation, without 
being observable by upstream or downstream routers.  It will look to 
cRTP as a 'link' with higher latency.
3. How to do ECRTP over an MPLS LSP, in which new RSVP signaling 
extensions are needed.  Here the compression between ingress-egress 
routers of an LSP can be viewed as the MPLS equivalent of RFC 2509
4. How SCID switching can be applied by the ingress router of a 
compressed MPLS LSP.  This in effect combines the outputs of work items 
2 and 3.

There are several issues to be considered within these work items:

1. protocol extensions for cRTP, RSVP-TE, RFC2547 VPNs
2. resynchronization & performance of cRTP/'simple' mechanisms
3. scalability of E2E VoMPLS applied CE-CE
4. LDP application as the underlying LSP signaling mechanism

Protocol extensions may be required for [cRTP] and [ECRTP] in that a 
packet type field is needed to identify FULL_HEADER, CONTEXT_STATE, etc. 
packets, and mechanisms are needed to create 'SCID routing tables' to 
allow routing based on the session context ID (SCID).  New objects need 
to be defined for [RSVP-TE], and extensions to RFC2547 VPNs are needed 
to allow SCID routing combined with label switching at PE's.  These 
protocol extensions need coordination with other working groups (MPLS, 
L3/2VPN, etc.).

Resynchronization and performance of VoIP header compression over 
multiple-hop paths needs to be considered.  cRTP header compression 
might not perform well with frequent resynchronizations, so standard 
protocols like [ECRTP] should be used to make cRTP more tolerant of 
packet loss.  The [SIMPLE] approach avoids the need for 
resynchronization, however cRTP achieves greater efficiency than 
'simple' (90% vs. 50% header compression), but requires 
resynchronization. [ECRTP] minimizes feedback based error recovery using 
CONTEXT_STATE packets to make cRTP more tolerant of packet loss, and 
minimize the need to use the cRTP error recovery mechanism. cRTP 
performs best with very low packet error rates on all hops of the path. 
Tunneling a cRTP session through multiple IP hops will increase the 
round trip delay and the chance of packet loss. cRTP contexts are 
invalidated due to packet loss. The cRTP error recovery mechanism using 
CONTEXT_STATE packets can compound the problem when long round trip 
delays are involved. When the cRTP decompressor context state gets out 
of synch with the compressor, it will drop packets associated with the 
context until the two states are resynchronized. To resynchronize 
context state at the two ends, the decompressor transmits the 
CONTEXT_STATE packet to the compressor, and the compressor transmits a 
FULL_HEADER packet to the decompressor. If the resynchronization were 
rare, then the basic cRTP approach would perform well for end-to-end 
header compression. Otherwise, ECRTP is desirable.

Scalability of VoIP header compression from compressor to decompressor 
over MPLS multiple-hop paths, needs to be considered when applied CE/HC 
to CE/HD.  This requires that LSPs be established with RSVP-TE between 
many CE pairs, raising possible scalability issues.  RSVP-TE has 
advantages in that it allows VoIP bandwidth assignment on LSPs and has 
QoS mechanisms.  But if applied CE/HC-CE/HD it may require a large 
number of LSPs to be created, and there is concern for CE, PE, and P 
ability to do the necessary processing.  This includes:

a. processing and label binding at every MPLS node on every path between 
each CE/HC-CE/HD pair,
b. processing every time resource reservation is modified (e.g., to 
adjust to varying number of calls on a CE/HC-CE/HD pair), and
c. core router load from thousands of LSPs, setup commands, refresh 
messages.

A final issue concerns LDP application as the underlying LSP signaling 
mechanism.  It is desirable to signal VoIP over MPLS tunnels with LDP, 
since many RFC2547 VPN implementations use LDP as underlying LSP 
signaling mechanism, and LDP is very scalable.  However, substantial 
extensions to LDP may be needed to signal VoIP over MPLS header 
compression over multiple-hop paths.  [LDP-PWE3] proposes ways for LDP 
to signal 'VC' (outer) labels for pseudo wires, and also suggests ways 
to do auto-discovery.  This together with LDP capability to distribute 
inner labels might support CE/HC-CE/HD VoIP header compression LSPs 
within the context of RFC 2547.  Also, [GVPLS] proposes LDP signaling 
for multipoint-to-point LSPs.  However, LDP provides no bandwidth 
associated with LSPs, and QoS mechanisms are limited.

5. Security Considerations

No new requirements.

6. References

[cRTP] Casner, S., Jacobsen, V., "Compressing IP/UDP/RTP Headers for 
Low-Speed Serial Links", RFC 2508, February 1999.

[DIFF-MPLS] Le Faucheur, F., et. al., "MPLS Support of Diff-Serv", RFC 
3270, May 2002.

[DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated 
Services", RFC 2475, December 1998.

[DS-TE] Le Faucheur, F., Lai, W., et. al., "Requirements for support of 
Diff-Serv-aware MPLS Traffic Engineering," RFC 3564, July 2003.

[E2E-VoMPLS] Ash, G., Goode, B., Hand, J., "End-to-End VoIP over MPLS 
Header Compression", work in progress.

[E2E-cRTP] Ash, G., Goode, B., Hand, J., "End-to-End VoIP Header 
Compression Using cRTP", work in progress.

[ECRTP] Koren, T., et. al., "Compressing IP/UDP/RTP Headers on Links 
with High Delay, Packet Loss, and Reordering," RFC 3545, July 2003.

[G.114] "One-way Transmission Time," January 2003.

[GVPLS] Radoaca, V., et. al., "GVPLS/LPE - Generalized VPLS Solution 
based on LPE Framework," work in progress.

[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement 
Levels", RFC 2119, March 1997.

[LDP] Andersson, L., et. al., "LDP Specification", RFC 3036, January 
2001.

[LDP-PWE3] Rosen, E., "LDP-based Signaling for L2VPNs", work in 
progress.

[MPLS-ARCH] Rosen, E., et. al., "Multiprotocol Label Switching 
Architecture," RFC 3031, January 2001.

[MPLS-VPN] Rosen, E., Rekhter, Y., "BGP/MPLS VPNs", RFC 2547, March 
1999.

[MPLSF-HC] MPLS Forum Technical Committee, "Voice over MPLS - 
BearerTransport Implementation Agreement,"  March 2001.

[ROHC] Bormann, C., et. al., "Robust Header Compression (ROHC)," RFC 
3091, July 2001.

[RSVP] Braden, R. et al., "Resource ReSerVation Protocol (RSVP) -- 
Version 1, Functional Specification", RFC 2205, September 1997.

[RSVP-AGG] Baker, F., et. al., "Aggregation of RSVP for IPv4 and IPv6 
Reservations", RFC 3175, September 2001.

[RSVP-TE] Awduche, D., et. al., "RSVP-TE: Extensions to RSVP for LSP 
Tunnels", RFC 3209, December 2001.

[RTP] Casner, S., et. al., "RTP: A Transport Protocol for Real-Time 
Applications," RFC 3550, July 2003.

[SIMPLE] Swallow, G., Berger, L., "Simple Header Compression", work in 
progress.

[TCRTP] Thompson, B., et. al., "Tunneling Multiplexed Compressed RTP 
("TCRTP")", work in progress.

[Y.1541] "Network performance objectives for IP-based services," 
December 2002.

7. Authors' Addresses

Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-4578
Email: gash@att.com

Bur Goode
AT&T
Phone: + 1 203-341-8705
E-mail: bgoode@att.com

Jim Hand
AT&T
Room MT A2-4F36
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1 732-420-6179
E-mail: jameshand@att.com

Raymond Zhang
Infonet Services Corporation
2160 E. Grand Ave. El Segundo, CA 90025 USA
Email: raymond_zhang@infonet.com

Appendix A - Summary of Proposed Solutions

The solution space includes the well-established cRTP-based [cRTP] and 
enhanced cRTP [ECRTP] approaches, as specified in RFC 2508 and RFC 3545, 
respectively.  These methods presently provide hop-by-hop header 
compression, and require resynchronization when packets are lost, but 
are very efficient providing about 90% header compression.

'Simple' header compression [SIMPLE] over multiple-hop MPLS paths 
transmits only first order differences, and as such resynchronization is 
not needed when packets are lost.  This approach achieves about 50% 
header compression, and was accepted by the MPLS working group for a 
charter extension at IETF-47, although the work was discontinued before 
the charter was extended.

The approach described in [E2E-VoMPLS] 'End-to-End VoIP over MPLS Header 
Compression', has the following steps:

1. use RSVP to establish LSPs between CE1/header compressor (HC) and 
CE2/header decompressor (HD)
2. use cRTP (or simple) to compress header at CE1/HC, decompress at 
CE2/HD
3. CE1/HC requests session context IDs (SCIDs) from CE2/HD
4. CE1/HC appends CE2/HD label to compressed header
5. header compression context routed from CE1/HC --> PE1 --> P --> PE2 
--> CE2/HD
6. route compressed packets with MPLS labels CE1/HC --> CE2/HD
7. packet decompressed at CE2/HD using cRTP (or simple) algorithm

The advantage of this approach is that it minimizes PE requirements, but 
has the disadvantage that CE's need to run RSVP, which is a possible 
scalability issue.  It also adds a label, which increases the header 
size by four bytes, thereby reducing the compression efficiency.

The approach described in [E2E-cRTP] 'End-to-End VoIP Header Compression 
Using cRTP' has the following steps:

1. use RSVP to establish LSPs between PE1-PE2
2. use cRTP to compress header at CE1/HC, decompress at CE2/HD
3. PE1 requests SCIDs from PE2
4. header compression context routed from CE1/HC --> PE1 --> P --> PE2 
--> CE2/HD
5. PE1 & PE2 create 'SCID routing tables' & perform 'SCID switching' for 
compressed packets (SCID --> MPLS labels)
6. route compressed packets with MPLS labels PE1 --> PE2
7. packet decompressed at CE2/HD using cRTP algorithm

The advantage of this approach is that it minimizes CE requirements and 
minimizes bandwidth requirements on the access links, but has the 
disadvantage that there are additional PE requirements, such as the need 
to create 'SCID routing tables'.

8. Full Copyright Statement

Copyright (C) The Internet Society (2003). 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   MERCHANTABILITY OR 
FITNESS FOR A PARTICULAR PURPOSE.