Subject: [CCAMP] I: Re: R: Poll on ODUFlex-related encoding

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Tue, 26 Feb 2013 09:39:20 +0000

Hi all,

As for Lou's suggestion please consider the answer below to Lou question (marked SB)

Thanks

BR

Sergio

Belotti Sergio-  System Architect

ALCATE-LUCENT  Optics Division

via Trento 30 Vimercate (MB) - Italy

phone +39 (039) 6863033

-----Messaggio originale-----
Da: BELOTTI, SERGIO (SERGIO)
Inviato: venerdì 8 febbraio 2013 18.50
A: Lou Berger
Cc: Daniele Ceccarelli; Fatai Zhang; BELOTTI, SERGIO (SERGIO)
Oggetto: R: Re: R: [CCAMP] Poll on ODUFlex-related encoding

Hi Lou,

While I'm not sure to have well understood what you really ask,

please see in line for my reply.

I do not know whether Daniele or Fatai can have more to add.

Hope this can help.

Cheers

Sergio

Belotti Sergio - System Architect

ALCATEL-LUCENT  Optics Division

-------- Original Message --------

Subject:    Re: R: [CCAMP] Poll on ODUFlex-related encoding

Date:       Wed, 06 Feb 2013 07:53:17 -0500

From:       Lou Berger <[email-masked]>

To:   BELOTTI, SERGIO (SERGIO) <[email-masked]>,

Daniele Ceccarelli <[email-masked]>, Fatai Zhang

<[email-masked]>

CC:   CCAMP <[email-masked]>

Sergio/Daniele/Fatai,

I think we all now clearly understand that the line/network/ODUk side of

ODUflex (CBR) needs to be allocated at 100ppm for AIS and other

maintenance signals to operate properly.  (Per note note 2 of table

7-2.) And that this means that nodes must allocate TSes based on the

tolerance implied by the signal type, per table 7-2.

But what about the client signal?  G.709 allows for lower/different

tolerance values per the same note and multiple other statements (search

for 'up to ±').

- Is the client signal still selectable by the equipment, or is it now

fixed?  If the latter, where is this change/restriction to G.709

documented? (Remember we/ccamp/ietf can't modify or limit the G.709 data

plane.)

SB> What it is really need is to have an adaptation between ODUflex (CBR) and the line (OTUk) on which map the flex container, able to manage a signal container with +-100 ppm tolerance. This is absolutely independent of the client.

Source and Sink have to be coordinated (I mean Tx and Rx) to manage this type of adaptation , while the client is with different tolerance this is not influence the TS allocation and so what we need to signal to permit the right TS allocation.

- Is it okay for two nodes to run their client adaptation at different

tolerance values?

SB> as above , the adaptation is the same independently of the client.

- Is it the client or line/ODUk signal tolerance that you are proposing

signaling?

SB> The tolerance is the tolerance of ODUflex (CBR) , that now we know is +-100ppm , but , for suggestion from Zafar, we say are now hard-coded to 100 but we leave the field to permit future flexibility.

On 2/6/2013 4:59 AM, BELOTTI, SERGIO (SERGIO) wrote:

> Ciao Daniele,

> Your understanding is correct : the only reference is G.709 2012 that reports fixed value of tolerance for ODUflex (CBR) dependent of the management of maintenance signal.

> The update of G.874.1 is a consequence of that. We can decide to write a "confirmation" to ITU along these lines.

If you mean, ask for confirmation of our understanding, this may be a

good idea.

Thanks,

Lou

> BR

> Sergio

> Belotti Sergio - System Architect

> ALCATEL-LUCENT  Optics Division

> -----Messaggio originale-----

> Da: Daniele Ceccarelli [mailto:[email-masked]]

> Inviato: mercoledì 6 febbraio 2013 10.43

> A: Fatai Zhang; Lou Berger

> Cc: CCAMP; [email-masked]; [email-masked]

> Oggetto: RE: [CCAMP] Poll on ODUFlex-related encoding

> Just to summarize since different editors will update the FWK, info model and encoding docs.

> We are going to reference only G.709 2012 (which has the updated text allowing only +/-100 ppm for ODUFlex) and not G.874.1 which needs to be updated accordingly.

