Subject: Failure definition w.r.t. SONET/SDH and Protection/Restoration

From: "Diego Caviglia" <[email-masked]>
Date: Wed, 23 Mar 2005 12:05:49 +0100

Hi all,
              is it defined somewhere, with respect to SDH/SONET, which
defect has to be consider as a failure?

It seems to me that for interoperability could be useful to have a list of
defect that must be considered as failure, the same applies for defect that
optionally can be considered as defect.

May be also a communication between restoration TNEs in order to agree on
the list could be useful.

Does anyone agree on that?

Regards

Diego

PS I apologise if the list is defined somewhere but I wasn't able to find
it.

---

From: Amit 70405 <[email-masked]>
Date: Fri, 25 Mar 2005 09:41:04 +0800

Hi Adrian & Igor,
   But there is one issue with this multilayer protection.
   Say in the case if the link gets broken, and the lower layer protection has succeeded.
   In this case, should the control plane(higher layer) be notified by the lower layer of link??

   If yes than it has following consequences:
   - As control plane is unaware of any failure, control plane will continue to setup new connections on the failed.
   - This may not be a good thing to do.
   - Some means may be needed to avoid this link in Path computation.

   If no than following are the consequences:
   - Control plane too will go ahead with its protection mechanism.
  
   Let me know your view.
Regards,
Amit.

----- Original Message -----
From: Adrian Farrel <[email-masked]>
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> Hi Amit,
> 
> >    Do you mean to say that Data plane & Control plane protection 
> shouldbe independant of each other??
> 
> No, I mean that they MAY be independent.
> In particular, if you are using the control plane *and* the data 
> plane to
> manage protection on the same set of resources you are bound to 
> get in a
> horrible mess.
> 
> Seems more reasonable that you would apply data plane protection 
> first and
> then apply control plane protection at a higher level.
> 
> >    If so, in case of MSP protection in SDH,
> >     Control plane should not have any control over the resource pool
> >      used for MSP switch.
> >    This may lead to lot of unused resource in the network.
> 
> It is certain that each layer of protection that you install MAY 
> result in
> unused resources. Building multiple layers of protection will, 
> therefore,potentially build up more and more unused resources. It 
> is the job of
> CCAMP to produce the tools that allow operators to build the 
> protectionschemes that they want. It's not really our business to 
> tell them which
> schemes to build and when.
> 
> Cheers,
> Adrian
> 
>

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 25 Mar 2005 08:25:22 +0100

Hi Amit,
               actally for link/span protection I don't see any problem
with control plane restoration and data plane protection interworking.

It is sufficient to hide protection resourse to control plane.

I see a lot of problems (there are SPs opened in the ITU-T documents about
that) when you want an MS-SPRing protected ring to interwork with GMPLS
restoration.

Actually I'm not sure if that topic is in the charter of the CCAMP (Adrian
what is your feeling about this?) but in any case it is a problem.

Regards

Diego

Amit 70405 <[email-masked]> on 25/03/2005 02.41.04

To:    Adrian Farrel <[email-masked]>, Igor Bryskin
       <[email-masked]>
cc:    Diego Caviglia <[email-masked]>, [email-masked],
       [email-masked]

Subject:    Re: Failure definition w.r.t. SONET/SDH and
       Protection/Restoration

Hi Adrian & Igor,
   But there is one issue with this multilayer protection.
   Say in the case if the link gets broken, and the lower layer protection
has succeeded.
   In this case, should the control plane(higher layer) be notified by the
lower layer of link??

   If yes than it has following consequences:
   - As control plane is unaware of any failure, control plane will
continue to setup new connections on the failed.
   - This may not be a good thing to do.
   - Some means may be needed to avoid this link in Path computation.

   Let me know your view.
Regards,
Amit.

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 25 Mar 2005 08:32:28 +0100

