Re: Responding to the OIF

[dimitri papadimitriou <dpapadimitriou@psg.com>]

Adrian Farrel wrote:
> Hi Evelyne,
>
>
> > 1. From the examples below, STS3c and VC4 have different
> > RCC/NCC values. Clarifications on which values should be
> > used for SONET/SDH interworking would be useful.
>  
> I have a couple of folks looking at this for me because I can't tell the
> difference between a timeslice and a cakeslice.
>
> Hopefully they will generate a response soon.

this may help -

   "A dedicated signal type is assigned to a SONET STS-3c SPE instead of
   coding it as a contiguous concatenation of three STS-1 SPEs. This is
   done in order to provide easy interworking between SONET and SDH
   signaling."

also the RFC explains how the negotiation occurs (RCC/NCC selection is a 
local decision process depending on the supported capabilities) - not a 
big deal here, there are 4 cases possible:

- symmetric fixed case either SDH or SONET on both sides, there is no 
interworking issue possible

- symmetric configurable case (assumption taken by OIF) where selection 
is not impacting establishment, there is no interworking issue possible

- asymmetric fixed-configurable case: the upstream node drives the 
selection by indicating the selected values, there is no interworking 
issue possible

- asymmetric configurable-fixed case: an error is generated if the 
config supported by the fixed side is not selected by the upstream node 
but signaling just follows result of the selection - however, GMPLS 
signaling can not correct this in any case -

> > 5. Is a change in the presence/absence of ResvConf considered a
> > trigger message?
>
>
> Yes, it would be a trigger message (that is, it would not be treated as a
> simple refresh). But a "trigger message" does not necessarily cause any
> action.
>
>
> > My interpretation of the text below is that a refresh resv
> > message containing a RESV_CONF object would not
> > result in the generation of a RESV_CONF message,
> > RESV_CONF messages only being sent on trigger
> > resv message. Is that correct?
>
>
> Seems reasonable to me.
> That way the ResvConf confirms the receipt of the changed Resv.
>
> I guess I should have added a note that a ResvConf message is not
> necessarily reliably delivered. Relying on the receipt of a ResvConf
> message before doing something (e.g. turning on the laser) might be a poor
> idea. GMPLS uses the Administrative Status object and in particular the
> R-bit in order to reliably achieve this function.
>
> Adrian
>
>
>
> .