Subject: Re: Final draft of response to the OIF

From: [email-masked]
Date: Thu, 1 Sep 2005 12:18:30 +0200

hi,

> Hi Dimitri,
>
> 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 ?

> 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

" Super rates services are mapped into and transported as STS-Nc SPE [N=3X there X = 1, 4, 16, 64 or 256]"

this is exactly what we used in RFC 3946

thanks and good bye

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:[email-masked]] Sent:
>>> Wednesday, August 31, 2005 2:38 PM
>>> To: Mack-Crane, T. Benjamin
>>> Cc: Adrian Farrel; Richard Rabbat; Huub van Helvoort; [email-masked]
>>> 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
>> ============================================================
>>
>>
>> .
>>
>

---

From: Huub van Helvoort <[email-masked]>
Date: Thu, 01 Sep 2005 12:46:33 +0200

Hello Dimitri,

You quoted T1.105:

--8<-- snipped

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

Somehow you left out the last part between the square brackets:
"or SDH VC-4 or VC-4-Xc, where X=N/3]"

This clearly means that an STS-3c == VC-4 == super rate of STS-1.

-- 
================================================================
              http://www.gironet.nl/home/idefiks/
              http://members.chello.nl/hhelvoort/
================================================================
Always remember that you are unique...just like everyone else...

---

From: Bert Klaps <[email-masked]>
Date: Thu, 01 Sep 2005 16:16:32 +0200

Hi Dimitri,

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

> you will that your interpretation is not the one specified in this 

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

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

Regards,
Bert Klaps