Re: {Spam?} Re: Final draft of response to the OIF
Bert Klaps <bertk <at> txc.com>
2005-09-01 14:16:32 GMT
Hi Dimitri,
Dimitri.Papadimitriou <at> alcatel.be wrote:
> > Note 2 refers to transparent STS-N/STM-N signals only (signal types 7
> > through 12), OIF is requesting clarification on the coding of STS-3c SPE
> > versus VC-4 (both signal type 6).
>
> yes, i noticed 
this was not the purpose of my first comment
>
> > Since VC-4 == STS-3c SPE it should be possible to swap both terms
> > without making a technical change which is not the case for examples 1
> > and 8. Any such difference is confusing and a potential interworking
> > problem.
>
> so you can flexibily swap between local configuration and not have that
> flexibility in the control plane ?
This way the control plane will make a distinction
which is not present in the data plane and therefore will confuse.
> > Standard contiguous concatenated STS-Nc SPE is actually STS-3c-Xc SPE
> > with N=3X and X=4,16,64,... which explains the coding with a STS-3c SPE
> > elementary signal and NCC=X. So we code the STS-Nc SPE and VC-4-Xc
> > identical (examples 3 and 9) but not their base signal ?!?...
>
> i refer you to section 7.3.1 of ANSI T1.105 - 2001 (aka SONET base spec)
> you will that your interpretation is not the one specified in this
> recommendation
Er, I'm quite familiar with the contents of T1.105-2001
That content doesn't change my observations about the signal structure
above.
Note that T1.105 at multiple locations states the VC-4 == STS-3c SPE
equivalence. E.g. from the definitions:
3.5 "The equivalent SDH term for an STS-3c SPE is a VC-4.
The equivalent SDH term for an STS-Nc (N>3) SPE is a VC-4-Xc,
where X=N/3."
or,
3.73 "A VC-4 is equivalent to an STS-3c SPE,
and a VC-4-Xc is equivalent to an STS-Nc (N=3X) SPE."
> " Super rates services are mapped into and transported as STS-Nc SPE
> [N=3X there X = 1, 4, 16, 64 or 256]"
This is a list of signal names with a "c" in them, as you put it.
You have to look at the figures to understand the signal structure
and how they relate to each other, which was my point.
Also from 7.3:
"Two methods for concatenation are defined; contiguous and virtual
concatenation. Both methods provide concatenated bandwidth of X times
the SPE payload capacity at the path termination."
A STS-Nc SPE has a payload capicity of X times the payload capacity
of a STS-3c SPE with N=3X.
However a STS-Nc SPE does _not_ have a payload capacity of N times
the payload capacity of a STS-1 SPE, not even for N=3...
> this is exactly what we used in RFC 3946
Regards,
Bert Klaps
> dimitri papadimitriou wrote:
> > ben,
> >
> > the purpose of the sentence you were initially pointing out addresses as
> > generic rule more than the specific case under discussion (reason why i
> > pointed to this note 2) from the initial clarification asked by the OIF
> > - ditto
> >
> > "Clarification is requested from IETF CCAMP as to which setting is
> > considered correct, or if both settings should be accepted (this
> > procedure was used during testing at Supercomm)."
> >
> > hence, any further discussion is involving much more than the requested
> > clarification since questioning the logic behind the settings specified
> > in this RFC; as these are pure conventions we may debated them forever,
> > however, it suffice that one logic gets consensus (with all what it
> > implies), which is the case otherwise this would have not become an RFC
> >
> > ---
> >
> >
> > Mack-Crane, T. Benjamin wrote:
> >
> >> Dimitri,
> >>
> >> Note 2 on page 6 refers to transparent mode, which is a
> >> different thing altogether. I think this encoding is
> >> poorly chosen as well (and may not allow for the full
> >> flexibility of equipment that provides various levels
> >> of transparent STS-N/STM-N switching), but that is not
> >> currently under discussion.
> >>
> >> Regards,
> >> Ben
> >>
> >>> -----Original Message-----
> >>> From: dimitri papadimitriou [mailto:dpapadimitriou <at> psg.com] Sent:
> >>> Wednesday, August 31, 2005 2:38 PM
> >>> To: Mack-Crane, T. Benjamin
> >>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort;
> ccamp <at> ops.ietf.org
> >>> Subject: Re: Final draft of response to the OIF
> >>>
> >>>
> >>> to clarify:
> >>>
> >>>
> >>>> The example did not adhere to the rule RCC=1 implies NCC>1
> >>>> which was stated in the RFC (and is technically sound) thus
> >>>> one could reasonable presume the example was in error.
> >>>
> >>>
> >>> actually your interpretation is not correct - see note 2 of RFC 3946
> >>> (page 6) where the settings RCC=1 can imply NCC=1 is explicitly
> stated -
> >>>
> >>> this said, one of the reason for this setting wrt the specific point
> >>> raised by the OIF is due to the logic that has been used in making
> >>> use of RCC and NCC value when the signal spelling include a "c" i.e.
> >>> STS-(3xN)c SPE so for STS-3c SPE the setting is a logical consequence
> >>> of N = 1
> >>>
> >>> however, editors have been using a wording for the generic rule which
> >>> has not been understood as expected hence the clarification stated
> >>> last march on this list - and reproduced in the bis version -
> >>>
> >>> in brief, all this doesn't deserve this flurry of e-mails wrt to the
> >>> specific point to be addressed
> >>>
> >>>
> >>>
> >>>
> >>
> >> ============================================================
> >> The information contained in this message may be privileged
> >> and confidential and protected from disclosure. If the reader
> >> of this message is not the intended recipient, or an employee
> >> or agent responsible for delivering this message to the
> >> intended recipient, you are hereby notified that any reproduction,
> >> dissemination or distribution of this communication is strictly
> >> prohibited. If you have received this communication in error,
> >> please notify us immediately by replying to the message and
> >> deleting it from your computer. Thank you. Tellabs
> >> ============================================================
> >>
> >>
> >> .
> >>
> >
>
RSS Feed