Subject: Re: [CCAMP] TS in Signaling

From: Yechiel Rosengarten <[email-masked]>
Date: Mon, 1 Aug 2011 17:04:39 +0300

Hi,
IMHO, there is no need to signal end-to-end TSG and/or supported hierarchies.
These are link properties, that may be negotiated by its both ends.
The only thing that we have to know is the switching capability for each ODUj/k.
Each node knows to which ports it can connect the ODUj/k.

  Best Regards,

     Yechiel Rosengarten
     System Engineering
     ECI Telecom Ltd
     30 Hasivim St. Petach Tikva 49517
     Israel
     Tel:  +972 3 926 8794
     Fax: +972 3 926 6200
     e-mail: [email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Sent: Friday, July 29, 2011 6:13 PM
To: Lou Berger; John E Drake; CCAMP
Cc: CATR - Zhang Guoying
Subject: Re: [CCAMP] TS in Signaling

Hi Lou,

My 5 cents.

Let's try to reason from a purely logical point of view. There are two problems:

1) When setting up a LSP ensure that the two end-points are consistent in terms of TS granularity. With this respect G.709 provides just two adaptations. One adaptation has the effect to set TS granularity at 1.25,
the other one has the effect to set the TS granularity at 2.5.

If the requirements is only this a possible solution is defining new G-PIDs.

2) Ensure that the set of supported hierarchies is the same at both ends of the LSP. With this respect telling that a server supports a structured adaptation at 1.25 is not enough information.

If this is a requirement, signaling should also have the information about
the set of hierarchies that should be supported in order to enable the penultimate hop to choose correctly the interface.

Last but not least: it is true that signaling the set of hierarchies that
should be supported allows choosing the TS granularity in the sense that:

if signaled hierarchies contain an ODUj introduced with G.709v3 then the chosen interface must be able to support TSG=1.25.

If signaled hierarchies support only G.709 original ODUj then any TSG is OK.

This means that we could try to solve the points 1 and 2 together. But at this point it becomes not clear which value has to be inserted in G-PID.

Hope this clarify a little.

============================================
Pietro Vittorio Grandi
Terrestrial Optics Portfolio Evolution
Alcatel-Lucent Vimercate (Italy)
Tel: +39 039 686 4930
Mail: [email-masked]
============================================
Put your hand on a hot stove for a minute, and it seems like an hour.
Sit with a pretty girl for an hour, and it seems like a  minute. That's relativity.
(A. Einstein)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: venerdì 29 luglio 2011 16.41
To: John E Drake; CCAMP
Cc: CATR - Zhang Guoying
Subject: Re: [CCAMP] TS in Signaling

I think it would be worthwhile to get a tight definition of the
information that is needed to represent the mux capabilities of the
H-LSP end-points.  Once we have this, we can better understand how best
to communicate it.

So far, I've heard:
- all that is needed is TSG
- TSG is useless, need full muxing capabilities
- only need 1 muxing capability

Clearly these all can't be right.

Anyone care to take a try?

Thanks,
Lou

