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

[Heiles Juergen <Juergen.Heiles@icn.siemens.de>]

Akan,

I don't see your scenario that the management plane sets up explicitly a connection (configuration of each cross-connect) and the control plane does the restoration. As the control plane has to know about the apth in any case i norder to do restoration it should also setup the original apth as SPC. Your approach introduces unnecessary complexity.


Juergen

> -----Original Message-----
> From:	Alan J Weissberger [SMTP:alan.weissberger@ties.itu.ch]
> Sent:	Thursday, May 17, 2001 10:24 PM
> To:	Carmine Daloia
> Cc:	Alan J Weissberger; Tammy.Ferris@mail.sprint.com; ssnarayanan@lucent.com; zwlin@lucent.com; ccamp@ops.ietf.org; mvissers@lucent.com; t1x15@t1.org; tsg13q10@itu.int; tsg15q12@itu.int; tsg15q14@itu.int
> Subject:	Re: : ASTN Layer Network Architecture- Co-ordiantion between Control &  Mgt Planes
> 
> 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