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

[Maarten Vissers <mvissers@lucent.com>]

Alan,

I will not be in Caracas, but I will be in Turin.

In my (sometimes) simple vision, I expect TCM endpoints to be activated
already at the E-NNI and UNI points in the network before any actual
connection is being requested. Once the decision is made that an
interface port is an E-NNI/UNI for the ODUk layer network, management
plane can activate the TCM endpoint immediately. It isn't important that
there is no signal yet connected to it, like it isn't important for a
path termination point that it is not the endpoint of a path yet. So in
this case, the control plane has only to assign the appropriate values
to the other MI_XXX signals (like MI_ExTI, see annex % of my ASTN layer
network architecture document).

Regards,

Maarten

Alan J Weissberger wrote:
> 
> Hi Martin
> 
> Agree with your comment below, but what primitives/ parameters are passed
> between planes to facilitate TCM activation/ de-activation
> 
> Wouldn't it be possible to activate TCM sesstions in the core of the network in
> advance?  That would speed up the complete provisioning process
> 
> Are you going to Caracas meeting?
> 
> alan W
> 
> Quoting Maarten Vissers <mvissers@lucent.com>:
> 
> > Alan,
> >
> > Concerning your 3rd item (TCM activation), the control plane should be
> > able to control this also for the case of SPCs and SCs. The control
> > plane will also have to control the TCM endpoint related MI_XXX
> > parameters.
> >
> > Regards,
> >
> > Maarten
> >
> > 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