RE: proposed solution for recovery

We have already proposed one of recovery support solutions in optical
spec.
Would you like to examine section 4.1, 5.1 9.1, and 9.2 in optical spec.
 
Regards
JungYul Choi. 
 
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Avri
Doria
Sent: Thursday, September 18, 2003 12:09 PM
To: [email protected]
Subject: [GSMP] proposed solution for recovery
 

In order to support the function, we need to modify connection
management, port configuration message, event message, failure response
message, and so on. 

Yes, indeed, we need some change, but we as a group have not arrived at
an agreement of what level of support we need.

While not a complete solution yet, i am currently working on doing the
following.

1. Add the capability to include protection information in add, move and
delete messages. This is as opposed to the previous solution i proposed
that only allowed protection by doing a second add. I do not, however,
plan to remove the ability to add a 1+1 protection link by doing a
second add - unless of course there is consensus that i should do

2. Continue using reservations to establish recovery channels. This
still means that, except in the case of the second add method,
reservation channels would need to be reserved before being assigned.
Each reservation would still require its own message.

3. Add a msg for grouping several reservation ids into a reservation set
with an reservation set id. I plan to use a flag in the reservation
field to differentiate between a reservation set id and a single
reservation id.

4. Add a bulk transaction msg for grouping regular messages (all
messages except adjacency, switch configuration and bulk) including
reservations into a single transaction. The bulk message would be
designated for either sequential process or non-ordered process. In the
sequential process, if one message failed, the others would not be
processed. In the non-ordered bulk each message would succeed or fail
without affecting other messages in the bulk bundle. (any preferences
for which should be the default type? and are there any other processing
modes I should include?) The bulk message would include a count of
included messages and the bulk response would include failure and
success count info.

(I have not thought much about the event messages for reservations yet
and of course plan to include bunches of failure responses, though i am
sure i will originally miss some failure possibilities)

Part of the reason I am taking this approach is that I still would like
the protocol to have a relatively simple commands and though that using
this approach might contribute to that. And I would like to change
existing messages ass little as possible.

I am still working out the message details and will float a new copy of
the draft for review as soon as I do - hopefully before next week. There
are also still open dealing with how restoration is dealt with between
the controller and the switch, but I think these messages will provide
the basis for resolving those issues.

As always, I would be interested in comments on the list. No need to
wait for the draft.

a.