Re: changes in draft-ietf-ippcp-protocol-04.txt

[Avram Shacham <[e-mail]>]

Naganand,

The CPI usage can be in several modes, as the following scenarios present:

1.  manual setup:
Nodes A and B were configured to use a well-defined algorithm, say
IPCOMP_V42BIS, with no parameters. In this case, nodes A and B do not use
ISAKMP (or any other dynamic negotiations protocol) but immediately start
using IPComp with CPI = 4. (DOI defines IPCOMP_V42BIS Transform ID to be 4.)

2. ISAKMP resulting with well-known algorithm, no params:
Nodes A and C are not manually configured. They negotiate the usage of
IPCOMP_V42BIS with no parameters. The may select the CPI in both directions
to be 4. This will result in time-saving on the receiving side, as CPI=4 can
be immediately decompressed using V42BIS. These nodes can also select CPIs
in the range 64-61439, but in this case the receiver has first to look up
the algorithm in his IPCA database.

3. ISAKMP resulting with well-known algorithm with params/"un-known" alg:
Nodes A and D are not manually configured. They negotiate the usage of
COMP_V42BIS _with_ parameters or some new algorithm. They must select CPIs
in the range 64-61439. In this case the receiver must first look up the
algorithm in his IPCA database using <dest, CPI>.

In all cases, the sending node has to maintain an IPCA db, where <dest, src,
port, port> defines a CPI, the related compression algorithm, and the
related params, if any.

The only change in the new version is based on Thomas Narten's idea
(thanks!) not to restrict negotiating parties from selecting a CPI in the
range 0-63, thus saving some CPU cycles in the receiving node as scenario
(2) demonstrates.

avram

At 11:24 AM 12/17/97 -0500, Naganand Doraswamy wrote:
>Avram,
>
>I am little bit confused about the usage of CPI in the new draft. The
>receiver allocates the CPI and it has to unique. Now we can say the
>uniqueness is based on the tuple <src, dst, protocol, CPI> in which case
>things work fine. However, if the uniqueness is based just on <dst,
>protocol, CPI> then the receiving host (which is <dst> above) will not
>be able to use the same CPI for two hosts A and B.
>
>Thanks,
> 
>--Naganand