Re: [T1X1.5] RE: Proposed text for the concatenation

[Dimitri Papadimitriou <dimitri.papadimitriou@alcatel.be>]

Dear all,

So we could add the following text to the proposed sentence (in 
capital letters) - see previous e-mail - :

"Some of the features described in this specification are not defined
either in ANSI T1.105 (1995 and 2000), or in ITU-T G.707 (1996 and 
2000) OR IN ANY OTHER APPROVED DOCUMENT COMING FROM STANDARDIZATION 
BODIES DEALING WITH SONET/SDH." 

If this applies for the corresponding feature then the footnote could
be aligned with this text as well.

Kind regards,
Dimitri.

Zhi-Wei Lin wrote:
> 
> Hi John,
> 
> Yes, The signalling can be compliant to GMPLS. But what would that mean
> for compliance of the transport network?
> 
> As I mentioned a while back, interworking is needed in two levels,
> signalling interworking AND transport interworking.
> 
> Signalling interworking can be fairly easy I think. Transport
> interworking would be hard, because of all the physical layer aspects
> that needs to be considered. If we're not familiar with what these
> aspects are, then I guess we cannot and should not be making decisions
> and let the experts do it...
> 
> As for "multiple standards bodies", yes there are more than one
> standards bodies working on this, but they all work TOGETHER and align
> with each other, and the folks working on this are experts in the area
> who's been in the industry for MANY years. ANSI document specifies
> SONET. So does Telcordia GRs. ITU Recommendation specifies SDH. So does
> ETSI specs.
> 
> Zhi
> 
> John Drake wrote:
> >
> > Monica,
> >
> > When you say standards compliant, which standards bodies are you
> > considering?  I.e., from one of Eric's
> > notes I got the impression that there were actually multiple bodies that had
> > defined SONET/SDH features.
> > Further, we could indicate that implementations of GMPLS signalling are are
> > GMPLS compliant - see 'self
> > defining term' in the index of Knuth vol 1.
> >
> > Thanks,
> >
> > John
> >
> > -----Original Message-----
> > From: Lazer, Monica A, NNAD [mailto:mlazer@att.com]
> > Sent: Wednesday, May 23, 2001 1:42 PM
> > To: 'Heiles Juergen'; 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein,
> > Greg'; 'Bala Rajagopalan'
> > Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> > Subject: RE: [T1X1.5] RE: Proposed text for the concatenation
> >
> > From an operator's perspective, it is essential to clearly flag the features
> > that are standards compliant from those, which deviate from existing
> > standards, even when they are improvements to the standards. The reason for
> > this is rooted in the need to have the ability to identify all the relevant
> > issues when inter-working network elements from multiple vendors in the same
> > networks, while taking advantage of new non-standard features.
> >
> > Monica A. Lazer
> > Advanced Transport Technology and Architecture Planning
> >
> > 908 234 8462
> > mlazer@att.com
> >
> > -----Original Message-----
> > From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
> > Sent: Wednesday, May 23, 2001 8:57 AM
> > To: 'Mannie, Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> > Subject: [T1X1.5] RE: Proposed text for the concatenation
> >
> > The concatenation waves are going high here on the mailing list.
> > I attended the Paris editing session and didn't complain about the
> > proprietary solutions.
> > However the ongoing discussion showed me several points:
> > - When we start to introduce one proprietary solution we open the document
> > for any proprietary solution, where will we stop (I want B3 transparency and
> > I over connection setup for containers (without POH)? Do we really want to
> > define the signaling support for single, two, three vendor solutions. I
> > would leave this to the vendors. They implemented a proprietary transport
> > plane solution so they can also define their proprietary control plane
> > solution. If we have a broader interest in the feature we should look at the
> > application and consider if it should be standardized both for the transport
> > plane and the control plane.
> > - Remember that we define the control in order to support the transport
> > plane and not vice versa. A stand alone transport plane makes sense (and has
> > been in use for years), a stand alone control plane doesn't. Interworking at
> > the control plane doesn't help much if the transport plane doesn't
> > interwork. So it should be a common standardization activity both in the
> > control and in the transport plane.
> > - If we define something proprietary we need information about the feature,
> > we cannot do it with guesses.
> > - We also have to be careful with proprietary features as we don't know what
> > implications they have on the transport plane, they might exclude each
> > other. That can happen as we focus only on the control plane and don't care
> > about the implications at the transport plane. We can generate a real mess.
> > - I don't want to restrict new ideas and developments. Actually you cannot
> > kill a good solution that fits network needs by blocking it from a standard.
> > If someone builds it and shows its advantages operators will start to ask
> > for it.
> >
> > Now coming to Erics new proposed section:
> > In my view the proposal makes it even worse. Just say this is a standard
> > feature and this is a proprietary feature. Don't start to explain how we can
> > come form a proprietary  feature to interworking or a standard. And don't
> > start to explain how the feature could be implemented. It will bring you
> > into more trouble. This is a control plane document, nothing more.
> >
> > Arbitrary contiguous concatenation:
> > What are the relaxed limitations. Either say nothing or define it in detail,
> > but the later is not the task of this document.
> >
> > Transparency:
> > RS and MS transparency is a standard feature, while transparency of
> > individual overhead bytes is not. You have to distinguish between the two.
> > Transparency of individual bytes is an critical issue. You violate the
> > layers and can screw up your whole management. In addition it is not real
> > transparency what is needed, it is functional transparency. For example for
> > B2. Or for the DCC bytes you might allow byte slips. But what implications
> > has this on the DCN? It is easy to define a feature for the control plane
> > and don't care about the transport plane implications.
> > Although you are a strong supporter of transparency, you were very fast in
> > dropping the already included B2 transparency. Because it is not a straight
> > forward solution? Requires some awkward processing? And some people don't
> > understand how it works? That might be also true for other features
> > (flexible arbitrary concatenation). So why include one and not the other?
> >
> > Flexible arbitrary contiguous concatenation:
> > You started to describe a implementation. You have a certain solution in
> > your mind. I think about a completely different approach. We both don't know
> > it exactly, we just guess. Is this a good base to achieve interoperability.
> > One problem I see has to do with the AUG7STS Group signal type, another
> > proprietary feature. The AUG/STS group signal type provides some
> > transparency concerning the underlying VC-3/4/4-Xc structure. However as
> > pointer processing for the individual VCs is still required in case of
> > multiplexing the network elements have to detect the VC-N structure by
> > themselves using the pointer information (valid pointer, concatenation
> > indication). But this doesn't work with flexible arbitrary contiguous
> > concatenation, at least with the solution I have in mind. Additional
> > information on the VCs that belong together is needed in-band (SOH?) if
> > automatic detection should be supported. If it is not supported it cannot be
> > part of a AUG/STS group signal type while all other types of concatenation
> > can be. If it is supported you might not need a label set. A label for the
> > first time slot is enough. The network element detects which other belong to
> > the group. So from the currently available informatio!
> > !
> > !
> > n it is difficult to tell if the control plane support is correct.
> > One other question. The Sonet/SDH GMPLS document says that virtual
> > concatenation can be used with any contiguous concatenation. Although with
> > flexible arbitrary contiguous concatenation as both require a label set?
> >
> > Coming back to the AUG/STS group and TUG. I missed it in your new proposed
> > section. It is a proprietary feature.
> > Dimitri mentioned that AUG-X is defined in G.707 but not supported in G.783.
> > It should be noted that AUG/TUG are not and were never intended to be
> > networking entities. They were introduced as internal signal structures in
> > order to better describe the SDH multiplex process. VC-11/12/2/3/4, MS and
> > RS are the networking entities.
> > A AUG/STS group or TUG provides some transparency concerning the underlying
> > VC-N structure. IF you multiplex the signal you still have to do pointer
> > processing for the individual VCs. As a AUG/STS group or TUG has no overhead
> > of its own, any supervision has to be performed on the individual VCs. So
> > what will it buy us ?(ok, ok better not to ask the question, some one
> > supports it and has its good reasons to do so as it is the case for any of
> > the above features)
> >
> > Regards
> >
> >         Juergen
> >
> > > -----Original Message-----
> > > From: Mannie, Eric [SMTP:Eric.Mannie@ebone.com]
> > > Sent: Tuesday, May 22, 2001 9:22 PM
> > > To:   'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan'
> > > Cc:   ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> > > Subject:      RE: Proposed text for the concatenation
> > >
> > > 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
> > >
> > >
begin:vcard 
n:Dimitri;Papadimitriou Dimitri
tel;home:+32 2 3434361
tel;work:+32 3 2408491
x-mozilla-html:FALSE
url:http://www.alcatel.com
org:Alcatel Bell;IPO NSG - Antwerpen 
version:2.1
email;internet:dimitri.papadimitriou@alcatel.be
title:Optical Networking R&S - Senior Engineer
adr;quoted-printable:;;Francis Wellesplein, 1=0D=0AB-2018 Antwerpen;;;;BELGIUM
fn:Papadimitriou Dimitri
end:vcard