Re: : ASTN Layer Network Architecture- Co-ordiantion between Control & Mgt Planes

[Maarten Vissers <mvissers@lucent.com>]

Alan,

Loss of signal comes from the transport plane as part of the AI_TSF
signal towards protection and control plance restoration engines. PM
based threshold crossings are up to now never used to trigger
protection. It is the degraded signal (DEG) defect that is used so far,
which contributes as AI_TSD to protection/restorarion from the transport
plane.

Regards,

Maarten

Alan J Weissberger wrote:
> 
> Hi Carmine
> 
> Thanks for your reply
> 
> 1.  There is a scenario where the Management plane (e.g. EMS  and/or NMS) sets
> up the connection, but the control plane then does re-routing based restoration
> over the NNI.  At least one network operator told me that they wanted to do that
> 
> 2.  What I meant to say was that the protection triggers would come from the
> management plane (e.g. TCM threshold crossings, Loss of light/ loss of signal,
> etc).  Restoration triggers could come from Physical layer or a higher layer
> 
> Carmine, are you going to Caracas?  I will be there, but not at June 4-7 Turin
> meeting
> 
> rgds
> 
> alan W
> 
> Quoting Carmine Daloia <daloia@lucent.com>:
> 
> > Hi Alan,
> >
> > I agree there is need for management plane and control plane
> > interactions.  I am
> > a bit confused with your second example (Resiliency/Self-Healing)
> > though.
> >
> > You indicate that Mangement Plane sets up connection, but control plane
> > is
> > notified of the path to do restoration on a hard failure. Are you
> > suggesting
> > that the control plane in this scenario would only be responsible for
> > restoration and not setting up the initial connection?
> >
> > Also, you indicate that the control plane sets up the connection, but
> > the
> > management plane is notified to do protection on a SONET/SDH path or
> > line.  The
> > management plane is never notified to do protection. Protection (e.g.,
> > SNCP,
> > MS-SPRING) occurs in the transport plane.  So in this scenario, I am not
> > sure
> > what you mean by control plane and management plane interactions.
> >
> > Carmine
> >
> > Alan J Weissberger wrote:
> > >
> > > All
> > >
> > > I agree with Tammy's remarks below regarding the jurisdiction of the
> > control
> > > plane.  We do have a G.874 LL item on Interworking between Mgt and
> > Control
> > > planes and this takes on more importance with soft PC's.  I see 3
> > critical
> > > interactions between these two planes:
> > >
> > > 1.  SPCs: management plane initiates connection, control plane (NNI
> > sig &
> > > Routing) executes, then informs mgt plane of outcome of connection
> > setup request
> > > (see attached illustration).  PM and fault management done in
> > management plane
> > >
> > >
> > > 2.  Resiliency/ self healing: Management plane sets up connection, but
> > control
> > > plane is notified of the path to do restoration on a hard failure.
> > Conversely,
> > > control plane sets up the connection, but management plane notified to
> > do
> > > protection on a SONET/SDH path or line layer basis
> > >
> > > 3.  Control plane sets up an OTN connection, management plane is
> > notified to
> > > activate G.709 TCM sessions (or they may be pre-allocated along
> > predefined paths
> > >
> > > There are others as well, but I believe the above three are most
> > important
> > >
> > > I suggest we address this "co-ordination between planes" issue on May
> > 21-22,
> > > when we have the ASON discussions in Caracas.
> > >
> > > rgds
> > >
> > > alan W
> > >
> > > Quoting Tammy.Ferris@mail.sprint.com:
> > >
> > > > Shiva,
> > > > Traditionally, often different systems are responsible for different
> > > > management functions relating to the same resources.
> > > >
> > > > I think it is important to define and keep in mind scope.  For
> > example,
> > > > as I currently understand it, the control plane is only required to
> > > > control path set-up within a single layer network (while interacting
> > > > with other layers as needed to do its job).
> > > >
> > > > Network/Service management (management plane) needs scope of all
> > layers
> > > > and interfaces that cross administrative boundaries.
> > > >
> > > > My current view is that the control plane is mainly responsible for
> > > > connection set-up and tear-down (network engineering) and traffic
> > > > management for those resources it has been allocated.  If, for some
> > > > reason, it cannot do its' job (e.g. failure of a control channel),
> > it
> > > > should be reporting such failures to the management plane.
> > > > Tammy
> > > > -----Original Message-----
> > > > From: ssnarayanan [mailto:ssnarayanan@lucent.com]
> > > > Sent: Thursday, May 17, 2001 08:47
> > > > To: zwlin
> > > > Cc: ssnarayanan; Tammy.Ferris; mvissers; ccamp; t1x15; tsg13q10;
> > > > tsg15q12; tsg15q14
> > > > Subject: Re: ASTN Layer Network Architecture
> > > >
> > > >
> > > > Tammy, Maarten and Zhi,
> > > >   Along the lines of Zhi's question, it is also fundamental to know
> > > > which plane "owns" the management responsibility for the connection,
> > > > e.g., if a SPC is setup, then is it the management plane which owns
> > this
> > > > or the control plane.  The management plane initiates the request,
> > but
> > > > the control plane executes the request via NNI signaling.  As far as
> > I
> > > > see, if we resolve this issue, then we can get a better
> > understanding of
> > > > what is meant by "migrating" a connection from the management plane
> > to
> > > > the control plane control.
> > > >
> > > > Regards,
> > > > Shiva
> > > > ------------------
> > > > Sivakumar Sankaranarayanan
> > > > Member of Technical Staff
> > > > HO 3C-508A
> > > > Lucent Technologies,
> > > > 101 Crawfords Corner Road,
> > > > Holmdel, NJ 07733.
> > > >
> > > > Phone:        +1 732 949 5762
> > > > Fax:  +1 732 949 3210 (Attn: S. Sankaranarayanan)
> > > > Email:        ssnarayanan@lucent.com
> > > >
> > >
> > > Alan J Weissberger
> > > DCT
> > > 2013 Acacia CT
> > > Santa Clara, CA 95050-3482
> > > 1 408 588 6493
> > > Home email: ajwdct@netgate.net
> > >
> > >
> > ------------------------------------------------------------------------------
> --
> > >                Name: SPCs.ppt
> > >    SPCs.ppt    Type: Microsoft PowerPoint Show
> > (application/vnd.ms-powerpoint)
> > >            Encoding: base64
> >
> 
> Alan J Weissberger
> DCT
> 2013 Acacia CT
> Santa Clara, CA 95050-3482
> 1 408 588 6493
> Home email: ajwdct@netgate.net
> 1 408 588 6493
> ajwdct@technologist.com
begin:vcard 
n:Vissers;Maarten
tel;cell:+31 62 061 3945
tel;fax:+31 35 687 5976
tel;home:+31 35 526 5463
tel;work:+31 35 687 4270
x-mozilla-html:FALSE
org:Optical Network Group;Lucent Technologies Nederland
version:2.1
email;internet:mvissers@lucent.com
title:Consulting Member of Technical Staff
adr;quoted-printable:;;Botterstraat 45=0D=0A=0D=0A;1271 XL Huizen;;;The Netherlands
fn:Maarten Vissers
end:vcard