[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [T1X1.5] Re: : ASTN Layer Network Architecture- Co-ordiantion between Control & Mgt Planes
The interaction between control and management plane isn't defined yet (See the ongoing discussion). It is questionable for me if the traditional error performance and availability parameters are usefull for switched networks.
The ITU is working on G.optperf "Error and availability performance parameters and objectives for international paths within the Optical Transport Network (OTN)". I will sent you a copy directly.
Juergen
> -----Original Message-----
> From: Richard W. Tibbs [SMTP:rtibbs@opnet.com]
> Sent: Friday, May 18, 2001 12:14 AM
> To: Maarten Vissers
> Cc: Alan J Weissberger; Tammy.Ferris@mail.sprint.com; ssnarayanan@lucent.com; zwlin@lucent.com; ccamp@ops.ietf.org; t1x15@t1.org; tsg13q10@itu.int; tsg15q12@itu.int; tsg15q14@itu.int
> Subject: [T1X1.5] Re: : ASTN Layer Network Architecture- Co-ordiantion between Control & Mgt Planes
>
> I am looking at failure/restoration issues in SDH/Sonet and optical.
> I am familiar with G.821, G.822 and G.826 which define delineation of available state
> for a link,
> and G.805/803/872.
> I am wondering several things, and any pointers in the right direction are
> appreciated:
> 1) Upon Mgmt plane deciding whether a link (trail, etc.) is down (e.g. via 10 SES per
> G.826) where is the interaction with the control plane defined in the ITU and/or IETF
> standards?
> 2) What are the relevant ITU specs for optical for availability "declaration" as well
> as mgmt-ctrl plane interaction? (G.8xx is for SDH/Sonet, but there seems to be a
> separate O.xxx series emerging.)
>
> Thanks very much all. >>>> RWT
>
> Maarten Vissers wrote:
>
> > 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
>
> --
> Come to the networking industry's premier conference,
> OPNETWORK 2001 August 27 - August 31
> (http://www.opnet.com/opnetwork2001/home.html)
> and to OPNET's cutting-edge seminars
> (http://www.opnet.com/seminars.html)
> << File: Card for Richard W. Tibbs >>