Please publish the following as an internet draft.
Network Working Group November 2001 Internet-Draft Expires: May 10, 2002 Abbie Barbir R. Penno Nortel Networks Delphine Kaplan Activia Data Compression For Content Network Advertisement Protocol (CNAPComp) draft-barbir-cdi-cnapcomp-00.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. This Internet-Draft will expire on October 30, 2001. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved. Abstract The draft specifies a data compression encapsulation protocol to be used to compress the data packets of the Content Network Advertisement Protocol (CNAP). The CNAP is a protocol intended to facilitate the interconnection of Content Networks. CNAP is a simple advertisement protocol that advertises both content (URLs) as well as content network coverage information. The CNAP protocol is described in . Barbir et al Expires May 10, 2002 [Page 1] Internet-Draft CNAP Data Compression Protocol May 2002 1. Introduction The Content Network Advertisement Protocol (CNAP) is designed to facilitate the interconnection of separately administered Content Networks [3-9]. The term, Content Network (CN), refers to a collection of network elements that assist in the location, delivery and usage tracking of content . The interconnection point between CNs is referred to as a Content Internetworking Gateway (CIG). Due to the amount of data that is associated with the CNAP protocol, there is a need to define data compression protocol that helps to reduce the amount of traffic that is transmitted on the links. Due to the repetitive nature of the advertisements in CNAP, it is possible for the data compression operation to achieve high compression ratios, thus reducing significantly the amount of data bytes that is communicated. In this regard, the data compression operation is performed on the whole CNAP messages. The data compression protocol (DCP) is basically an encapsulation protocol that compresses the traffic that is associated with CNAP. The negotiation of DCP is performed after the negotiation of the CNAP protocol has reached the Ready state. The negotiation is performed provided that the two entities that are initiating the CNAP protocol has expressed their willingness to support data compression operation. The DCP is based on LCP . The DCP protocol supports a default data compression protocol that must be supported by CNAP entities that agree to perform data compression. Furthermore, the DCP protocol provides support for propitiatory data compression operations that are vendor specific. The draft is organized as follows: Section 2 starts with a brief overview of the operation of CNAP. Section 3 introduces the data compression encapsulation protocol for CNAP. Section 4 discusses the security considerations. 1.1 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 . 2. Overview of Content Network Advertisement Protocol (CNAP) This section provides an overview of the CNAP protocol. The section briefly provides an overview, operation, and protocol specification for the Content Network Advertisement Protocol (CNAP). The primary function of the CNAP is to exchange content and reachability information as it relates to Content Networks. Reachability applies to both network reachability and content reachability. Barbir et al Expires May 10, 2002 [Page 2] Internet-Draft CNAP Data Compression Protocol May 2002 CNAP is a CN to CN protocol and makes use of TCP as a reliable transport protocol. CNAP uses TCP port number (TBD). Information exchanged between CNs using CNAP is communicated on a neighbor-by-neighbor basis. That is, a CIG may filter information based on policies configured by the CIG administrator. CNAP advertises information for the following purposes: - The readiness (or not) of a CN to serve content - How the authoritative CN should redirect requests to the CN. - The information required to make an informed request routing decision. The above information is advertised in two types of advertisements: - Content Advertisements: These advertisements are keyed on URLs that specify content. They specify the readiness to serve sets of content as well as the information required for request routing. - Area Advertisements: These advertisements specify information related to making an informed request routing decision. These are keyed on IP prefix/length pairs and contain metrics from a CN to those prefixes. The initial version of CNAP is based on DNS based Request-Routing systems. However, CNAP is extensible for other request routing types. The high-level protocol design and the connection state machine of CNAP are based on BGP-4. CNAP introduces the concept of a "Content AS", which is a single administrative CN. The Content AS is included in a number of CNAP protocol messages. 2.1 CNAP Connections CNAP connections are explicitly configured by an administrator. Before a CNAP session can be established the operators of the CIGs involved in a CNAP session must establish: - Local Content AS number for local CIG - Local CIG IP address - Neighbor Content AS number - Neighbor CIG IP address - Security credentials - And any advertisement filtering policies After this information has been configured either site MAY initiate a CNAP session by establishing a TCP connection and exchanging CNAP messages. A CNAP connection is fully established only when the connection enters the ESTABLISHED state. Barbir et al Expires May 10, 2002 [Page 3] Internet-Draft CNAP Data Compression Protocol May 2002 2.2 CNAP Messages and Formats CNAP is text-based, using ISO 10646 in UTF-8 encoding. Each CNAP message contains a small one-line header that includes the CNAP message type. Each message type has its own unique header. generic-message = start-line [message-header] CRLF message-header = ( open-header | notification-header | advertisement-header ) Header fields ("open-header", "notification-header", "advertisement-header") follow the same generic header format as that given in section 3.1 of RFC 822 [X]. Each header field consists of a name followed by a colon (":") and the field value. Field names are case-insensitive. The field value MAY be preceded by any amount of leading white space (LWS), though a single space (SP) is preferred. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). CIGs MUST follow HTTP "common form" when generating these constructs. Message-header = field-name ":" [field-value] CRLF Field-name = token Field-value = *(field-content|LWS) Field-content = <the OCTETs making up the field-value and consisting of either TEXT-UTF8 or combinations of token, separators and quoted string> Each CNAP message contains a small one-line header defined by: start-line = Method CRLF Each method corresponds to a CNAP message type. The Method token is case- sensitive. Method = "OPEN" | "NOTIFY" | "ADVERTISEMENT" | "KEEPALIVE" The following sections describe CNAP messages and the content of these messages. 2.2.1 OPEN The OPEN message is sent by each CIG in a CNAP session to initiate and establish the CNAP protocol connection. Each CIG sends an OPEN message as soon as the TCP connection is established. An OPEN message contains an open-header: Barbir et al Expires May 10, 2002 [Page 4] Internet-Draft CNAP Data Compression Protocol May 2002 open-header = Protocol-Version | Node-ID | Content-AS | Holdtime | Distrib-Levels | RRS-Types where, - Protocol-Version: CNAP protocol version number running on the CIG gateway. - Node-ID: The Node ID is unique IP address of the CIG. - Content-AS: The Content Autonomous System uniquely identifies this Content Network. Each CN is assigned a content AS number. - Holdtime: Keepalives expected in this interval. - Distrib-Levels: Number of levels supported for request routing for this CN. - RRS-Types: list of RRS types supported by this CN. - Capabilities: list of optional capabilities supported by the CN. 2.2.2 KEEPALIVE KEEPALIVE messages are sent according to the period specified for HOLDTIME in the OPEN message. No parameters are supported for KEEPALIVE messages. KEEPALIVE messages are used to acknowledge OPEN messages. After a CIG receives a KEEPALIVE in response to its OPEN, it enters the ESTABLISHED state assuming that its neighbor is ready to begin receiving advertisements. A KEEPALIVE message contains no specific method header. 2.2.3 NOTIFY NOTIFY messages are sent to indicate an error has occurred. The sender will move to the Idle state immediately after sending the NOTIFY message. notify-header = Error-Code | Error-Subcode | Error-Data - Error-Code: Error code indicates the type of notification. - Error-Subcode: Sub-code within a given error code type. If no specific subcode applies, the subcode should be set to zero. - Error-Data: additional information regarding the error. In  the currently defined error-codes and error sub-codes are provided. Barbir et al Expires May 10, 2002 [Page 5] Internet-Draft CNAP Data Compression Protocol May 2002 2.2.4 ADVERTISEMENT In CNAP ADVERTISEMENT messages contains the actual content and CN information; ADVERTISEMENTs are used to both advertise positive status as well as to withdraw information. Content and Area ADVERTISEMENTs are "linked" through RegionIDs. A RegionID is a 16-bit unsigned integer assigned to one or more IP prefixes. If a Content Network ADVERTISMENT contains RegionIDs, it means "this content is available in these areas with these RegionIDs". advertisement-header = Advertisement-Type | Authoritative-CN | CN-Path | (area-header | content-header), where, - Advertisement-Type: This specifies the type of advertisement. - Authoritative-CN: the CONTENTAS number of the CN authoritative for the - CONTENT or AREA being advertised in this message. - CN-Path: attribute that is composed of a sequence of CONTENTAS numbers. An "area" advertisement includes an area-header that is a list of areas (and their metrics) being advertised. A "content" advertisement includes a content- header that is a list of content (and its metrics) being advertised. In , the details of each of the advertisement types are provided. 2.2.6 CNAP Finite State Machine In CNAP the states of the protocol are defined on a per peer basis, where a peer is a Content Internetworking Gateway. 184.108.40.206 State Table In CNAP the following states are defined. - Init - No connection established. - OpenSent - An OPEN message has been sent. - OpenConfirm - OPEN messages exchanged; confirmation required. - Ready - Session is established. The following defines the state table. For each state, the messages which are valid in that state are listed. The "Next State After Success" column indicates the state entered after the message indicated in "Message Sent" is sent. If a message not specified for the state is received, the receiver will move to the Idle state, with the following exceptions: Barbir et al Expires May 10, 2002 [Page 6] Internet-Draft CNAP Data Compression Protocol May 2002 - A NOTIFY message is always followed by the sender moving to the Idle state. - AREA, CONTENT messages may only be sent in the Ready state and do not cause a state change. The OPEN sent in the Idle state MUST be sent by the initiator or the TCP connection between the CIG peers. The OPEN sent in the OpenSent state MUST be sent by the receiver of the initial OPEN message. State Message Sent Next State After Success --------- ------------ ------------------------- Idle OPEN (initiator) OpenSent OpenSent OPEN OpenConfirm OpenConfirm KEEPALIVE Ready Ready KEEPALIVE Ready To move to the Idle state from any other state, the socket connection associated with this peer will be terminated. Data collected from AREA and CONTENT advertisements is retained only as long as the session is maintained. When a session moves to Idle state, the CIG must update it's AREA and CONTENT tables. This is accomplished by ensuring that for all AREA data received from a disconnected peer, AREA Status: Withdraw messages will be sent on remaining CNAP connections, and paths represented by the associated AREAs will be deleted from local tables. 3. CNAP Data Compression Protocol Due to the amount of data that is associated with the CNAP protocol, there may be a need to perform data compression. This section introduces the data compression protocol (DCP) that could be used to compress CNAP traffic. In this regard, data compression is performed on the whole CNAP messages. The data compression (DCP) is basically an encapsulation protocol that compresses the traffic that is associated with CNAP. The DCP uses some concepts from LCP  and Data Compression over Frame Relay . The DCP protocol supports a default data compression protocol that must be supported by CNAP entities that agree to perform data compression. Furthermore, the DCP protocol provides support for proprietary data compression operations that are vendor specific . 3.1 Data Compression negotiations CNAP will support the negotiation of multiple data compression algorithms. The default data compression algorithm at this time is Hi/Fn LZS . Provisions may be made in the future to support other data compression protocols. The protocol also supports the negotiation of proprietary data compression algorithms. Barbir et al Expires May 10, 2002 [Page 7] Internet-Draft CNAP Data Compression Protocol May 2002 The negotiation of data compression is performed after the CNAP protocol has reached the Established State. 3.2 CNAP Data Compression Protocol This section discusses the data compression protocol that will be used to encapsulate the CNAP messages. The data compression Protocol (DCP) allows for control Payload Data Units (CPDU) and Data Compression Payload Data Units (DPDU). The CPDU allows for the possibility of changing the compression parameters during an active session. 3.2.1 DCP Control Operation The control portion of DCP is used to enable, disable, and optionally configure DCP. The control portion of the protocol can be used to negotiate the appropriate data compression algorithm and its associated parameters. The format of the Control Payload Data Units (CPDU) is given below: +-----------------+ | TCP Frame | | . | | . | +-----------------+ | NLPID | +-----------------+ | Data Compression| | Protocol Header | | (DCPH) | +-----------------+ | Control | | Primitives | |(0 to n octets) | +-----------------+ | . | | end of TCP | | Frame | +-----------------+ Figure 1. Control PDU Frame Format A description of the DCP encapsulation frame from Figure 1 is given next. 1. NLPID The NLPID is the Network Level Protocol Identifier . This is a one-byte identifier that has the value 0x???? (TBD). Editor Note: This field may not be needed. Barbir et al Expires May 10, 2002 [Page 8] Internet-Draft CNAP Data Compression Protocol May 2002 2. Data Compression Protocol Header (DCPH) A DCP data PDU encapsulates compressed or uncompressed CNAP messages for transport to the peer CIG. One CNAP data PDU (message) is mapped into one compressed frame using DCP. The maximum size of the DCP frame is dependent on the maximum size of a CNAP PDU. In some cases, data expansion may occur, this will leads to DCP frames that are larger in size than the original CNAP PDU. The DCPH is one-byte in length. The format of the DCPH is given below: +------------------------------------+ |8 | 7 | 6 | 5 | 4 3 2 | 1 | -------------------------------------- |E | C/U | R-A | R-R | Reserved | C/D| +------------------------------------+ E 0 for extension 1 for no extension C/U 0 for uncompressed mode 1 for compressed mode R-A 0 for no reset acknowledge 1 for reset acknowledge R-R 0 for no reset request 1 for reset request Reserved for future use. Set to 0. C/D 0 for DCP data PDU's The description of the bits in the header is given next. 1. E is the extension bit and is used to indicate any future extensions to DCP into multiple header bytes. It should be set to 0 for now. 2. C/U indicates if the payload is compressed or not 3. R-A and R-R bits are used for compression history synchronization. 4. C/D indicates whether the frame is a control or data frame. 3.2.2 DCP Data Compression Operation The DCP allows for the transmission of data in compressed or uncompressed fashion. The DCP is a protocol that encapsulates the original raw messages from CNAP into a protocol that allows for data compression. In DCP the payload is encapsulated as in Figure2. Barbir et al Expires May 10, 2002 [Page 9] Internet-Draft CNAP Data Compression Protocol May 2002 +-----------------+ | TCP Frame | | . | | . | +-----------------+ | NLPID | +-----------------+ | Data Compression| | Protocol Header | | (DCPH) | +-----------------+ | Compressed | | Payload | | . | +-----------------+ | LCB | +-----------------+ | Length | +-----------------+ | . | | end of TCP | | Frame | +-----------------+ Figure 2. Data Compression Protocol Frame Format The NLPID and DCPH have been defined in an earlier section. The rest of the fields in the frame are defined next. 1. Compressed Payload This is the compressed data from the CNAP protocol. 2. LCB The LCB octet is the Exclusive-OR of FF (hex) and each octet of the uncompressed CNAP PDU prior to the compression transformation. On receipt, the receiver shall compute the Exclusive-OR of FF (hex) and each octet of the decoded data. If this value does not match the received LCB in the DCP data PDU, then a receive failure for that frame has occurred. An error message must be sent to the sender and the connection may be closed or a request for history resynchronization may be sent using control DCP. 3. Length This is a two-byte field that specifies the length of the DCP payload including the NLPID and the two Length bytes. Barbir et al Expires May 10, 2002 [Page 10] Internet-Draft CNAP Data Compression Protocol May 2002 3.3 DCP Operations This section describes the negotiation, setup and various capabilities that the DCP support. 3.3.1 Modes of operation The DCP supports two modes of operations, Mode-1 and Mode-2. Mode-1 provides a simple negotiation protocol to enable DCP with the default parameter values as specified in subsequent sections. Mode-2 allows the CIG's to negotiate a vendor specific data compression algorithm. It also allow for the re-negotiation of specific set of parameters that need to be supported during the data compression session. The negotiation of Mode-1 or Mode-2 is performed after CNAP reaches the Established stage. The next subsections details the CDCP frame format and how it is used for negotiating the operation mode. 220.127.116.11 Control DCP Mode Negotiation The Control DCP (CDCP) supports two modes of data compression operations. The DCP mode of operation is negotiated using the CDCP frames. Here the C/D bit is set to 1. These frames are used to negotiate compression at the beginning of a CNAP session and can also be used within an active session. The format of CDCP frame is based on LCP  and is depicted below: +-----------------+ |Data Compression | | Protocol Header| | (DCPH) | +-----------------+ +-->| Code | | +-----------------+ Mode-1 Request/ -->| | Identifier | Response | +-----------------+ +-->| Length | +-----------------+ +-->| Type | | +-----------------+ Configuration -->| | Length | Options | +-----------------+ +-->| Revision | +-----------------+ Figure 3 CDCP Frame Format Barbir et al Expires May 10, 2002 [Page 11] Internet-Draft CNAP Data Compression Protocol May 2002 18.104.22.168 Mode-1 Parameters Mode-1 is the default data compression mode. Here, any CIG can issue a Mode-1 request and then expects a reply from the peer to the request. The fields in the CDCP are populated as follows: - Mode-1 Request Parameters - Code: one octet in length set to 0. - Identifier: one octet in length set to 0 - Length: one octet in length set to 7 - Mode-1 Response Parameters - Code: one octet in length set to 1. - Identifier: one octet in length set to 0 - Length: one octet in length set to 7 - Mode-1 Configuration Options Parameters - Type: one octet in length set to decimal 254 (LZS as defined in ) - Length: one octet in length set to decimal 3 - Revision: one octet in length set to decimal 1 22.214.171.124 Mode-2 Parameters Mode-2 supports the negotiation of proprietary data compression algorithms. Mode-2 uses the Organization Unique Identifier (OUI) to identify the proprietary data compression algorithm that is associated within an organization. The general format of CDCP for mode-2 operation is depicted in Figure 4. +-----------------+ |Data Compression | | Protocol Header| | (DCPH) | +-----------------+ +-->| Code | | +-----------------+ Mode-1 Request/ -->| | Identifier | Response | +-----------------+ +-->| Length | +-----------------+ +-->| Type | | +-----------------+ Configuration -->| | Length | Options | +-----------------+ | | OUI | | +-----------------+ | | Subtype | | +-----------------+ | | Values | +-->+-----------------+ Figure 4. CDCP Mode-2 Frame Format Barbir et al Expires May 10, 2002 [Page 12] Internet-Draft CNAP Data Compression Protocol May 2002 - Mode-2 Request Parameters - Code: one octet in length set to 0. - Identifier: one octet in length set to 0 - Length: one octet in length set to 7 - Mode-2 Response Parameters - Code: one octet in length set to 1. - Identifier: one octet in length set to 0 - Length: one octet in length set to 7 - Mode-2 Configuration Options Parameters - Type: one octet in length set to decimal 0 for OUI - Length: one octet in length set to the number of octets in the Values field plus 6. - OUI: three octets in length and is the vendor's IEEE Organization Unique Identifier (OUI) assigned to the vendor by IEEE 802 . This identifies the option as being proprietary to the indicated vendor. The bits within the octet are in canonical order, and the most significant octet is sent first. - Subtype: one octet in length and is specific to each OUI. The purpose of this field is to select between multiple proprietary compression algorithms under the vendor's OUI. Each OUI implements its own values. - Values: The Values field shall be zero or more octets, and contains additional data as determined by the vendor's compression protocol. 3.3.2 DCP Finite State Machine DCPCP Mode-1 consists of three phases: Disabled, DCP-Init, and Operation. The Disabled phase is entered when CNAP has not reaches the Established state. The DCP-Init phase is entered after CNAP reaches the Established state and assuming that compression is on both peered CIG's capabilities list. The Operation phase is entered upon the successful completion of the DCP-Init phase. Unsuccessful completion of the DCP-Init phase causes DCP to enter the Disabled Phase. DCP data PDUs are transferred only when Mode-1 is in the Operation phase. However, DCP control PDUs may be transferred in any phase. The Mode-1 DCP-Init phase shall be entered when the CNAP CIG initiate or send a request for DCP negotiation or receives a request for DCP from the remote CIG peer. When the Mode-1 DCP-Init phase is entered, a handshake procedure must be initiated. Each time the handshake procedure is initiated, it must operate as follows: Barbir et al Expires May 10, 2002 [Page 13] Internet-Draft CNAP Data Compression Protocol May 2002 At the beginning, the initiating CIG send a Mode-1 Request to its peer. Next, it starts a handshake completion timer to expire P-Time seconds after the Mode-1 Request was sent. The CIG that receives a Mode-1 Request must send a Mode-1 Response. When a Mode-1 Response has been both sent and received, the handshake procedure is complete and DCP enters the Mode-1 Operation phase. If the handshake completion timer expires before the handshake procedure is completed, the handshake procedure must be re-initiated. If the handshake procedure is re- initiated P-Count times without leaving the Mode-1 DCP-Init phase, the CIG shall terminate the handshake procedure and enter the Disabled phase. Editor Note: Here, we can either proceed with no data compression or the connection would be closed (CNAP is down). The Mode-1 Disabled phase must be entered when a CNAP session is released. While in the Mode-1 Operation phase, if a Mode-1 Request is received, the entity shall terminate transfer of DCP data PDUs and enter the Mode-1 DCP-Init phase. Mode-1 phase transitions are shown in Table 1. +----------------------------------------------------+ | CNAP\DCP | Disabled | DCP-Init | Operation | +----------------------------------------------------+ |Init |Disabled | Disabled | Disabled | |----------------------------------------------------| |OpenSent |Disabled | Disabled | Disabled | |----------------------------------------------------| |OpenConfirm |Disabled | Disabled | Disabled | |----------------------------------------------------| |Ready |DCP-Init | DCP-Init | DCP-Init | |----------------------------------------------------| |Mode-1 | DCP-Init | DCP-Init | DCP-Init | |Request | | | | |----------------------------------------------------| |Handshake | N/A |Operational | N/A | |Complete | | | | |----------------------------------------------------| |Handshake | N/A | Disabled | N/A | |Failed | | | | +----------------------------------------------------+ Table 1. Mode-1 State Transition Table Mode-2 negotiation must use the finite-state automaton described in sections 3 and 4 of RFC 1661  with the following exceptions: - If the Mode-2 negotiate finite-state automaton enters the Closed state because of negotiation time out (P-Revert-Time seconds), the entity must enter the Mode-1 Initialization phase. Barbir et al Expires May 10, 2002 [Page 14] Internet-Draft CNAP Data Compression Protocol May 2002 - An entity may abandon Mode-2 and enter the Mode-1 initialization phase at any time. - If an entity operating in Mode-2 receives a Mode-1 Request at any time, it must enter the Mode-1 Initialization phase. - If an entity that supports Mode-2 is currently in Mode-1 and it receives a Mode-2 Configure-Request, it must begin Mode-2 negotiation. Note: The value of P-Revert-Time counter must be set to a minimum of 30 seconds. The Value of P-Count must be set to ? (TBD). The Value of P-Time must be set to ? (TBD). 4. Security Considerations The IPSEC architecture  defines security services at the IP level which can be used by any higher layer protocol. CNAP requires the ability to authenticate the session participants and to ensure the confidentiality of messages. These services are provided through use of IPSEC's Authentication Header (AH) and Encapsulating Security Payload (ESP), respectively. Because IPSEC targets providing services to security-unaware applications, CNAP requires only a mechanism to indicate to a peer that certain security services are required. References  Bradner, S.O., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996.  Bradner, S.O., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.  Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CDN Peering Architectural Overview", January 2001.  Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", January 2001.  Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", January 2001.  Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request Routing Requirements for Content Internetworking", January 2001.  Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Accounting Requirements for CDN Internetworking", January 2001. Barbir et al Expires May 10, 2002 [Page 15] Internet-Draft CNAP Data Compression Protocol May 2002  Amini, L., Spatscheck, O. and S. Thomas, "Distribution Requirements for Content Delivery Internetworking", January 2001.  Day, M., Cain, B. and G. Tomlinson, "A Model for Content Distribution Internetworking", January 2001.  Day, M., Cain, B. and G. Tomlinson, "Content Distribution Network Peering Scenarios", January 2001.  Kent, S., Atkinson, R. and G. Tomlinson, "Security Architecture for the Internet Protocol", January 2001.  ANSI X3.241-1994 Data Compression Method - adaptive coding with sliding window for information interchange.  RFC1661 - The Point-to-Point Protocol (PPP).  TIA/EIA 655 - Support for Terminal Adaption and Data Compression in Data Circuit- Terminating Equipment (DCE) with provisions for negotiation of parameters.  Cain et al, "Content Advertisement Protocol", November 2001.  Data Compression Over Frame Relay, FRF.9, January 1996. Author's Address Abbie Barbir Nortel Networks 3500 Carling Avenue Nepean, Ontario K2H 8E9 Canada Phone: +1 613 763 5229 email: email@example.com Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 San Jose, CA 95134 Email: firstname.lastname@example.org Delphine Kaplan ActiVia Networks Space Antipolis 5 Parc de Sophia Antipolis 2323 Chemin St Bernard 06225 Vallauris, Cedex FRANCE Phone: +33 4 97 23 46 66 email: Delphine.Kaplan@activia.net URI: http://www.activia.net/ Barbir et al Expires May 10, 2002 [Page 16] Internet-Draft CNAP Data Compression Protocol May 2002 Full Copyright Statement Copyright (C) The Internet Society (2001). 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. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society.