Re: [CCAMP] Thought on where to carry G.709-v3 TSG

[Daniele Ceccarelli <[e-mail]>]

Hi Lou,

Let's try with an example showing that in a muxing hierarchy not every layer must use the same TSG. Please consider the following path.

                     IF1     IF2
A ------ B -------- C ----------D
|--ODU2--|          |---ODU2----|
         |---ODU3---|


Suppose an ODU2 from A to D is set up in order to carry an ODU0, so D needs to be able to perform ODU0->ODU2 demuxing. The ODU2 is carried over an ODU3 FA from B to C.
B is not able to support ODU2 and can only carry it through an ODU3@2,5Gbps TSG. It does not care about the fact that the ODU2 is carrying and ODU0 and a 1,25 TSG is needed to extract it, since the extraction is performed by D.

D advertises both hierarchy information and TSG capability on IF2: muxing hierarchy ODU0->ODU2 and TSG field = 01 (i.e. Both 1,25 and 2,5 supported).

The ODU0 is terminated only on D, so B can forward the ODU2 over the ODU3 FA using a TSG = 2,5 Gbps *but* if multiple interfaces are present from C to D, C must choose an OTU2 inferface supporting an 1,25 TSG adaptation towards the client.
 
In conclusion, when setting up an ODU2 LSP, that has to be able to extract an ODU0 in the termination node, TSG information carried in the ODU2 LSP signaling (so referred to ODU0 carried over it) has NO impact on the label allocation for the ODU2 LSP (in fact label allocation for link BC is @2,5 Gbps). Label allocation for the ODU2 LSP is impacted by the TSG capability offered by the underlying ODU3 link/FA.

So the answer to you question is: The LSP's supported TSG does not impact the label allocation/selection. The label allocaction/selection is only impacted by the server link/FA TSG.

As a further clarification, the reason why in our opinion the TSG is not relevant to the traffic parameters is that the type of LSP being set up does not influence the TSG of the server layer (which has already been fixed) but only the choice of the right server.

Thanks
Daniele, Sergio, Pietro

PS. The piece of text in the info model referring to the optional object is in page 9, section 4.1:
"The G-PID information is not enough to have a complete choice since
 the penultimate hop node has to distinguish between interfaces with
 the same TSG (e.g. 1.25Gbps) whether the interface is able to support
 the right hierarchy, i.e. it is possible to have two interfaces both
 at 1.25 TSG but only one is supporting ODU0.

 A dedicated optional object should to be defined in order to carry
 the multiplexing hierarchy and have a more precise choice capability.
 In this way, when the penultimate node receives the GENERALIZED LABEL
 REQUEST Object, the G-PID value together with the ODU bandwdith
 included into the Traffic Parameters Object allow desuming the
 correct TSG value."



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: mercoledì 5 ottobre 2011 19.16
To: BELOTTI, SERGIO (SERGIO); GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Cc: CCAMP
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG

Guys,
	I think we're going in circles.  Let me try a different question that hopefully can help us resolve this.

Are there *any* cases where an LSP's supported TSG impacts label allocation/selection?

If the answer is yes, then TSG belongs in the traffic parameters.

Thanks,
Lou

PS your reference to some text in the info document, rather than keeping us guessing, can you point to a section and paragraph number or just copy and paste the text?