> Should this be formalized via a Liaison?

> BR

> Daniele

>> -----Original Message-----

>> From: [email-masked] [mailto:[email-masked]]

>> On Behalf Of Fatai Zhang

>> Sent: mercoledì 6 febbraio 2013 3.07

>> To: Lou Berger

>> Cc: CCAMP; [email-masked];

>> [email-masked]

>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

>> Hi Lou,

>> Yes, we all agree that FWK and Info should be updated accordingly.

>> Best Regards

>> Fatai

>> -----Original Message-----

>> From: Lou Berger [mailto:[email-masked]]

>> Sent: Wednesday, February 06, 2013 10:05 AM

>> To: Fatai Zhang

>> Cc: John E Drake; Zafar Ali (zali); CCAMP;

>> [email-masked];

>> [email-masked]

>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

>> Fatai/Sergio,

>> G.709 has been stable for quite some time now.  I guess the

>> discussion on tolerance should have occurred once it was

>> stable (1-2 years ago) or whenever the change occurred the

>> obviated your original motivation for including tolerance in

>> the first place.

>> Note that the framework still says:

>>      Therefore, bit rate and bit rate tolerance should

>>      also be carried in the Traffic Parameter in the signaling of

>>      connection setup request.

>>      For other ODU signal types, the bit rates and tolerances of them

>>      are fixed and can be deduced from the signal types.

>> and the info draft says:

>>   6. Bit rate and tolerance

>>   In the current traffic parameters signaling, bit rate and tolerance

>>   are implicitly defined by the signal type.  ODUflex CBR and Packet

>>   can have variable bit rates and tolerances (please refer to

>> [OTN-FWK]

>>   table 2); it is thus needed to upgrade the signaling traffic

>>   parameters so to specify requested bit rates and tolerance values

>>   during LSP setup.

>> This text will be updated independent of the signaling format.

>> Lou

>> On 2/5/2013 8:24 PM, Fatai Zhang wrote:

>>> Hi Lou and all,

>>> I think Serge and I have pointed out very clearly that Table 7-2 in

>>> G.709 is sufficient (No need to reference to G.874.1, in which it is

>>> wrong to say that "Allowable values of this attribute are 20 and

>>> 100.there is an error that should be corrected", this error will &

>>> MUST be corrected in the next version of G.874.1).

>>> Please have a look at Table 2 in G.709 (02/2012) and the

>> Note 2. It says:

>>> Note 2 -The bit rate tolerance for ODUflex(CBR) signals is specified

>>> as 100 ppm. This value may be larger than the tolerance for

>> the client

>>> signal itself (e.g. ±20 ppm). For such case, the tolerance is

>>> determined by the ODUflex(CBR) maintenance signals, which

>> have a tolerance of 100 ppm.

>>> I hope my mail can clarify your concern.

>>> Note that I checked with the editor of G.709 before I said

>> that G.709

>>> is sufficent in the CCAMP list.

>>> Best Regards

>>> Fatai

>>> -----Original Message-----

>>> From: Lou Berger [mailto:[email-masked]]

>>> Sent: Wednesday, February 06, 2013 6:39 AM

>>> To: John E Drake

>>> Cc: Zafar Ali (zali); Fatai Zhang; CCAMP;

>>> [email-masked];

>>> [email-masked]

>>> Subject: Re: [CCAMP] Poll on ODUFlex-related encoding

>>> John,

>>> See question in-line below.

>>> On 2/5/2013 2:19 PM, John E Drake wrote:

>>>> Snipped, comment inline

>>>> Irrespectively Yours,

>>>> John

>>>>>>    0             1             2             3

>>>>>>   0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

>>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>>>  |  Signal Type  |       N       |        Reserved       |

>>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>>>  |              NVC           |      Multiplier (MT)     |

>>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>>>  |                      Bit_Rate                       |

>>>>>>  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>> I just wonder are we not better off keeping Tolerance field in

>>>>> signaling and adding a statement in v7 that this field is

>> hardcoded

>>>>> to

>>>>> 100ppm.

>>>>> This has advantage of interworking with earlier draft

>>>>> implementations

>>>>> and is also flexible for various (future/ unknown) client

>> signal types.

>>>>> I.e., we use the same encoding as defined thus far in the document