On 7/29/2011 9:57 AM, John E Drake wrote:
> Sergio,
>
> That would be fine with me.
>
> Thanks,
>
> John
>
> Sent from my iPhone
>
>
>> -----Original Message-----
>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-
>> lucent.com]
>> Sent: Friday, July 29, 2011 6:56 AM
>> To: John E Drake
>> Cc: CCAMP; CATR - Zhang Guoying; Ong, Lyndon
>> Subject: R: TS in Signaling
>>
>> John,
>>
>> I have just to confirm what kindly already answered by Jonathan.
>> I agree with Jonathan that TSG is an adaptation information. GPID it
>> could be a right place to put TSG information, moreover we can also
>> think to potential LO services to be supported by ODUk/OTUk or H-LSP/FA
>> , and in this case a new dedicated object could be a good solution
>> (aligned with Biao proposal) .
>>
>> Thanks
>> sergio
>>
>>
>>
>>
>>
>> -----Messaggio originale-----
>> Da: John E Drake [mailto:[email-masked]]
>> Inviato: venerdì 29 luglio 2011 15.05
>> A: BELOTTI, SERGIO (SERGIO)
>> Cc: CCAMP; CATR - Zhang Guoying; Ong, Lyndon
>> Oggetto: RE: TS in Signaling
>>
>> Sergio,
>>
>> Is it case that a hierarchical LSP can have its own TS size independent
>> of the TS sizes of the underlying links over which it is routed?  Lou
>> and I and, separately, Biao and I, had conversations yesterday in which
>> we concluded that the answer was yes, but I thought I should ask you as
>> well.
>>
>> If the answer is yes, then we are probably heading in a direction in
>> which TS size needs to be advertised in routing for both forwarding
>> adjacencies as well as ODUk/OTUk links, as TS size becomes an end-to-
>> end property of an LSP that needs to be checked during its
>> establishment.  (An LSP for certain values of j can still be
>> established over a path containing links with heterogeneous TS sizes.)
>>
>> I think this may re-affirm utility of the signal type proposal from
>> Lou, Fatai, and I from Wednesday.
>>
>> Thanks,
>>
>> John
>>
>> Sent from my iPhone
>>
>>> -----Original Message-----
>>> From: BELOTTI, SERGIO (SERGIO) [mailto:sergio.belotti@alcatel-
>>> lucent.com]
>>> Sent: Friday, July 29, 2011 12:04 AM
>>> To: John E Drake
>>> Cc: CCAMP; CATR - Zhang Guoying; Ong, Lyndon
>>> Subject: R: TS in Signaling
>>>
>>> Yes John,
>>>
>>> In principle you could have a board able to structure interfaces at
>>> 1.25 but the matrix not able to switch ODU0 .
>>>
>>> Thanks
>>> sergio
>>>
>>>
>>>
>>>
>>> -----Messaggio originale-----
>>> Da: [email-masked] [mailto:[email-masked]] Per conto
>> di
>>> John E Drake
>>> Inviato: giovedì 28 luglio 2011 20.06
>>> A: Ong, Lyndon
>>> Cc: CCAMP; CATR - Zhang Guoying
>>> Oggetto: Re: [CCAMP] TS in Signaling
>>>
>>> Lyndon,
>>>
>>> Is it possible for an ODUk/OTUk link to have a 1.25 TS size without
>>> offering an ODU0 switching capability?
>>>
>>> Thanks,
>>>
>>> John
>>>
>>> Sent from my iPhone
>>>
>>> On Jul 28, 2011, at 2:02 PM, "Ong, Lyndon" <[email-masked]> wrote:
>>>
>>>> Hi All,
>>>>
>>>> Is the TS size sufficiently implied by the advertisement of ODU0 as
>>>> a client?  I seem to recall some discussion about this a while
>> back.
>>>>
>>>> Cheers,
>>>>
>>>> Lyndon
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: [email-masked] [mailto:[email-masked]] On
>>>> Behalf Of John E Drake
>>>> Sent: Thursday, July 28, 2011 10:45 AM
>>>> To: John E Drake
>>>> Cc: CCAMP; CATR - Zhang Guoying
>>>> Subject: Re: [CCAMP] TS in Signaling
>>>>
>>>> Hi,
>>>>
>>>> I re-read yesterday's emails from Malcolm and Steve and it seems
>> that
>>>> having a node advertise the TS size of each of its interfaces is
>>>> useful for two reasons.
>>>>
>>>> 1) It allows the nodes at either end of an ODUk/OTUk link to
>> perform
>>>> the TS size determination in the control plane (Steve)
>>>>
>>>> 2) It allows the ingress node to compute a path containing links
>> with
>>>> the necessary TS size (Malcolm)
>>>>
>>>> Thanks,
>>>>
>>>> John
>>>>
>>>> Sent from my iPhone
>>>>
>>>> On Jul 27, 2011, at 6:07 PM, "John E Drake" <[email-masked]>
>>>> wrote:
>>>>
>>>>> This is certainly a red letter day; I agree with Steve.  Perhaps a
>>>>> medical check-up for both of us is advised.
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: Trowbridge, Stephen J (Steve)
>>>>>> [mailto:steve.trowbridge@alcatel-
>>>>>> lucent.com]
>>>>>> Sent: Wednesday, July 27, 2011 1:44 PM
>>>>>> To: Jonathan Hardwick; John E Drake
>>>>>> Cc: CATR - Zhang Guoying; CCAMP
>>>>>> Subject: RE: TS in Signaling
>>>>>>
>>>>>> Hi all,
>>>>>> I don't understand how there is ever a scenario where "the
>> operator
>>>>>> knows they need" is a criteria regarding TS size.
>>>>>>
>>>>>> From the perspective of the LO ODU, if you are transporting LO
>> ODU1
>>>>>> or
>>>>>> LO ODU2 over any combination of HO ODUk, these can be carried
>> over
>>>>>> either 1.25G or 2.5G TS capable HO ODUk. Different segments of
>> the
>>>>>> same
>>>>>> connection can have different TS granularities along the path -
>> it
>>>>>> doesn't matter. If your LO ODU is an ODU0 or ODUflex, clearly the
>>> HO
>>>>>> ODUk must be 1.25G TS structured, and as a practical matter, a LO
>>>>>> ODU3
>>>>>> mapped into a HO ODUk is only carried over 1.25G TS because ODU4
>>>>>> (and
>>>>>> presumably future larger ODUk) are only 1.25G TS structured. So
>> the
>>>>>> only "need" is that if you want to set up a LO ODU0, ODUflex, or
>>>>>> ODU3
>>>>>> connection, you need to find a route over 1.25G capable links. If
>>>>>> you
>>>>>> are setting up a LO ODU1 or ODU2, you can use either or both on
>>>>>> different segments of the connection.
>>>>>>
>>>>>> As far as the HO ODUk, the auto-negotiation ensures that if the
>>>>>> hardware on both ends is 1.25G TS capable, it will operate with
>>>>>> 1.25G
>>>>>> structuring, and if one (or both) ends can only support PT=20
>> 2.5G
>>>>>> TS
>>>>>> granularity, they fall back to that. There is no reason you would
>>>>>> ever
>>>>>> need to force 2.5G TS granularity if the HW on both sides can
>>>>>> support
>>>>>> 1.25G TS granularity, as a 1.25G structured HO ODUk can carry all
>>> of
>>>>>> the same tributary types as a 2.5G TS structured HO ODUk. If the
>>>>>> hardware is not capable of 1.25G TS operation, then it isn't
>> going
>>>>>> to
>>>>>> work that way no matter what the operator wants.
>>>>>>
>>>>>> So you need to be able to know the TS granularity of a given HO
>>> ODUk
>>>>>> link (either because the control plane is told the results of the
>>>>>> auto-
>>>>>> negotiation, or if the control plane replicates the results of
>> the
>>>>>> auto-negotiation by knowing the HW capabilities of the two
>> sides),
>>>>>> but
>>>>>> I don't see where you are ever asking for a particular TS
>>>>>> granularity.
>>>>>> Regards,
>>>>>> Steve
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf
>>>>>> Of Jonathan Hardwick
>>>>>> Sent: Wednesday, July 27, 2011 1:07 PM
>>>>>> To: John E Drake
>>>>>> Cc: CATR - Zhang Guoying; CCAMP
>>>>>> Subject: Re: [CCAMP] TS in Signaling
>>>>>>
>>>>>> Hi John,
>>>>>>
>>>>>> I understand why it is necessary to signal the required TS size,
>>>>>> but I
>>>>>> don't think the signal type is the right place to do it.
>>>>>>
>>>>>> From a usability point of view, either the operator knows they
>>>>>> need a
>>>>>> TS granularity of 1.25 Gbps, or else they don't care.  It feels
>>>>>> wrong
>>>>>> to mandate that the TS size be requested in the signal type in
>> all
>>>>>> cases.  I don't see a use case for requesting a signal type of
>>> (say)
>>>>>> ODU3/TS=2.5G - can you elaborate?
>>>>>>
>>>>>> The TS size only matters on the final hop.  That is, it is
>> possible
>>>>>> for
>>>>>> an ODU3 signal to have intermediate spans at 2.5G granularity,
>> and
>>>>>> yet
>>>>>> 1.25G on the final hop.  If the requested signal type were
>>>>>> ODU3/1.25G,
>>>>>> this would be a valid path but somewhat counter-intuitive.
>>>>>>
>>>>>> I think it would be better to encode the required TS size (where
>>>>>> one is
>>>>>> required) in the NMC field of the traffic parameters.  You can
>>> infer
>>>>>> the required TS size from that and the signal type.
>>>>>>
>>>>>> The 8-bit length field sounds a good idea to me.
>>>>>>
>>>>>> Regards
>>>>>> Jon
>>>>>>
>>>>>>
>>>>>> -----Original Message-----
>>>>>> From: [email-masked] [mailto:[email-masked]] On
>>>>>> Behalf
>>>>>> Of John E Drake
>>>>>> Sent: 27 July 2011 12:21
>>>>>> To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; GRANDI, PIETRO
>>>>>> VITTORIO (PIETRO VITTORIO); Infinera - Khuzema Pithewan; CATR -
>>>>>> Zhang
>>>>>> Guoying
>>>>>> Cc: CCAMP
>>>>>> Subject: [CCAMP] TS in Signaling
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Fatai, Lou, and I had a discussion of tributary slot size in
>>>>>> signaling
>>>>>> and we have the following proposal.
>>>>>>
>>>>>> 1)  Add a complete enumeration of all ODUj/tributary slot size
>>>>>> combinations to Signal Type (e.g., ODU3/TS=1.25 & ODU3/TS=2.5G).
>>> (I
>>>>>> think this was there are one time.)
>>>>>>
>>>>>> 2)  Use Signal Type in signaling instead of ODUj, ODUk, and TS
>> size
>>>>>>
>>>>>> The nice thing is that this means that we do not need to have a-
>>>>>> priori
>>>>>> understanding between the endpoints of a link regarding the
>>>>>> tributary
>>>>>> slot size to be used on that link.
>>>>>>
>>>>>> I would also like to propose adding an 8 bit length field to the
>> TS
>>>>>> slot bit map and using the TS slot bit map even in the mapping (j
>> =
>>>>>> k)
>>>>>> case.  The former allows the receiver to perform an useful
>>> integrity
>>>>>> check and the latter allows uniform processing in all cases.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> John
>>>>>>
>>>>>> Sent from my iPhone
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>>> _______________________________________________
>>>>>> CCAMP mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>> _______________________________________________
>>>> CCAMP mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/ccamp
>>>>
>>>>
>>> _______________________________________________
>>> CCAMP mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ccamp
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp
>
>
>
>
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp
_______________________________________________
CCAMP mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ccamp

