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

[Zhi-Wei Lin <zwlin@lucent.com>]

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
> >
> >