On Fri, 23 May 2003, jfcm wrote:
On 18:43 23/05/03, Alex Rousskov said:
Here is my interpretation of the primary part of your problem:
I am afraid I was not clear enough. The system exists. It runs well
and is designed to have A respondng B an XML status report. This is
all what A knows doing. It checks the calling IP address and
respons. This permits B to discover that A has a problem from the
daily status report. The only improvement is that A will call when
it has a problem (an empty XML message).
I do not think the above details affect correctness of my response.
A emits messages using format/protocol pA
Yes. Empty XML.
A is configured to talk D as its "next hop" for pA
It calls B. But because it uses IP addresses, the address listed as
B has to be D address. Or better - but how will that work. D fakes
being B.
A talks to D. Whether D represents, fakes, or forwards messages to B
is of no importance at this point. D is the "next hop" for A, using
pA.
B is interested in A's state but understands
(or prefers) messages in format/protocol pB, not pA
Yes. The message is unique. A full A XML status report
D accepts messages in pA from A,
D adapts messages in pA to messages in pB, possibly using C,
D forwards adapted messages (in pB) to B
Yes but you by pass all what is interesting:
- multiple sending in one very long cession
I already commented on that: OCP supports multiple adapted responses
and OPES must not prohibit them.
- possible changes in who is C
Not a problem from OPES/OCP point of view, as long as D and C can
handle that. For example, D can close the existing OCP connection to
C1 and establish a new connection to C2, transparently for A and B.
- necessary calls from C to A to be able to complete the service
on the pA to B call.
I already commented on that: this is not prohibited by OPES but is
beyond OPES scope. In other words, C is free to do that, using
whatever means necessary.
C is in a different administrative domain than D
An OPES system can support the format/protocol adaptation above, IMO.
OCP already handles the case when one message from A is converted to
multiple messages to B (to address your concern #3).
- even if it is a "long cession" are there no timers anywhere
which may influence?
OCP timeouts are not defined yet, but will be fully
configurable/negotiable, of course. The duration of an OCP connection
does not matter from OCP point of view (as long as all OCP agents
involved are OK with long-lived connections).
There may be some interesting things one can do on transport level to
make long-lived OCP connections efficient and robust (e.g., smooth TCP
connection termination and resumption using custom OCP messages).
- no impact if there are reboots of D?
No impact from OPES/OCP point of view. However, raw TCP may not be
appropriate transport for OCP in this case, and D has to be able to
keep state across reboots. These are not OPES/OCP issues though. These
are issues for D state storage and for OCP transport.
The other part of your problem is communication in the other direction
(B, D, and C talking to A). I believe such communication is not
prohibited by OPES rules, but otherwise is outside of OPES scope.
- problem in having them totally supported under OCP you would
think of?
OCP does not know of these "communications in the other direction". If
A, B, D, and C want to use OCP for "communication in the other
direction", they can. I am not sure it would be the best choice
though. Don't they already have a protocol that B, D, and C use to
query A? Perhaps I misunderstand your question/concern?
Interest is that if I got the funding it might help developping OCP
functions and test them. Also, to put me back in the OCP stuff (I am
out of scope right now with the load with my ICANN oriented load).
Low chances to get a budget, so is it worth a try? Or are there
enough resources already commited in here?
Are you kidding? There are never enough resources! If you get funding
and will be willing to share money and/or results, the group will
benefit, of course. For example, it can speed up building a decent
reference implementation.
Alex.
On Fri, 23 May 2003, jfcm wrote:
I come across the following customer request. I think it may help checking
OCP can be used and can support this.
There are four systems involved.
1. A: an automated system (oil station pump)
2. B; a remote management station
3. C: a considered ticketing service
4. D: a possible OPES
B polls A once a day
When A has an incident it calls B.
But B is management not support
So the idea is D as an OPES between A and B branching into C via OCP.
1. when A has a problem, the call is blocked by D and C is told.
2. C manages the incident (may take hours)
3. when the incident has been repaired, C can authorize D to forward the
call as "treated".
I would like to understand if all this is orthodox as far as OCP which
will
be used between D and C.
1. is there a problem about qualifying this as an OPES?
2. A only knows to say "I have a problem" and to report its status upon
request from B (IP address) and respond.
D's IP would replace B's IP in A table. So the dialog would actually
be A-D.
So, if B and C call, D should make the calls coming from D.
there are three reasons to call A:
- normal administrative calls by B
- calls by D when receiving the alarm: to check the reason of the
call
(D may decide to discard if it is a repetitive call)
- calls be C: as part of the ticketing status control and reporting
to
technicians
Calls by D and C are part of the OPES service. Is that dialog with
the
caller permitted?
3. there would be a need for a multiple "continuations" of A calls to be
received by B.
Sequence:
- A calls to say I have a problem : this is the data transmitted that
is going to be modified.
- B should receive that data as a continuity of different blocks, may
be over hours
- 1st block: there is an alarm info to follow
- 2. this alarms has been taken over by the ticketing service
- 3. the ticketing service may pass different reports
- 4. report "the problem has been addressed as follows: ...."
4. what is also interesting is that A, B, D are in the same domain of
security While C is an externalized service. So OCP relations would have
to
be secure. Also, C may change into C1, C2, etc as the complexity/type of
incident management is handled.