This e-mail message is intended for the recipient only and contains information which is CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this transmission in error, please inform us by e-mail, phone or fax, and then delete the original and all copies thereof.

---

From: Igor Bryskin <[email-masked]>
Date: Mon, 1 Aug 2011 14:21:14 +0000

This is all true. So why do you need signal TS for any LSP?

Igor

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Thursday, July 28, 2011 1:45 PM
To: John E Drake
Cc: CCAMP; CATR - Zhang Guoying
Subject: Re: [CCAMP] TS in Signaling

Hi,

I re-read yesterday's emails from Malcolm and Steve and it seems that  
having a node advertise the TS size of each of its interfaces is  
useful for two reasons.

1) It allows the nodes at either end of an ODUk/OTUk link to perform  
the TS size determination in the control plane (Steve)

2) It allows the ingress node to compute a path containing links with  
the necessary TS size (Malcolm)

Thanks,

John

Sent from my iPhone

On Jul 27, 2011, at 6:07 PM, "John E Drake" <[email-masked]> wrote:

>> From: Trowbridge, Stephen J (Steve) [mailto:steve.trowbridge@alcatel-
>> lucent.com]
>> I don't understand how there is ever a scenario where "the operator
>> From the perspective of the LO ODU, if you are transporting LO ODU1  
>> or
>> LO ODU2 over any combination of HO ODUk, these can be carried over
>> either 1.25G or 2.5G TS capable HO ODUk. Different segments of the  
>> same
>> connection can have different TS granularities along the path - it
>> doesn't matter. If your LO ODU is an ODU0 or ODUflex, clearly the HO
>> mapped into a HO ODUk is only carried over 1.25G TS because ODU4 (and
>> presumably future larger ODUk) are only 1.25G TS structured. So the
>> only "need" is that if you want to set up a LO ODU0, ODUflex, or ODU3
>> connection, you need to find a route over 1.25G capable links. If you
>> hardware on both ends is 1.25G TS capable, it will operate with 1.25G
>> structuring, and if one (or both) ends can only support PT=20 2.5G TS
>> need to force 2.5G TS granularity if the HW on both sides can support
>> 1.25G TS granularity, as a 1.25G structured HO ODUk can carry all of
>> hardware is not capable of 1.25G TS operation, then it isn't going to
>> So you need to be able to know the TS granularity of a given HO ODUk
>> negotiation, or if the control plane replicates the results of the
>> auto-negotiation by knowing the HW capabilities of the two sides),  
>> but
>> From a usability point of view, either the operator knows they need a
>> TS granularity of 1.25 Gbps, or else they don't care.  It feels wrong
>> to mandate that the TS size be requested in the signal type in all
>> cases.  I don't see a use case for requesting a signal type of (say)
>> The TS size only matters on the final hop.  That is, it is possible  
>> for
>> an ODU3 signal to have intermediate spans at 2.5G granularity, and  
>> yet
>> required) in the NMC field of the traffic parameters.  You can infer
>> VITTORIO (PIETRO VITTORIO); Infinera - Khuzema Pithewan; CATR - Zhang
>> Guoying
>> Cc: CCAMP
>> combinations to Signal Type (e.g., ODU3/TS=1.25 & ODU3/TS=2.5G).  (I
>> 2)  Use Signal Type in signaling instead of ODUj, ODUk, and TS size
>>
>> understanding between the endpoints of a link regarding the tributary
>> I would also like to propose adding an 8 bit length field to the TS
>> slot bit map and using the TS slot bit map even in the mapping (j =  
>> k)
>> case.  The former allows the receiver to perform an useful integrity