Subject: Capability Negotiation for OCP

From: "Reinaldo Penno" <[email-masked]>
Date: Thu, 17 Apr 2003 11:09:35 -0700

These are my ideas on capability negotiation. They are a mix of SDP's
offer/answer, BGP and PPP. I wait for comments before I expand the sections.

-----------

* The requirements for the capability negotiation are:

- Small number of RTTs
- Simple but extensible
- Able to negotiate different capabilities for transaction, connection,
channel and device level. (did I miss any layer?)
- Able to negotiate capabilities for a different processing layer (for
example, inside a channel you can alter the capabilities for the device
level, or inside a transaction you can alter the capabilities for the
channel).

* Capabilities

Capabilities are expressed with a identifier and a value. Depending on the
OCP protocol the WG chooses, this can be achieved by a TLV field or a text
based <name:value> notation

The same capability can be included in a packet more than once if they are
on different scopes (e.g., device vs. transaction).

* Packet Format

The capability negotiation packet is divided in several scopes (device,
transaction, channel, etc). In each scope any number of capabilities and
their respective values can be included.

The capability negotiation packets also includes a identifier so that the
peers can match packets belonging to the same negotiation.

There are 4 different types of capability negotiation packets: <offer>,
<answer>, <success> and <failure>

* Capability Negotiation

The capability negotiation starts with a <offer> packet in which the
initiator (OPES processor or Callout server) lists the desired capabilities
and their respectrive values in each scope. 

To every <offer> sent by the initiator, the non-initiator (OCP peer) sends
an <answer> packet listing the capabilities it would prefer a different
value and the ones it does not understand at all.

Based on the answer of its peer, the initiator of the capability negotiation
can send a <failure> packet and raise an event or try again with the changes
proposed by its peer. When the OCP peers have reached an agreement the
non-initiator will send an <success> packet which indicate the end of the
capability negotiation process.

It is expected that no more than 4 messages will be required for the peers
to reach a agreement: <offer>, <answer> with a different proposal, final
<offer>, <success>.

If one of the peers does not want to carry the capability negotiation any
further, it can send a <failure> packet. The <failure> packet should contain
the reason for the failure. More specifically, the message must contain for
each offending capability the offered value and the value proposed by the
peer. 

It is important to notice the capability negotiation process can occur
anytime during the life of a OCP transport connection (for the lack of a
better term), not necessarily when a connection/channel/transaction is
established.

----------

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 12:57:32 -0600 (MDT)

On Thu, 17 Apr 2003, Reinaldo Penno wrote:

> These are my ideas on capability negotiation. They are a mix of
> SDP's offer/answer, BGP and PPP.

Sounds like a great start to me. I am sure we will run into arguments
once the wording becomes more specific.

One high-level thing to consider now is scope (level) definition: Do
we want to have a fixed number of levels associated with OCP entities
like connection and transaction? Or do we want to allow unlimited
nesting? For example, is it possible that something needs to be
re-negotiated in the middle of a transaction?

Another issue: are negotiations always limited in scope to a single
transport connection? Are we worried that two connections to the same
IP may not end up at the same callout server? In other words, if an
OPES processor wants to open 10 connections to a callout server, does
it need to negotiate each from scratch OR can it refer to earlier
("cached") negotiations?

Semantically, does <offer> describe sender characteristics "I can use
Foo" or can it describe sender desires (recipient characteristics)
"Please use Foo" as well? For example, how can a callout server change
OPES processor copying state from "yes" to "no" in the middle of an
OCP connection? Using "Processor-uses-copying" property?

How is the order of negotiations determined -- what if both OPES
processor and callout server send <offer> messages "at once"?

Finally, can we define a complete set of parameters that MUST be
negotiated for OCP Core?

Let's not spent too much effort on what you call "packet format" now.
The choice of transport protocol and encoding will have a major impact
on that, I think.

Thank you,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 17 Apr 2003 14:52:45 -0600

"Channel" and "device" are not terms of reference that I've seen for OPES
before.  What are they, how do they relate to the architecture?

Why aren't two messages ("menu offer" and "menu selection") sufficient?
Many IETF protocols use this method and live happy lives.

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 15:11:27 -0600 (MDT)

On Thu, 17 Apr 2003, The Purple Streak, Hilarie Orman wrote:

> Why aren't two messages ("menu offer" and "menu selection")
> sufficient? Many IETF protocols use this method and live happy
> lives.

How do you indicate success/failure with only offer/selection message
available? For example, how can an OPES processor tell callout server
that server's particular selection (combination of available options)
from the offered menu is not acceptable/available?

Just because the processor offers

	paramA: valueA1 or valueA2
	paramB: valueB1 or valueB2

does not, in general, imply that any (valueA*, valueB*)
combination/pair selected by the server is acceptable to the OPES
processor, right?

Can you give an example of an offer/selection protocol that negotiates
more than one parameter at once but lacks success/failure
acknowledgments?

Thanks,

Alex.

---

From: "The Purple Streak, Hilarie Orman" <[email-masked]>
Date: Thu, 17 Apr 2003 16:15:15 -0600

PPP, IPSec and IKE use "offer, select".  The trick is to spell out the
complete set of selections at offer time.  Don't say (A1 or A2) and
(B1 or B2) if (A1 and B2) is not permitted - say instead

	{ A2 and (B1 or B2) } or { A1 and B1}

Hilarie

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 17 Apr 2003 16:57:09 -0600 (MDT)

On Thu, 17 Apr 2003, The Purple Streak, Hilarie Orman wrote:

> PPP, IPSec and IKE use "offer, select".  The trick is to spell out
> the complete set of selections at offer time.  Don't say (A1 or A2)
> and (B1 or B2) if (A1 and B2) is not permitted - say instead
>

I see. The problem is solved by enumerating all possibilities _before_
negotiation begins. Kind of defeats the whole idea behind
"negotiation" -- "multiple choice" is not how I would define
negotiation. Perhaps that's the best we can do with computers though,
not sure.

Alex.