RE: [IP-Optical] RE: Three GMPLS related IDs

[neil.2.harrison@bt.com]

Sivakumar Sankaranarayanan [mailto:ssnarayanan@lucent.com] wrote 15 March
2001 20:37

<snip>
> > 4       A further observation wrt the above is that it seems you are
> > advocating that all failures be conveyed by control-plane 
> message 'events'.
> > Are you suggesting that (at least) the 3 distinct areas of 
> (i) user-plane
> > failures, (ii) signalling protocol failures and (iii) 
> routing protocol
> > failures all get 'merged' into some generic form of event 
> notification?  I
> > would have thought that one would need notification (and 
> general defect
> > handling) per protocol type, and that this would be a 
> function of that
> > protocol only since the failure modes of each would be 
> different (and if one
> > changes one protocol one would not want to create backwards 
> compatibility
> > issues with another).
> >
> 
> [Siva]  Yes, currently there is no clear separation of the 
> events generated from
> 
> different sources. Maybe we need to discuss further on the rationales
> for this separation. For example, a user plane failure that impacts
> traffic would definitely need to be signaled to the control 
> plane.  However,
> when you say signaling "protocol" failures and routing "protocol"
> failures, what are you referring to, is it the failure of the 
> "box" that is
> implementing the signaling and routing software? Is it the 
> failure of the link
> in
> the SCN?  Is it a wrong routing decision?  If it is failure 
> of the DCN/SCN, then
> it should be protected by theDCN/SCN failure recovery 
> methods, e.g., protected
> signaling channels.  If it is a
> box failure, then it is a bigger problem and not only is 
> restoration mechanisms
> supposed to kick in, but some maintenance action is needed 
> and so the management
> 
> system would have to be informed as well.
NH=> What I meant by this was very simple.  If we consider the user-plane
this has defects which are either (i) inherited from lower layers or (ii)
caused within the layer.  The former generally manifests itself as a 'break'
to clients (where a client can be a higher user-plane layer network or the
peer control-plane or management-plane protocols).  'Within layer' defects
are technology dependent in terms of specification, and can be either simple
breaks, swapped trails or mismerged trails (latter only applies to pkt
case).  For example the definition of simple breaks is different for OTN,
SDH, ATM, MPLS, etc and can be, for example, LoS, LoF (loss of framing) or
loss of some keepalive/hello say.  For the swapped/mismerging cases one
needs some form of trail termination network-wide unique ID.  For the
routing, signalling and management protocols, these could also have failure
modes associated with the specific protocol, eg bad PATH message in RSVP,
bad LSA in the case of OSPF, etc.  There is also the case of internal 'box
failures', which are proprietary, and which could affect user and/or control
and/or management planes.  So all I was really saying here is that some
level of defect handling is required at a per transport, per protocol and
per box level.
<snipped to end>