[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Hello Grant et al,

I think the statement you add should be commented by carriers
and providers as well since related to the "applicability" of this 
features within "operational networks". It would be interesting if 
Monica, Eric Mannie and others could raise their opinion on this 
issue as well.

Many thanks,
Dimitri.

"Grant W. Cyboron" wrote:
> 
> I have been following this thread for the past several days but have not
> added anything to it because I have been inactive in standards for the
> past 4 years. Prior to that I contributed to T1X1.5 and chaired it from
> 1991 to 1995. I think that to be complete your footnote would actually
> have to read (I carried on with your capital letters although I do not
> think they are really necessary):
> 
> "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. THEREFORE ONE SHOULD ONLY EXPECT THEM TO
> BE OPERABLE IN A NETWORK CONTAINING A SINGLE VENDOR'S EQUIPMENT OR
> THROUGH NEGOTIATIONS BETWEEN NETWORK OPERATORS AND THEIR VENDORS. THEY
> WILL NOT BE OPERABLE BETWEEN ADMINISTRATIVE DOMAINS."
> 
> Grant Cyboron
> 
> |-----Original Message-----
> |From: Dimitri Papadimitriou [mailto:dimitri.papadimitriou@alcatel.be]
> |Sent: Thursday, May 24, 2001 6:27 AM
> |To: Zhi-Wei Lin
> |Cc: John Drake; 'Lazer, Monica A, NNAD'; 'Heiles Juergen'; 'Mannie,
> |Eric'; 'Fong, Man Wing'; 'Bernstein, Greg'; 'Bala Rajagopalan';
> |ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> |Subject: Re: [T1X1.5] RE: Proposed text for the concatenation
> |
> |
> |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