Please publish the attached as an Internet Draft.
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)
<draft-barbir-cdi-cnapcomp-01.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
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]