Hi Adrian,
                  I see your points (that doesn't mean I agree ;-)).

Given that seems that I'm the only one to ask such kind of statement I 
think the discussion could stop here.

Regards and thanks

Diego

Please respond to "Adrian Farrel" <[email-masked]>
To:     "Diego Caviglia" <[email-masked]>
cc:     <[email-masked]>, <[email-masked]> 

Hi Diego,
 
>> - The GMPLS control plane does not  necessarily want to define data
>>   plane failures. Rather, it  wants to signal (report) errors and allow
>>   the control plane  state (and data plane state) to remain in place.
> [dc] Agreed and that  was my initial point.  Which kind of data plane 
(e.g.
> SDG)  defects have to advertised to control plane to trigger 
restoration?  
> Given that control plane is concerned in  restore the data plane it 
should 
> also define what is a failure.  It is a  fiber break or we have also to 
> consider other defects? Of course we  have.  What happens if one
> restoration TNE consider as failure  only Loss Of Light (LOS) while the
> other starts restoration even if there  is a e.g. Loss Of Pointer?  Is 
> that acceptable?
 
Let's look at two things.
 
First, the trigger for protection switchover. If  you look at section 6.2 
of draft-ietf-ccamp-gmpls-recovery-e2e-signaling-02.txt  (currently in 
working group last call, so please comment now!) you will  see...
 
   To co-ordinate the switchover  between end-points, an end-to-end 
   switchover request is needed  since a failure affecting one the LSPs 
   results in both  end-points switching to the other LSP (resulting in 
   receiving  traffic from the other LSP) in their respective 
   directions.  This is done using the Notify message with a new Error 
   Code  indicating "Working LSP Failure (Switchover Request)".

This clearly indicates that the objective is not  to report a failure, but 
to request a switchover.
 
Which takes us to your second point: which data  plane errors should be 
reported to the control plane to trigger switchover  signaling, and would 
it matter if different transport nodes applied different  policies?
 
My contention is that this is entirely an  implementation issue. I think 
it would be a wise implementation that included  some degree of 
configurability to this function, but that is not in CCAMP's  scope. If 
two "TNEs" have different trigger thresholds I do not see that any  harm 
will be done, it might even be desirable.
 
>> - Decisions that trigger control plane  protection actions are
>>   fundamentally implementation  choices.
> [dc] Here we are.  This is the point.  IMHO CCAMP  should provide some
> guidance on this.
> 
>>   Maybe  we should make a statement that this type
>>   of thing SHOULD be  configurable so that there is some sort of
>>   consistency within  a network.
> [dc] Something like "..control plane restoration mechanism  SHOULD be
> triggered as the SNC/I defined in ITU-T G.783 (section  12.1.1.1).
 
But why?
 
It is not enough to know that this is a difficult  question for an 
implementaiton to answer.
 
Why is it not enough to say that the Data Plane  should trigger control 
plane recovery action when the data plane deems that  there is a fault 
from which it determines that recovery is required and from  which it is 
unable or unwilling to recover on its own?
 
If you can show that there is a need to make a more definitive statement 
then we can consider it.

Cheers,
Adrian

---

From: Amit 70405 <[email-masked]>
Date: Fri, 25 Mar 2005 16:22:49 +0800

Hi Diego,
   Its not only the case with MSP protection.
   For that matter any Multilayer protection will have the interworking issues.
   According to me lower layer restoration should be mandatorily independant of higher layer restoration.
   And let the Network operator be aware of the consequences(mainly some unutilised resources).
   
   This is the point which I feel that CCAMP should clarify.

Regards,
Amit.

----- Original Message -----
From: Diego Caviglia <[email-masked]>
Date: Friday, March 25, 2005 3:25 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> <[email-masked]>cc:     Diego Caviglia 
> <[email-masked]>, [email-masked], 
> [email-masked] 
>

---

From: <[email-masked]>
Date: Fri, 25 Mar 2005 12:03:54 -0000

You are quite correct Amit.  What you need is proper client/server
functional decoupling between the layer networks involved.  The ideas of
a 'common' control-plane (esp routing) from IP to Optics is rather a
nonsence in our view.....not just technically either, you need this to
provide the key 'network builder service' capability in commercial
relationships between operators.

Historically things have worked OK in practice because there has been a
common-sense approach about how the 3 networking modes of co-cs, co-ps
and cl-ps have been nested (there are 9 possible client/server
relationships here are there are no formal rules governing how many
up/down transitions are allowed in some end-end reference
architecture...and remember, a client layer network will inherit the
performance of its server layer network, and this is recursive to the
duct).  PWE3 stuff is turning this on its head wrt XoverY relationships
(not that these even ensure the key requirement of client/server
independence/transparency anyway)....hopefully most operator folks
should have the common sense to see the problems and avoid the pitfalls.

In the 2 co modes the defect handling MUST be done in the data-plane and
it MUST be unidirectional.  There is an OAM requirement to send a signal
called FDI (Forward Defect Indication...sometimes know as AIS in co-cs
technologies) which is intended to suppress alarm storms (which would
otherwise occur in all higher client co mode networks).  Has to be like
this, esp in the co-cs mode as the control/management-plane is forced to
run OOB and it must work the *same* for all methods of trail
set-up....be this by signalling protocols X, Y or Z of via management
provisioning.

regards, neil

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Amit 70405
> Sent: 25 March 2005 08:23
> To: Diego Caviglia
> Cc: Adrian Farrel <adrian; Igor Bryskin <i_bryskin; ccamp; Sasha
>    According to me lower layer restoration should be 
> mandatorily independant of higher layer restoration.
>    And let the Network operator be aware of the 
> consequences(mainly some unutilised resources).
>    
> > > plane to manage protection on the same set of resources you are 
> > > bound to get in a
> > > horrible mess.
> > >
> > > first and then apply control plane protection at a higher level.
> > >
> > > result in unused resources. Building multiple layers of 
> protection 
> > > will, therefore,potentially build up more and more unused 
> resources. 
> > > It is the job of

---

From: Igor Bryskin <[email-masked]>
Date: Fri, 25 Mar 2005 07:51:12 -0800 (PST)

Please, ee in-line.

Amit 70405 <[email-masked]> wrote: 

Hi Adrian & Igor,

IIB>> Control plane needs to verify with the data plane if the fault condition still exists after the hold-off time and start recovery procedures only if necessary.

Igor

Let me know your view.
Regards,
Amit.

----- Original Message -----
From: Adrian Farrel 
Date: Thursday, March 24, 2005 7:40 pm
Subject: Re: Failure definition w.r.t. SONET/SDH and Protection/Restoration

> schemes to build and when.

---------------------------------
Do you Yahoo!?
 Yahoo! Small Business - Try our new resources site!

---

From: "Diego Caviglia" <[email-masked]>
Date: Fri, 25 Mar 2005 22:30:10 +0100

Hi Amit,
                it seems to me that we are mixing different issues here (a
part from the fact that may be we need to change the subject of the
thread).

First point I think that link protection and path protection leads to
different problem.

In case of link protection it is quite simple to solve the issue; data
plane protecting link is hidden to the control plane and a hold-off timer
is used in order to separate data plane protection mechanism from control
plane restoration.

In case of path protection thing are different and I think are not solved,
or at least not solved in CCAMP/ITU-T.

The main issue I see in this field is the interworking between MS-SPRing
protection and control plane restoration.

It is a matter of fact that MS-SPRing is one of the most used inherent
protection scheme in SDH network but up to now we don't have a 'standard'
way to let MS-SPRing to interwork with control plane restoration scheme
(e.g. timeslot interchange and squelching problem)

I've again to mention the WG chair here and ask him if this kind issues are
in the scope of the CCAMP.

Regards

Diego

Hi Adrian & Igor,

   Let me know your view.
Regards,
Amit.