Subject: RE: Final draft of response to the OIF

From: "Mack-Crane, T. Benjamin" <[email-masked]>
Date: Thu, 1 Sep 2005 09:26:34 -0500

Dimitri,
 
The control plane is intended to control the data plane, not the naming
of data plane signals in various standards.  The fact that two names are
used in SONET and SDH for the same data plane signal is not
justification for creating two encodings in the control plane.
 
This should be a simple thing to fix, if we (CCAMP) are willing to fix
it.
 
Regards,
Ben

________________________________

	From: [email-masked] [mailto:[email-masked]]
On Behalf Of [email-masked]
	Sent: Thursday, September 01, 2005 6:53 AM
	To: Huub van Helvoort
	Cc: [email-masked]; [email-masked];
[email-masked]; Adrian Farrel; [email-masked]
	Subject: Re: Final draft of response to the OIF

	huub, 
	
	> > > 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]"
	>
	> 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.

	indeed but we are not discussing this issue or put this
"equivalence" under questioning (in fact this is reproduced in the
signal type 6 definition) the RFC took as logic (control plane) to set
the RCC value when the notation of the signal included a "c" we could
have created yet another exception but we did not - for several reasons
-

	> > this is exactly what we used in RFC 3946

	--
	================================================================

http://www.gironet.nl/home/idefiks/
				http://members.chello.nl/hhelvoort/

	================================================================
	Always remember that you are unique...just like everyone else...

============================================================
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: Greg Bernstein <[email-masked]>
Date: Thu, 01 Sep 2005 10:34:50 -0700

Concur with Ben and Huub.  This is also why all current framer chips 
support both SONET and SDH.  STS-3c == VC-4.
Greg B.

Mack-Crane, T. Benjamin wrote:

> Dimitri,
>  
> The control plane is intended to control the data plane, not the 
> naming of data plane signals in various standards.  The fact that two 
> names are used in SONET and SDH for the same data plane signal is not 
> This should be a simple thing to fix, if we (CCAMP) are willing to fix it.
>  
> Regards,
> Ben
>
>     ------------------------------------------------------------------------
>     *From:* [email-masked] [mailto:[email-masked]]
>     *On Behalf Of [email-masked]
>     *Sent:* Thursday, September 01, 2005 6:53 AM
>     *To:* Huub van Helvoort
>     *Cc:* [email-masked]; [email-masked];
>     *Subject:* Re: Final draft of response to the OIF
>
>     huub,
>
>     > > > with N=3X and X=4,16,64,... which explains the coding with a
>     STS-3c SPE
>     > > > 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
>     > >
>     > Somehow you left out the last part between the square brackets:
>     > This clearly means that an STS-3c == VC-4 == super rate of STS-1.
>
>     signal type 6 definition) the RFC took as logic (control plane) to
>     set the RCC value when the notation of the signal included a "c"
>     we could have created yet another exception but we did not - for
>     several reasons -
>
>

---

From: "Adrian Farrel" <[email-masked]>
Date: Sun, 4 Sep 2005 17:04:55 +0100

OK.

So I see two questions here.

1. What is meant by RFC3946?
2. Do we want to change what is said by RFC3946?

Question 1 appears to be the question that was asked by the OIF. I think
we have a clear answer. I think some people are not happy with this
answer, but that feeds into question 2. My understanding of the answer to
question 1 is based on the input from the editors of the RFC and reading
the CCAMP archive. Thus, the response to the question from the OIF is as
follows:

   This question about RFC 3946 was raised informally on the CCAMP
   mailing list at the start of March this year.

   Even when the signal Type value is the same (i.e. value 6) the
   NCC, RCC and NVC values depend on the specific signal being
   requested.

   From the examples in the annex we have...

     A VC-4 signal is formed by applying the following
     settings to a VC-4 Elementary Signal.
        RCC = 0
        NCC = 0
        NVC = 0
        MT  = 1
        T   = 0

     An STS-3c SPE signal is formed by applying the
     following settings to an STS-3c SPE Elementary
     Signal.
        RCC = 1 (standard contiguous concatenation)
        NCC = 1
        NVC = 0
        MT  = 1
        T   = 0

   Your question probably arises from the two notes and subsequent
   paragraph in section 2.1 or RFC 3946. Here it says...

     Note 1: when requesting a SONET STS-Nc SPE with N=3*X, the
       Elementary Signal to use must always be an STS-3c_SPE signal
       type and the value of NCC must always be equal to X.  This
       allows also facilitating the interworking between SONET and
       SDH.  In particular, it means that the contiguous
       concatenation of three STS-1 SPEs can not be requested because
       according to this specification, this type of signal must be
       coded using the STS-3c SPE signal type.

     Note 2: when requesting a transparent STS-N/STM-N signal
       limited to a single contiguously concatenated STS-Nc_SPE/
       VC-4-Nc, the signal type must be STS-N/STM-N, RCC with flag 1
       and NCC set to 1.

       The NCC value must be consistent with the type of contiguous
       concatenation being requested in the RCC field.  In particular,
       this field is irrelevant if no contiguous concatenation is
       requested (RCC = 0), in that case it must be set to zero when
       sent, and should be ignored when received.  A RCC value
       different from 0 must imply a number of contiguous components
       greater than 1.

   This final sentence should read "greater than or equal to 1," and
   was mistyped in the RFC. This change resolves all of your questions
   and makes the text consistent with the examples.

   The CCAMP working group is discussing a revision to RFC 3946 to
   clarify the situation.

Question 2 is a different issue. Quite a few people have stated that they
believe that RFC 3946 with its current interpretation by the editors,
should be changed. At the moment I do not see consensus on this issue and
frankly I do not see any weighty reason to change although if the
community shows consensus in favor of a change, that would be fine *if*
someone does the work.

My observations on this point are as follows.

a. This is control plane code. It is definitively not
   relevant to any interworking in the data plane. So
   long as it is written down clearly, *any* unambiguous
   control plane encoding is adequate.

b. Even if the data plane signal is identical, there may
   be value in distinguishing between the SDH and SONET
   origins of the signal.

c. We MUST support existing implementations. That means
   that whatever encoding rules we end up with, we MUST
   continue to support the receipt of existing encoding.
   It seems to me that this dilutes the purpose of any
   change.

d. Regardless of the definition of the signal encodings,
   and regardless of whether fields with the same names
   are used in the definition of those signals, I find
   the textual descriptions of NCC and RCC in RFC 3946
   unambiguous in English. It may be that those
   descriptions should be changed (or perhaps the names
   of the fields should be changed?).

e. At the end of the day you are arguing about whether
   there is a difference between:
   - "I would like a shoal of fish, with just one fish
      in the shoal."
   and
   - "I would like just one fish"
   Do you really have time for this debate?

f. Changing an RFC does not just happen through email
   exchanges. Someone has to do the work. If no-one does
   the work, it is clear to the chairs how much people
   care about the issue.

Thanks,
Adrian