On 10/4/2011 9:33 AM, BELOTTI, SERGIO (SERGIO) wrote:
> Lou,
>  
> See in line
>  
> Pietro and Sergio
>  
> ---------------------
>  
> Pietro, Sergio,
>  
> It looks like we may be converging.  We agree that encoding isn't 
> optimal, and you only have a slight preference for G-PID.  For me the 
> tipping point is on intermediate node use of TSG*.  At this point you 
> have said that this is never needed.  It's my understanding that this 
> isn't correct, and there are cases where it is needed.  Consider the 
> case where there is a 1.25G TSG LSP (e.g., ODU0 or ODUflex) that is 
> being signaled across a topology composed of ODU2 H-LSPs, some of 
> which can support 1.25G TSG and others that only support 2.5G TSG.
> Don't the intermediate nodes need to understand the TSG of the LSP in 
> order to select the proper outgoing H-LSPs?
>  
> [[ALU]] No. The point is that the intermediate nodes have only to 
> consider the LSP signal type (ODU1, ODU2 etc..), and not the TSG that 
> the LSP exports to its clients at the endpoints. So it happens that an 
> ODU0 can only be carried on H-LSPs that export 1.25 TSG to their 
> clients (by G.709 definition). An ODU2 instead can be carried on 
> H-LSPs that export either 1.25 or 2.5. Where you have to consider both 
> the LSP type and the TSG exported to LSP clients is the penultimate 
> node. On that node the interface choice has to be made in such a way 
> that the endpoint
> can:
>  
> 1) support the signal type indicated by the LSP
> 2) structure the LSP with the required adaptation
> 3) support all the required hierarchies
>  
>  
> (*) In a private mail (which the author may resend to the list) the 
> point was also made that by using G-PID for TSG we loose the ability 
> to identify the client adaptation supported by the LSP, e.g., Ethernet.
>  
> [[ALU]]
> In OTN an ODUj LSP either carries an ODUj client or a client of 
> different technology. When we set up a ODU3 H-LSP that will carry an 
> ODUj client, the G-PID of the ODU3 H-LSP simply indicates that the 
> client is an ODUj.
> In OTN when you structure a payload you are not defining which will be 
> the signal types of the carried ODU.
> Once that the ODU3 H-LSP is structured, in order to carry Ethernet you 
> should set up a client ODUj that in turn will carry Ethernet. The 
> G-PID of this ODUj will contain Ethernet.
>  
> Instead related to this point what we can add is that in case of 
> not-ODU clients the TSG is a useless parameter. This would imply to 
> have up to three signal types for every ODU , For example you would 
> need an ODU2-1.25, an ODU2-2.5 and an ODU2-neutral (e.g for Ethernet client).
>  
>  
>  
>  
> Please see below for detailed responses.
>  
> On 10/4/2011 4:31 AM, GRANDI, PIETRO VITTORIO (PIETRO VITTORIO) wrote:
>> Hello Lou,
>>
>> we think we have understood your motivations and we think that we 
>> could narrow the choice to just G-PID and Signal type.
>>
>  
> It looks like we may be converging.
>  
>> We would not consider encoding because in case of TDM it usually 
>> contains the nature of the path  (in this case G.709 ODUk (Digital
>> Path)=12 ) and not the container type and attributes.
>>
>  
> Well I don't mind us reaching the same conclusion, even if our 
> rational isn't the same.
>  
>> We have yet a slight preference for G-PID that is motivated by the 
>> fact the G.709, in case of structuring, explicitly foresees two 
>> different payloads named ODTUjk (for G.709v2) and ODTUk.ts (for 
>> G.709v3). The current GPID value defined in RFC 4328 is currently 
>> associated to the ODTUjk only.
>  
> Huh?  RFC4328 says:
>  
>    The G-PID (16 bits field), as defined in [RFC3471], identifies the
>    payload carried by an LSP, i.e., an identifier of the client layer of
>    that LSP.  This identifier is used by the endpoints of the G.709 LSP.
>  
>    The G-PID can take one of the following values when the client
>    payload is transported over the Digital Path layer, in addition to
>    the payload identifiers defined in [RFC3471]:
>  
> Clearly the rfc envisions use of multiple G-PIDs based on the use of 
> the
> G.709 LSP.
>  
> [ALU] The only value related to ODUjk is 47. The other (linked to
> G.709
> v3) can not be present .since G.709v3 was not present at that time.
>  
>> The extension of G-PID would be one to one consistent with G.709.
>  
> This is where our perspective diverges.
>  
> [ALU] Why?
>  
>>
>> We have also to notice that we are using the same signal type value 
>> both in routing and in signaling. Surely we would avoid a duplication 
>> of data in the ISCD just to differentiate the TSGs. (for example
>> ODU2-2.5 and ODU2-1.25). This could happen on interfaces that have 
>> auto-payload type on.
>  
> I addressed this point in my original mail:
>>> Hereto, the 1.25 types would imply support for both 1.25 and 2.5 
>>> types in routing.
>  
> Also note that the routing draft currently says:
>    A single ISCD MAY be used for the advertisement of unbundled or
>    bundled links supporting homogeneous multiplexing hierarchies and the
>    same Tributary Slot Granularity (TSG).  A different ISCD MUST be used
>    for each different muxing hierarchy (muxing tree in the following
>    examples) and different TSG supported within the TE Link, if it
>    includes component links with differing characteristics.
>  
>  
> [ALU] We addressed the point also in a previous mail in which you seem 
> to converge in the opportunity to have at least two different signal 
> types values.
> 1.25 does not imply the support also for both 1.25/2.5 as reported in 
> this snip of a previous mail.
> Snip>
>> To
>> complicate things, it is not always true that an interface supporting
>> 1.25 tributary slots can also support 2.5 tributary slots, because 
>> this specific functionality (known as fallback support setting 
>> auto-payload flag to ON) can be either not present in HW or disabled 
>> by NMS.
>>
>  
> Well this is something I didn't have in my original mail.  It was my 
> understanding from previous discussions, that fallback support was a 
> required in G.709-v3.  If it is optional (either in implementation or 
> in
> operation) we need to ensure that both cases (1.25 + 2.5 support, or 
> just 1.25 support) are fully covered.
>  
>  
>  
>>
>> On the other hand the usage of signal type could avoid the need to 
>> perform consistency checks between G-PID value and signal type value.
>> (e.g ODU4 with 2.5 TSG)
>>
>> About G-PID we have one question. The definition you wrote in RFC3471 
>> for G-PID is : "An identifier of the payload carried by an LSP, i.e., 
>> an identifier of the client layer of that LSP.  This is used by the 
>> nodes at the endpoints of the LSP, and in some cases by the 
>> penultimate hop."
>>
>> This definition standing, could you elaborate how can be derived from 
>> what described that G-PID is "an end-point only field " ? Did we miss 
>> something in the definition ?
>  
> Wouldn't you agree that client layer adaptation is only within the 
> scope of the endpoints?  The sole exception that I can think of is PHP.
> Perhaps I'm missing something.
>  
> [ALU] We have in mind a different case: supposing to have an ODU2 LSP 
> carrying an Ethernet client and suppose you have an OTU2 interface 
> able to terminate ODU2 and extract Ethernet. At penultimate this 
> interface may be selected for the ODU2 LSP and selection criteria is 
> the G-PID value indicating Ethernet payload and not for example FiberChanne/ATM.
>  
>>
>> Anyway, apart the slight preference motivated above we do not have a 
>> strong position on this issue. As co-authors of the draft we would 
>> like to collect WG opinion included at first our co-authors' opinion 
>> and report the WG decision in the drafts.
>  
> Sure.  Per IETF process, a WG document represents WG consensus.
>  
>>
>> Last but not least, we would like to remind that info draft reports 
>> the need for a optional dedicated object containing the hierarchies 
>> that should be supported by the endpoints. Independently from the 
>> solution for TSG, this object is anyway required.
>>
>  
> I'm not sure which text you are referring to, but if you think it's 
> covered in the routing draft, then we're in sync.
>  
> [ALU] The text is in the G.709-info draft , and is related to a 
> dedicated optional object to insert in signalling , not in routing, 
> where the supported hierarchies are already present.
>  
> Much thanks,
> Lou
>  
>  
>  
_______________________________________________
CCAMP mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ccamp