>>>>> (copying from

>>>>> v6):

>>>>>       0                   1                   2                   3

>>>>>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5

>> 6 7 8 9 0

>>>>> 1

>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>>      |  Signal Type  |       N       |           Tolerance

>>          |

>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>>      |              NVC              |        Multiplier

>> (MT)        |

>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>>      |                            Bit_Rate

>>          |

>>>>> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

>>>>> And state that Tolerance MUST be set to 100 ppm.

>>>> JD: This is a very good idea.

>>> Great.  Thanks for being clear on which option you support.

>>>> 'Per [G.874.1/2011] (or whatever is

>>>> the correct reference) Tolerance MUST be set to 100 ppm.'

>>> Is this correct (always 100ppm)?  Fatai/Sergio referred to table 7-2

>>> in

>>> G709 which has 20ppm for most signal types and 100ppm for

>> others.  And

>>> it seems there is some text that got dropped in the latest rev of

>>> G.874.1 (from and earlier amendment).

>>> In your role as ITU-T SG15 liaison manager, can you either figure out

>>> what the right text & reference should be or propose a

>> liaison that we

>>> can send asking the ITU-T for whatever information we need to close

>>> this

>>> issue/document?

>>> Thanks,

>>> Lou

>>>>> Thanks

>>>>> Regards...Zafar

>>>>>> <snip>

>>>>> _______________________________________________

>>>>> CCAMP mailing list

>>>>> [email-masked]

>>>>> https://www.ietf.org/mailman/listinfo/ccamp

>> _______________________________________________

>> CCAMP mailing list

>> [email-masked]

>> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Tue, 26 Feb 2013 09:15:05 -0500

Sergio,
	I think we're talking past each other.

The point I'm really trying to understand relates to the edge (ingress &
egress) equipment *only*.  We've killed the 100pps for transit
allocation, so no need to reopen that discussion.

WRT to the edge equipment: My question is basically do the
ingress/egress need to coordinate in some/any way on the tolerance being
run between it (i.e., the OTN termination equipment) and the client
equipment?

Recall that 709 *still* allows the tolerance to be less than 100ppm on
the actual client signal. For example, section 17.2 of G.709-2012 says:

  The mapping of a CBR2G5, CBR10G or CBR40G signal (with up to ±20
  ppm bit-rate tolerance) into an OPUk (k = 1,2,3) may be performed
  according to the bit-synchronous mapping procedure based on one
  generic OPUk frame structure (see Figure 17-1). The mapping of a
  CBR2G5, CBR10G or CBR40G signal (with up to ±45 ppm bit-rate
  tolerance) into an OPUk (k = 1,2,3) may be performed according to
  the asynchronous mapping procedure.

Given such options, and how equipment is being implemented, is there any
information that needs to be exchanged to ensure that the client signals
(and the adaptation performed by the edge equipment) are compatible (and
even using the same mapping procedures)?

For context, looking at:

 +------+    +----+    +----+    +----+    +------+
 |Client|----|ODXC|----|ODXC|----|ODXC|----|Client|
 +------+    +----+    +----+    +----+    +------+
    A          B         C         D          E

In context, my question can be rephrased as do B and D need too
coordinate in any way on the tolerance (or other) value used with the
client signals running between A-B and D-E in order to ensure/provide
client-to-client communication?

Thanks,
Lou

On 2/26/2013 4:39 AM, BELOTTI, SERGIO (SERGIO) wrote:
> SB>What it is really need is to have an adaptation between ODUflex (CBR)
> and the line (OTUk) on which map the flex container, able to manage a
> signal container with +-100 ppm tolerance. This is absolutely
> independent of the client.
> 
> Source and Sink have to be coordinated (I mean Tx and Rx) to manage this
> type of adaptation , while the client is with different tolerance this
> is not influence the TS allocation and so what we need to signal to
> permit the right TS allocation.
> 
>  
> 
> SB>as above , the adaptation is the same independently of the client.
> 
>  
> 
> SB>The tolerance is the tolerance of ODUflex (CBR) , that now we know is
> +-100ppm , but , for suggestion from Zafar, we say are now hard-coded to
> 100 but we leave the field to permit future flexibility.
> 
>  
>