RE: Proposed text for the concatenation

["Mannie, Eric" <Eric.Mannie@ebone.com>]

Hello Man Wing, Bala and All,

>I think Eric's proposed text gives a very good coverage on all cases

Thanks :-)

>and all we need is indicating which field is ... optional

Indeed everything is already optional in the draft except the signal type of
course:

  - CCT: set to zero to say no contiguous concatenation requested (default
value)
  - NCC: set to zero when CCT is set to zero (default value)
  - NVC: set to zero to say no virtual concatenation (default value).
  - Multiplier: set to one if one instance (default value).
  - transparency: set to zero to say don't care (default value).

So there is no issue there, I will add a specific paragraph to re-enforce
it.

In addition, when a downstream node receives an "incoming request" he can
decide to accept it or to refuse it depending of what is requested,
depending of the CAC process, depending of the customer profile, depending
of the capabilities that it supports, etc.

The draft doesn't indicate what must be implemented of course.

>and all we need is indicating which field is standard....

Ok, I agree. Let's indicate in the draft the features that are not
standardized in G.707 and T1.105, i.e. arbitrary concatenation, flexible
concatenation, and transparency. Is there another one ? All the signal types
have an equivalent definition in the standards.

--- proposed new section:

X. Relationship with SDH and SONET standards

Some of the features described in this specification are not defined neither
in ANSI T1.105 (1995 and 2000), nor in ITU-T G.707 (1996 and 2000). However,
these features are useful and implemented in many equipment's. All these
features are optional but can be controlled using this specification.

These features are: arbitrary contiguous concatenation, flexible arbitrary
contiguous concatenation and transparency. They have been described in the
relevant sections of this specification.

Arbitrary contiguous concatenation does not need any additional standard to
interoperate. It simply relaxes some limitations specified in the
corresponding AINSI and ITU-T standards.

Transparency does not need any standard at the UNI since it is only
implemented in the data plane at the NNI. This can be requested using the
signaling at the UNI, independently of its implementation at the NNI.
Interoperability between multiple manufacturers at the NNI can be achieved
in different ways: through the use of a standard, an implementation
agreement made by a forum, or an implementation agreement between two
manufacturers (e.g. at the request of an operator).

Flexible arbitrary contiguous concatenation just need a very simple and
obvious agreement to interoperate between multiple manufacturers. Again this
can be achieved in different ways: through the use of a standard, an
implementation agreement made by a forum, or an implementation agreement
between two manufacturers (e.g. at the request of an operator). A simple
agreement could for instance simply indicate where is copied the original
path overhead when "inverse multiplexing" locally a contiguously
concatenated signal (e.g. in the first VC/SPE POH). --- I am not sure at all
about this paragraph, ideas are welcome, please help !

---------- End of text

Agreed ? Comments ?

Comments from our ITU-T folks are welcome (really :-)

Kind regards,

Eric

-----Original Message-----
From: Fong, Man Wing [mailto:MFong@WhiteRockNetworks.com]
Sent: Tuesday, May 22, 2001 5:15 PM
To: 'Bernstein, Greg'; Mannie, Eric; 'Maarten Vissers'
Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com
Subject: RE: Proposed text for the concatenation


Very good point, Greg. If I remember correctly, the initial email initiated
such a great discussion was someone asked about whether it was worth
investing development effort on arbitrary concatenation. The bottom line is
if there is an appearing business case for the feature, then you will
support it. As some of you (vendors) already indicated that your systems
support AC because there are operators using and asking for this feature.
There might be a lot of vendors and users supporting this or might be just a
few, but the fact is there are someone supporting it. When defining new
protocols, I agree that we should consider and cover all cases, as long as
any non-standard fields are optional.
I think Eric's proposed text gives a very good coverage on all cases and all
we need is indicating which field is non-standard and optional.

Man Wing