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

Re: {Spam?} Re: Final draft of response to the OIF

Hi Dimitri,

Dimitri.Papadimitriou@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@psg.com] Sent:
>>> Wednesday, August 31, 2005 2:38 PM
>>> To: Mack-Crane, T. Benjamin
>>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; ccamp@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
>> ============================================================
>>
>>
>> .
>>
>