Network Working Group February 2002 Internet-Draft Expires: August 19, 2002 Abbie Barbir R. Penno Nortel Networks Delphine Kaplan Activia Data Compression For Content Network Advertisement Protocol (CNAPComp) 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 August 19, 2002. 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 content as well as content network coverage information. The CNAP protocol is described in [15]. Barbir et al Expires August 19, 2002 [Page 1] Internet-Draft CNAP Data Compression Protocol February 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 [9]. 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 significantly reducing the amount of data that is communicated. In this regard, the document specifies procedures for performing Data Compression for CNAP [15]. The scope of this document covers the negotiation and encapsulation of data compression over CNAP [15]. 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 [13]. The DCP protocol uses 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. The draft is organized as follows: Section 2 discusses acronyms and provides basic data compression definitions. Section 3 provides a brief overview of CNAP. Section 4 discusses the data compression protocol. Section 5 focuses on the operations of the data compression protocol. Section 6 covers the Finite State Machine and section 7 discusses 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]. Barbir et al Expires August 19, 2002 [Page 2] Internet-Draft CNAP Data Compression Protocol February 2002 2. Acronyms and Definitions 2.1 Acronyms Ack Acknowledgment ANSI American National Standards Institute Mode-1 Default Data Compression Mode 1 Mode-2 Vendor specific data compression algorithm C/D Control/data C/U Compressed/uncompressed DCP Data Compression Protocol DCPCP DCP Control Protocol Ext. Extension Bit IEEE Institute for Electrical and Electronic Engineering ISO/IEC International Standardization Organization LCB Longitudinal Check Byte LCP Link Control Protocol LZS Data Compression Algorithm OUI Organization Unique Identifier PDU Protocol Data Unit R-A Reset acknowledge XOR Boolean Exclusive OR 2.2 Definitions 1. Anti-expansion: A means to inhibit the expansion of user data due to compression encoding. 2. Data Compression Function: An entity that performs the data compression encoding, decoding, error detection, synchronization, and negotiation. 3. Decoder: An entity that decompresses user data. 4. Encoder: An entity that compresses user data. 5. 0x stands for hexadecimal numbers. 6. Longitudinal check byte (LCB): The LCB is calculated for each frame by - Exclusive ORing 0xFF to the first octet of the payload and storing the result. Then, - Each subsequent octet of the payload is XORed to the result generating the next value of the result. 3. A Brief Overview of 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 August 19, 2002 [Page 3] Internet-Draft CNAP Data Compression Protocol February 2002 CNAP is a CN to CN protocol and makes use of TCP as a reliable transport protocol. 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. An administrator explicitly configures CNAP connections. After the configuration step is performed a 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 Ready state [15]. In CNAP the states of the protocol are defined on a per peer basis, where a peer is a Content Internetworking Gateway (CIG). 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 CNAP. 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. Barbir et al Expires August 19, 2002 [Page 4] Internet-Draft CNAP Data Compression Protocol February 2002 State Message Sent Next State After Success --------- ------------ ------------------------- Idle OPEN (initiator) OpenSent OpenSent OPEN OpenConfirm OpenConfirm KEEPALIVE Ready Ready KEEPALIVE Ready 4. 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 based on LCP [13]. The DCP protocol uses a default data compression mode of operation 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. The DCP control protocol provides the following services for data compression: 1. Encapsulation of encoded CNAP messages and negotiation primitives within Protocol data units (PDU's) for transport between CIG peers. 2. Negotiation of DCP configuration options. 3. Synchronization of the sender and receiver peers, including: - Detection of loss of synchronization and signaling for resynchronization between peers. 4. The ability of signaling compressed/uncompressed mode from the encoder to the peer decoder. 5. Encoding of user data into compressed user data according to a default data compression algorithm or proprietary algorithms. 4.1 DCP General Frame Format The general frame structure of DCP supports the encapsulation of control information or the transfer of data. Control frames contain the information that is vital to negotiating the data compression facilities and their associated parameters. The C/D bit in the Data Compression Protocol Header (DCPH) distinguishes between control and data frames. For control frames, the C/D bit is set to 1. The general DCP frame format is given in Figure 1. Barbir et al Expires August 19, 2002 [Page 5] Internet-Draft CNAP Data Compression Protocol February 2002 +-----------------+ | TCP Frame | +->+-----------------+ | | Header | | +-----------------+ Data | | Control | Compression | | Primitives | Protocol | | or | | | Compressed | | | Data | +->+-----------------+ Figure 1. DCP General Frame Format 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. 4.2 DCP Control Operation This section discusses the data compression protocol that will be used to encapsulate the CNAP messages. CNAP data compression protocol (DCP) will support the negotiation of multiple data compression algorithms. The default data compression algorithm at this time is Hi/Fn LZS [12]. Provisions may be made in the future to support other data compression protocols. The protocol also supports the negotiation of proprietary data compression algorithms. The negotiation of data compression is performed after the CNAP protocol has reached the Ready State. 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 in Figure 2. +-----------------+ | Data Compression| | Protocol Header | | (DCPH) | +-----------------+ | Control | | Primitives | |(0 to n octets) | +-----------------+ Figure 2. DCP Control PDU Frame Format A description of the DCP encapsulation frame from Figure 2 is given next. Barbir et al Expires August 19, 2002 [Page 6] Internet-Draft CNAP Data Compression Protocol February 2002 1. 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. 4.3 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 Figure 3. Barbir et al Expires August 19, 2002 [Page 7] Internet-Draft CNAP Data Compression Protocol February 2002 +-----------------+ | Data Compression| | Protocol Header | | (DCPH) | +-----------------+ | Compressed | | Payload | | . | +-----------------+ | LCB | +-----------------+ | Length | +-----------------+ Figure 3. Data Compression Protocol Frame Format The DCPH has 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 two Length bytes. 5. DCP Operations This section describes the negotiation, setup and various capabilities that the DCP support. Barbir et al Expires August 19, 2002 [Page 8] Internet-Draft CNAP Data Compression Protocol February 2002 5.1 Modes of operation The DCP supports two modes of operations, Mode-1 and Mode-2. For implementations to be compliant with this document, the support of Mode-1 is mandatory. The Mode-1 data compression operation consists of a simple handshake to enable the default data compression algorithm and its parameters for both directions of the TCP connection. The default data compression algorithm is the ANSI X3.241-1994 (LZS) as described in [12]. 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 Ready stage. The next subsections detail the CDCP frame format and how it is used for negotiating the operation mode. 5.1.1 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 [13] and is depicted below: +-----------------+ |Data Compression | | Protocol Header| | (DCPH) | +-----------------+ +-->| Code | | +-----------------+ Mode-1 Request/ -->| | Identifier | Response | +-----------------+ +-->| Length | +-----------------+ +-->| Type | | +-----------------+ Configuration -->| | Length | Options | +-----------------+ +-->| Revision | +-----------------+ Figure 4. CDCP Frame Format Barbir et al Expires August 19, 2002 [Page 9] Internet-Draft CNAP Data Compression Protocol February 2002 5.1.1.1 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 are based on LCP [13] and are populated as follows: 5.1.1.1.1 Mode-1 Request Parameters Code: The Code field is one octet in length. It identifies the kind of the packet. For Mode-1 configure request, the Code must be set to decimal 1. Identifier: The Identifier field is one octet in length, and aids in matching requests and replies. When a packet is received with an invalid Identifier field, the packet must be silently discarded. Length: The Length field is two octets, and indicates the length of the DCP packet, including the Code, Identifier, Length and Configuration Options field. 5.1.1.2 Mode-1 Response Parameters Code: The Code field is one octet in length. It identifies the kind of the packet. For Mode-1 configure Ack, the Code must be set to decimal 2. Identifier: The Identifier field is one octet in length, and aids in matching requests and replies. It must be set to match the Identifier field in the configure request packet. Length: The Length field is two octets, and indicates the length of the DCP packet, including the Code, Identifier, Length and Configuration Options field. 5.1.1.3 Mode-1 Configuration Options Parameters Type: The Code field is one octet in length set to decimal 254 (LZS as defined in [12]) Length: The Length field one octet in length set to decimal 3. Revision: This field is one octet in length set to decimal 1. 5.1.2 Mode-2 Parameters Mode-2 supports the negotiation of proprietary data compression algorithms. Mode-2 uses the Organization Unique Identifier (OUI)[14] 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 5. Barbir et al Expires August 19, 2002 [Page 10] Internet-Draft CNAP Data Compression Protocol February 2002 +-----------------+ |Data Compression | | Protocol Header| | (DCPH) | +-----------------+ +-->| Code | | +-----------------+ Mode-1 Request/ -->| | Identifier | Response | +-----------------+ +-->| Length | +-----------------+ +-->| Type | | +-----------------+ Configuration -->| | Length | Options | +-----------------+ | | OUI | | +-----------------+ | | Subtype | | +-----------------+ | | Values | +-->+-----------------+ Figure 5. CDCP Mode-2 Frame Format The DCP Mode-2 allows the negotiation of vendor specific data compression protocols. The negotiation is based on the LCP packet formats defined in section 5 of RFC 1661 [13], with a unique set of Configurations options. The LCP packets with codes 1 through 7 are required. The other LCP packets specified in RFC 1661 are optional. The Configuration Option code points are currently assigned to match up with those of TIA/EIA 655 [14]. Current values used for DCP are assigned as follows: Configuration Option 23 reserved for future use. 254 DCP Mode-1. 255 reserved for future use. Mode-2 shall use the finite-state automaton described in sections 3 and 4 of RFC 1661 [13] and as detailed in a subsection section of this document. 5.1.2.1 Mode-2 Request Parameters Code: The Code field is one octet in length. It identifies the kind of the packet. For Mode-1 configure request, the Code must be set to decimal 1. Barbir et al Expires August 19, 2002 [Page 11] Internet-Draft CNAP Data Compression Protocol February 2002 Identifier: The Identifier field is one octet in length, and aids in matching requests and replies. When a packet is received with an invalid Identifier field, the packet must be silently discarded. Length: The Length field is two octets, and indicates the length of the DCP packet, including the Code, Identifier, Length and Configuration Options field. 5.1.2.2 Mode-2 Response Parameters Code: The Code field is one octet in length. It identifies the kind of the packet. For Mode-1 configure Ack, the Code must be set to decimal 2. Identifier: The Identifier field is one octet in length, and aids in matching requests and replies. It must be set to match the Identifier field in the configure request packet. Length: The Length field is two octets, and indicates the length of the DCP packet, including the Code, Identifier, Length and Configuration Options field. 5.1.2.3 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 [14]. 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. 5.2 Data Compression Signaling Procedures This section describes the anti-expansion and synchronization procedures that are used with the DCP. During the data transfer mode of operation the C/D bit in the DCHP field is set to 0 to indicate that the frame is a data frame. In this case, the C/U, RA and RR bits are used for signaling uncompressed data and performing synchronization procedures. Barbir et al Expires August 19, 2002 [Page 12] Internet-Draft CNAP Data Compression Protocol February 2002 5.2.1 Uncompressed Signaling Format The Data compression operation is compute intensive. In some cases, the encoding end may need to stop the data compression operation in order to free CPU resources. In this case, the DCP protocol provides the encoding end the option of sending data in uncompressed fashion. This can be achieved by setting the C/U to Zero. 5.2.2 Synchronization Signaling Format The DCP provides synchronization procedures to recover from a loss of synchronization between CIG peers. In this document, the LCB is used to detect the loss of synchronization. Synchronization signaling is provided between DCP peers via the RR and RA bits in the DCPH header field. The RR and RA may be signaled in a DCP Header that accompanies a DCP Payload. Additionally, they may also be signaled via a DCP Header without an attached DCP Payload. Separate RR and RA signals are provided to allow independent resynchronization of either or both directions of the connection. The decoder determines the loss of synchronization when it receives a frame with a wrong LCB. If the decoder detects a loss of synchronization in the remote-to- local direction of the DCP connection, it must generate an RR signal that is set to "1", on a new empty DCP data PDU or on the next DCP data PDU containing user data destined for the remote CIG peer. Once an RR set to "1" has been generated, any DCP data PDU's received in the remote-to-local direction of that DCP context that contain compressed user data (C/U=1) must be discarded until an RA set to "1" is received for that context. If a receiver detects an RR set to "1" in the remote-to-local direction, it shall reset its encoder to a known state. The encoder must generate an RA signal set to "1" on a new empty DCP data PDU or on the next DCP data PDU containing user data destined for the local DCP peer. When a local DCP receiver receives an RA signal set to "1" in the remote-to-local direction of the DCP context, it must reset its history for that context to a known state. The local DCP receiver must decode any user data in the DCP data PDU containing the RA set to "1" and all subsequent DCP data PDUs until another loss of synchronization is detected. The C/U bit must be set to "0" in DCP synchronization frames (when the RR or RA bits are set). In order to ensure initial that synchronization is achieved between two peers upon the successful negotiation of data compression. The encoder must set the RA bit to "1" on the first PDU to indicate that the history is in a known state. The decoder must ignore all compressed frames until it gets such a frame. To increase reliability, the decoder must initiate a reset request to the remote encoder. Barbir et al Expires August 19, 2002 [Page 13] Internet-Draft CNAP Data Compression Protocol February 2002 6. DCP Finite State Machine This section discusses the finite state machine of the DCP protocol. In order to simplify the negotiation process, the document derives a simple handshake procedure that is used to negotiate Mode-1. The negotiation of Mode-2 is more complex and requires the support of the procedures that are related to LCP as discussed in [13]. 6.1 Mode-1 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 Ready state. The DCP-Init phase is entered after CNAP reaches the Ready 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: 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. 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. Barbir et al Expires August 19, 2002 [Page 14] Internet-Draft CNAP Data Compression Protocol February 2002 +----------------------------------------------------+ | 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 6.1.2 Mode-2 DCP Finite State Machine Mode-2 negotiation must use the finite-state automaton described in sections 3 and 4 of RFC 1661 [13] with the following exceptions: 1. 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. 2. An entity may abandon Mode-2 and enter the Mode-1 initialization phase at any time. 3. If an entity operating in Mode-2 receives a Mode-1 Request at any time, it must enter the Mode-1 Initialization phase. 4. 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. Barbir et al Expires August 19, 2002 [Page 15] Internet-Draft CNAP Data Compression Protocol February 2002 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). 7. Security Considerations The IPSEC architecture [11] 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. 8. Acknowledgements The authors would like to thank Joseph Hui, Nalin Mistry and Wayne Ding for their valuable feedback. References [1] Bradner, S.O., "The Internet Standards Process -- Revision 3", RFC 2026, BCP 9, October 1996. [2] Bradner, S.O., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997. [3] Green, M., Cain, B., Tomlinson, G. and S. Thomas, "CDN Peering Architectural Overview", February2001. [4] Cooper, I., Melve, I. and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", January 2001. [5] Fielding, R., Gettys, J., Mogul, J., Nielsen, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", January 2001. [6] Cain, B., Spatscheck, O., May, M. and A. Barbir, "Request Routing Requirements for Content Internetworking", January 2001. [7] Gilletti, D., Nair, R., Scharber, J. and J. Guha, "Accounting Requirements for CDN Internetworking", January 2001. [8] Amini, L., Spatscheck, O. and S. Thomas, "Distribution Requirements for Content Delivery Internetworking", January 2001. Barbir et al Expires August 19, 2002 [Page 16] Internet-Draft CNAP Data Compression Protocol February 2002 [9] Day, M., Cain, B. and G. Tomlinson, "A Model for Content Distribution Internetworking", January 2001. [10] Day, M., Cain, B. and G. Tomlinson, "Content Distribution Network Peering Scenarios", January 2001. [11] Kent, S., Atkinson, R. and G. Tomlinson, "Security Architecture for the Internet Protocol", January 2001. [12] ANSI X3.92-1981, Data Encryption Algorithm, ANSI, New York, 1981 [13] RFC1661 - The Point-to-Point Protocol (PPP). [14] TIA/EIA 655 - Support for Terminal Adaption and Data Compression in Data Circuit- Terminating Equipment (DCE) with provisions for negotiation of parameters. [15] Cain et al, "Content Network Advertisement Protocol", November 2001. [16] 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: abbieb@nortelnetworks.com Reinaldo Penno Nortel Networks, Inc. 2305 Mission College Boulevard Building SC9-B1240 San Jose, CA 95134 Email: rpenno@nortelnetworks.com 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 August 19, 2002 [Page 17] Internet-Draft CNAP Data Compression Protocol February 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. Barbir et al Expires August 19, 2002 [Page 18]