Please publish the following as an internet draft.
thanks
abbie barbir
abbieb@nortelnetworks.com
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 [15].
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 [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 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 [13]. 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].
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 [15] 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 [15],
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.
3.2.6.1 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 [13] and Data Compression over Frame Relay
[16]. 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 [16].
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 [14]. 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 [16]. 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.
3.3.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 3 CDCP Frame Format
Barbir et al Expires May 10, 2002 [Page 11]
Internet-Draft CNAP Data Compression Protocol May 2002
3.3.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 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 [12])
- Length: one octet in length set to decimal 3
- Revision: one octet in length set to decimal 1
3.3.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 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 [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.
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 [13] 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 [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.
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", January 2001.
[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.
Barbir et al Expires May 10, 2002 [Page 15]
Internet-Draft CNAP Data Compression Protocol May 2002
[8] Amini, L., Spatscheck, O. and S. Thomas, "Distribution
Requirements for Content Delivery Internetworking", January
2001.
[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.241-1994 Data Compression Method - adaptive coding with
sliding window for information interchange.
[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 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 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.