Subject: [GSMP] proposed solution for recovery

From: Avri Doria <[email-masked]>
Date: Thu, 18 Sep 2003 12:10:16 +0900

>>
>> 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.

---

From: "passjay" <[email-masked]>
Date: Thu, 18 Sep 2003 13:13:22 +0900

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-masked] [mailto:[email-masked]] On Behalf Of Avri
Doria
Sent: Thursday, September 18, 2003 12:09 PM
To: [email-masked]
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.

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

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 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.

a.

---

From: Avri Doria <[email-masked]>
Date: Thu, 18 Sep 2003 13:48:06 +0900

> Would you like to examine section 4.1, 5.1 9.1, and 9.2 in optical 

Yes, I looked at them extensively and will be using some of the fields 
you proposed.  I some cases you suggest making very large changes to 
some existing messages.  As a general rule I would like to avoid doing 
that.  As in some cases I think that some of the solutions change the 
existing message too greatly, for example the event message, and thus 
need to be reviewed further.

a.

---

From: Avri Doria <[email-masked]>
Date: Thu, 18 Sep 2003 15:04:19 +0900

>> Would you like to examine section 4.1, 5.1 9.1, and 9.2 in optical 

I have a general question, not only for you as for the group.  One of 
the implication of your proposed changes to the reservation messages 
where you associate multiple (port,label) pairs with a connection 
reservation is that all recovery links will have the same (i assume) 
service attributes and traffic parameters.  one of the things that 
concerned me was the generality of the solution.  Is it the case that 
all recovery links for any technology would have the same service and 
traffic attributes.   While i have been  assuming they would have the 
same adaptations, i have been assuming that they would not necessarily 
have the same attributes in all cases.  This is one reason i have taken 
a different approach, i.e for greater flexibility.

Another question I have, and this applies to the proposal in the 
optical support draft as well as the one that will show up soon in the 
base draft.

Can one connection have connections (a,b,c) in its recovery set  while 
another has connections (b,c,d)?

a.