[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Proposed text for the concatenation
Dimitri,
the SONET/SDH document says further on about AUG-N
"In addition any contiguous concatenation relationships between the
VC-3s or VC-4s in the AUG-N are preserved and are allowed to
change over the life of an AUG-N. It is this flexibility in the
concatenation relationships between the component virtual
containers that differentiates this signal from a set of VC-3s or
VC-4s. In addition whether the AUG-N is structured with AU-3s or
AU-4s does not need to be specified and is allowed to change over
time."
So you can change between VC-4, VC-4, VC-4-4c, VC-4-16c, ... and even from all VC-4 to VC-3 over time. So it is a kind of transparency for the signal type. The text is even confusing as VC-3 contiguous concatenation is not defined.
If it would be only VC-3 or VC-4 what would be the difference to a multiplier which also allows to setup several VC-3/4.
By the way I didn't miss TUG. As I said I wasn't concerned about the proprietary definitions until the ongoing discussion.
Regards
Juergen
> -----Original Message-----
> From: Dimitri Papadimitriou [SMTP:dimitri.papadimitriou@alcatel.be]
> Sent: Wednesday, May 23, 2001 5:04 PM
> To: Heiles Juergen
> Cc: ccamp@ops.ietf.org; ip-optical@lists.bell-labs.com; t1x1.5; q11/15
> Subject: Re: Proposed text for the concatenation
>
> Hello Juergen,
>
> Only two short remarks here on the AUG/STS-Group:
> - First, on relation with transparency, it is clearly indicated
> into the document:
> "Note as well that transparency is only applicable when using
> the following Signal Types (ST's): STM-1, STM-4, STM-16, STM-64,
> STM-256, STS-1, STS-3, STS-12, STS-48, STS-192, and STS-768. At
> least one transparency type must be specified when requesting
> such a signal type. NOT WITH AUG/STS-G"
> - Second it is clearly indicated into the document that:
> "Administrative Unit Group-N's (AUG-N's) are either a homogeneous
> collection of AU-3s or AU-4s. When used as a signal type this
> means that all the VC-3s or VC-4s in the AU-3s or AU-4s that
> comprise the AUG-N are switched together as one UNIQUE signal..."
>
> So, by taking care of cautiously defining the terms used in the
> document, we were convinced (by one of your itu-t colleagues) that
> introducing such kind of signal into the current document can
> increase it's utility (since TUG were already introduced at that
> time in the document it was a question of consistency as well
> so i am surprised on the fact you missed the TUG since they are
> referenced in the document since March 2001 so TUG were introduced
> prior to the last published version) since today he provides such
> kind of services - at that time the argument was "what can i do
> with gmpls if it doesn't cover any service covered today by our
> product !" - NB: now there is an informal 'agreement' with the
> referenced person to introduce the related material in order to
> propose itu-t specification alignment.
>
> Kind regards,
> Dimitri.
>
> Heiles Juergen wrote:
> >
> > 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 inform!
!
!
> at!
> > io!
> > !
> > !
> > 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
> > >
> > > << File: Card for Dimitri Papadimitriou >>