RE: ASON reqts

["Varma, Eve L (Eve)" <evarma@lucent.com>]

Hi,

I'll give you one example - clarifications related to the discussion of domains, interfaces, and reference points, which has been at the heart of many a discussion.  This clarification comes from G.8080 Amendment 1, and is extremely helpful in understanding the concept and its applicability.

Specifically, some additional text is needed to expand upon the
discussion of reference points & domains in the second paragraph of "Problem Statement", reproduced below:
"The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various
networking environments (e.g., inter-carrier, intra-carrier). Also, ASON model distinguishes reference points (representing points of protocol information exchange) defined (1) between an administrative domain and a user (2) between administrative domains and (3) between areas of the same administrative domain and when needed between control components (or simply controllers) within areas. A full description of the ASON terms and relationship between ASON model and GMPLS protocol suite may be found in [IPO-ASON]."

The proposed expanded text is as follows:

"The ASON control plane specification is meant to be applicable to different transport technologies (e.g., SDH/SONET, OTN) in various networking environments, and to support a range of business models. As Automatically Switched Optical Networks (ASONs) are deployed into new and existing networks, it cannot be assumed that such networks will be homogeneous (e.g., with respect to transport technologies, vendors, approach to management/control). This is true even within a single carrier's network. In order to support deployment of an optical control plane into a heterogeneous environment, the ASON model introduces the concept of control domains and associated inter- and intra-domain reference points.

A control domain is an architectural construct that provides for encapsulation and information hiding, with the characteristics of the control domain identical to those of its constituent architectural components. The UNI and E-NNI reference points are defined to exist between control domains, while the I-NNI reference point is defined as existing within a control domain. The nature of the information exchanged between control domains across the E-NNI reference point captures the common semantics of the information exchanged amongst its constituent components, while allowing for different representations inside each control domain. The reference points are realized as interfaces when instantiated by signaling and routing protocols as appropriate (i.e., no routing information is exchanged over the UNI reference point).  Further description of the ASON model and GMPLS protocol suite may be found in [IPO-ASON]".

Eve

-----Original Message-----
From: Adrian Farrel [mailto:afarrel@movaz.com]
Sent: Monday, May 12, 2003 7:09 PM
To: Stephen Trowbridge; John Drake
Cc: 'Wijnen, Bert (Bert)'; Kireeti Kompella; ccamp@ops.ietf.org
Subject: Re: ASON reqts


> Back to Bert's original questions:
> > > > > - is there or do we see any conflict?
> - As Zhi said, this is not (yet) fully aligned with ITU-T requirements
>   and should not be advanced to a WG document until it is. However, before
>   we do, I think we need to understand why this is necessary - see below.

Notwithstanding the immediate future of this document (WG or not WG) I would
greatly appreciate a summary of the areas that are deficient.

Thanks,
Adrian