Subject: [CCAMP] TS in Signaling

From: John E Drake <[email-masked]>
Date: Wed, 27 Jul 2011 09:20:48 -0700

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

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 28 Jul 2011 01:42:13 +0800

Hi all,

I do agree with John on the statement: " 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 just checked all the drafts related to OTN (e.g, FWK, Info, OSPF, RSVP) and found that Signal Type is independent of TS. I recall that some experts suggested that Signal Type should be independent of TS and consistent with ITU-T recommendtations. 

So, the simple alternative is to include TS in the label format, ie., the original Signal Type + TS (to replace John's combined Signal Type). 

Fatai

Thanks
----- Original Message ----- 
From: "John E Drake" <[email-masked]>
To: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>; "Khuzema Pithewan" <[email-masked]>; <[email-masked]>
Cc: "Lou Berger" <[email-masked]>; "CCAMP" <[email-masked]>; "Fatai Zhang" <[email-masked]>
Sent: Thursday, July 28, 2011 12:20 AM
Subject: TS in Signaling

Hi,

Thanks,

John 

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Jul 2011 10:46:01 -0700

Fatai,

I do think we also want the same combination, preferably with the same encoding, in routing in the ODUj advertisement.

Thanks,

John 

Sent from my iPhone

> -----Original Message-----
> From: Fatai Zhang [mailto:[email-masked]]
> Sent: Wednesday, July 27, 2011 10:42 AM
> To: John E Drake; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; GRANDI,
> PIETRO VITTORIO (PIETRO VITTORIO); Khuzema Pithewan;
> [email-masked]
> Cc: Lou Berger; CCAMP
> Subject: Re: TS in Signaling
> 
> Hi all,
> 
> I do agree with John on the statement: " 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 just checked all the drafts related to OTN (e.g, FWK, Info, OSPF,
> RSVP) and found that Signal Type is independent of TS. I recall that
> some experts suggested that Signal Type should be independent of TS and
> consistent with ITU-T recommendtations.
> 
> So, the simple alternative is to include TS in the label format, ie.,
> the original Signal Type + TS (to replace John's combined Signal Type).
> 
> 
> 
> 
> 
> 
> Fatai
> 
> Thanks
> To: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>;
> "Daniele Ceccarelli" <[email-masked]>; "GRANDI, PIETRO
> VITTORIO (PIETRO VITTORIO)" <pietro_vittorio.grandi@alcatel-
> lucent.com>; "Khuzema Pithewan" <[email-masked]>;
> <[email-masked]>
> 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.)
> 
> 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

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 28 Jul 2011 01:57:05 +0800

Hi John,

I have no strong opinion on your prososal if people like that.

I am just thinking how to make things simpler and easier, :-)

Fatai

Thanks
----- Original Message ----- 
From: "John E Drake" <[email-masked]>
To: "Fatai Zhang" <[email-masked]>; "BELOTTI, SERGIO (SERGIO)" <[email-masked]>; "Daniele Ceccarelli" <[email-masked]>; "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>; "Khuzema Pithewan" <[email-masked]>; <[email-masked]>
Cc: "Lou Berger" <[email-masked]>; "CCAMP" <[email-masked]>
Sent: Thursday, July 28, 2011 1:46 AM
Subject: RE: TS in Signaling

Fatai,

Thanks,

John 

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Jul 2011 11:03:48 -0700

As are we all.

Sent from my iPhone

> Sent: Wednesday, July 27, 2011 10:57 AM
> To: "Fatai Zhang" <[email-masked]>; "BELOTTI, SERGIO (SERGIO)"
> <[email-masked]>; "Daniele Ceccarelli"
> <[email-masked]>; "GRANDI, PIETRO VITTORIO (PIETRO
> VITTORIO)" <[email-masked]>; "Khuzema
> Pithewan" <[email-masked]>; <[email-masked]>
> I do think we also want the same combination, preferably with the same
> encoding, in routing in the ODUj advertisement.
> 
> Thanks,
> 
> John
> 
> Sent from my iPhone
> 
> 
> > Fatai, Lou, and I had a discussion of tributary slot size in
> signaling
> > and we have the following proposal.
> >

---

From: [email-masked]
Date: Wed, 27 Jul 2011 14:45:18 -0400

Hi all,

I am having trouble understanding some of the assertions being made - 
please see in line below.

Regards,

Malcolm

Fatai Zhang <[email-masked]> 
Sent by: [email-masked]
27/07/2011 01:42 PM

To
John E Drake <[email-masked]>, "BELOTTI, SERGIO (SERGIO)" 
<[email-masked]>, Daniele Ceccarelli 
<[email-masked]>, "GRANDI, PIETRO VITTORIO (PIETRO 
VITTORIO)" <[email-masked]>, Khuzema Pithewan 
<[email-masked]>, [email-masked]
cc
CCAMP <[email-masked]>
Subject
Re: [CCAMP] TS in Signaling

Hi all,

I do agree with John on the statement: " 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."
[MB] To be clear signalling cannot change the TS used on a link it is 
determined by the hardware.  A link that uses 1.25G TS can support any of 
the OTN payloads.  A link that uses 2.5G TS cannot support some payloads 
e.g. ODUflex.

I just checked all the drafts related to OTN (e.g, FWK, Info, OSPF, RSVP) 
and found that Signal Type is independent of TS. I recall that some 
experts suggested that Signal Type should be independent of TS and 
consistent with ITU-T recommendtations.
[MB] So what is the justification for combining them. If TS granularity 
and payload type are "merged" does this imply that we must use the same TS 
granularity on all links end to end. A higher level question why do you 
need to signal the TS granularity - routing should only select a path that 
supports the required TS granularity.

So, the simple alternative is to include TS in the label format, ie., the 
original Signal Type + TS (to replace John's combined Signal Type). 

Fatai

Thanks
----- Original Message ----- 
From: "John E Drake" <[email-masked]>
To: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>; 
"Daniele Ceccarelli" <[email-masked]>; "GRANDI, PIETRO 
VITTORIO (PIETRO VITTORIO)" <[email-masked]>; 
"Khuzema Pithewan" <[email-masked]>; 
<[email-masked]>
Cc: "Lou Berger" <[email-masked]>; "CCAMP" <[email-masked]>; "Fatai 
Zhang" <[email-masked]>
Sent: Thursday, July 28, 2011 12:20 AM
Subject: 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.)

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

---

From: Khuzema Pithewan <[email-masked]>
Date: Wed, 27 Jul 2011 18:57:01 +0000

John,

TSG discussion started with objection of TSG in label, which was between 2 nodes  and was getting used to make sense of time slots. Now, that we are assuming that both the nodes know the TSG a priori, the mention of TSG in label is redundant.

The TSG you are talking about now is more of property of a FA-LSP for client-LSP and using FA-LSP signaling to get intersection of TSG support by 2 ends of the FA-LSP. This is more of a link property discovery and correlation. LSP signaling can be used to communicate the property. We prefer a separate object that carries TSG in signaling message. Attaching TSG with signal type will just blow up the number of signal type and it is unwarranted.

Thanks
Khuzema

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 2:04 PM
To: Fatai Zhang; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Khuzema Pithewan; [email-masked]
Cc: Lou Berger; CCAMP
Subject: RE: TS in Signaling

As are we all.

Sent from my iPhone

> To: John E Drake; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; 
> GRANDI, PIETRO VITTORIO (PIETRO VITTORIO); Khuzema Pithewan; 
> > So, the simple alternative is to include TS in the label format, 
> > ie., the original Signal Type + TS (to replace John's combined 
> > Signal
> Type).
> >
> >
> >
> >
> >
> >
> > Fatai
> >
> > Thanks
> > understanding between the endpoints of a link regarding the 
> > tributary slot size to be used on that link.
> >

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 27 Jul 2011 19:06:31 +0000

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,

Thanks,

John 

Sent from my iPhone

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Jul 2011 15:49:12 -0400

Khuzema,
	I fully admit that I haven't thought enough about this to be convinced
on any particular approach.  That said, what's the problem with
increasing the number of signal types, we have about 230 unused values
and are talking about using 3 of these.

My understanding is that TSG comes into play in two cases.  The first is
the one you mention which has link-local scope.  The second, which is
the one that lead me to suggest using signal type, is when signaling an
OTU1,2 or 3 H-LSP the H-LSP endpoints need to know the TSG requested for
the H-LSP. Since this latter case is one of end-to-end (of the H-LSP)
coordination, it makes sense for TSG to be carried in an field/object
with e2e significance.  This lead me to suggest signal type.

Lou (chair hat off)

On 7/27/2011 2:57 PM, Khuzema Pithewan wrote:
> John,
> 
> TSG discussion started with objection of TSG in label, which was
> between 2 nodes  and was getting used to make sense of time slots.
> Now, that we are assuming that both the nodes know the TSG a priori,
> the mention of TSG in label is redundant.
> 
> The TSG you are talking about now is more of property of a FA-LSP for
> client-LSP and using FA-LSP signaling to get intersection of TSG
> support by 2 ends of the FA-LSP. This is more of a link property
> discovery and correlation. LSP signaling can be used to communicate
> the property. We prefer a separate object that carries TSG in
> signaling message. Attaching TSG with signal type will just blow up
> the number of signal type and it is unwarranted.
> 
> Thanks
> Khuzema
> 
>> GRANDI,

---

From: "Trowbridge, Stephen J (Steve)" <[email-masked]>
Date: Wed, 27 Jul 2011 15:44:07 -0500

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,

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,

Thanks,

John 

Sent from my iPhone

---

From: Lou Berger <[email-masked]>
Date: Wed, 27 Jul 2011 17:15:33 -0400

Tspec was another spot I've been thinking about, but had reservations as
allocation is also more of a "per-hop" processed object.  Deborah also
suggested g-pid, which is worth some consideration.  clearly we have to
keep looking at the different options.

Lou (hat off)

On 7/27/2011 3:06 PM, Jonathan Hardwick wrote:
> 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.
>

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 27 Jul 2011 21:42:02 +0000

Hi Steve,

>> I don't understand how there is ever a scenario where "the operator knows they need" is a criteria regarding TS size

I think the following is a simplistic, but valid, scenario.

A --- ODU2 --- B --- ODU2 --- C

B can switch ODU2 only.  The operator requires an ODU2 H-LSP connecting A and C, and is going to use it to carry ODU0 or ODUflex LSPs.  The BC link therefore must have a 1.25G TS granularity.  If the operator merely requests an ODU2 H-LSP without giving a TS size, they might not get what they wanted.

>> Different segments of the same connection can have different TS granularities along the path

Agree - I think the TS granularity only potentially matters on the initial and final segments.

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

Agree.  You might want to force a 1.25G TS granularity, but I can't see a use case for forcing a 2.5G TS granularity.

Regards
Jon

-----Original Message-----
From: Trowbridge, Stephen J (Steve) [mailto:[email-masked]] 
Sent: 27 July 2011 16:44
To: Jonathan Hardwick; John E Drake
Cc: CATR - Zhang Guoying; CCAMP
Subject: RE: TS in Signaling

Hi all,

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

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,

Thanks,

John 

Sent from my iPhone

---

From: Jonathan Hardwick <[email-masked]>
Date: Wed, 27 Jul 2011 21:44:53 +0000

Hi Lou

I agree, we should explore the options.  I do like the idea of using G-PID.

Regards
Jon

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: 27 July 2011 17:16
To: Jonathan Hardwick
Cc: John E Drake; CATR - Zhang Guoying; CCAMP
Subject: Re: [CCAMP] TS in Signaling

Lou (hat off)

---

From: John E Drake <[email-masked]>
Date: Wed, 27 Jul 2011 15:07:57 -0700

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

> Sent: Wednesday, July 27, 2011 1:44 PM
> 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
> 
> 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.
> 
> To: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; GRANDI, PIETRO
> VITTORIO (PIETRO VITTORIO); Infinera - Khuzema Pithewan; CATR - Zhang
> Guoying
> Cc: CCAMP

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Jul 2011 00:10:39 +0200

Hi, 

For the second case this is related to the adaptation, which is related
to the G-PID, and 
also apply when you want to transport SDH or any of the OPU payload type
defined in G.709 
table 15-8. The G-PID defined in RFC4328 does allow to derive the PT to
use, except to derive
if PT 20 or 21 should be used. One potential solution would be to
defined a new G-PID indicating
the OPU carries an ODTUk.ts.

Overall the TS is independent of the signal type, TS is a property of a
single multiplexing stage. 
For H-LSP in order to agree on the TS size, this is the same problem as
a ODUk link provisioning, 
So mechanism like G-PID can be used to enforce a given adaptation, or
LMP can be used to bring up the link with correlated properties, or
solution using signaling (one of them was
draft-roch-ccamp-lsp-hier-multi-client-00) could be considered.

Best regards.

> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of ext Lou Berger
> Sent: Wednesday, July 27, 2011 3:49 PM
> To: Khuzema Pithewan
> Cc: [email-masked]; CCAMP
> 	I fully admit that I haven't thought enough about this to be
> convinced on any particular approach.  That said, what's the problem
> with increasing the number of signal types, we have about 230 unused
> values and are talking about using 3 of these.
> 
> My understanding is that TSG comes into play in two cases.  The first
> is the one you mention which has link-local scope.  The second, which
> is the one that lead me to suggest using signal type, is when
signaling
> an
> OTU1,2 or 3 H-LSP the H-LSP endpoints need to know the TSG requested
> for the H-LSP. Since this latter case is one of end-to-end (of the H-
> LSP) coordination, it makes sense for TSG to be carried in an
> field/object with e2e significance.  This lead me to suggest signal
> type.
> 
> Lou (chair hat off)
> 
> > To: Fatai Zhang; BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli;
> GRANDI,
> >> I do think we also want the same combination, preferably with the
> >> same encoding, in routing in the ODUj advertisement.
> >>
> >> Thanks,
> >>
> >> John
> >>
> >> Sent from my iPhone
> >>
> >>
> >>> some experts suggested that Signal Type should be independent of
TS
> >> and
> >>> slot bit map and using the TS slot bit map even in the mapping (j
=
> >> k)

---

From: "Margaria, Cyril (NSN - DE/Munich)" <[email-masked]>
Date: Thu, 28 Jul 2011 00:17:02 +0200

Hi, 

Please see inline

> Of ext Jonathan Hardwick
> Sent: Wednesday, July 27, 2011 5:42 PM
> To: Trowbridge, Stephen J (Steve)
> Cc: CCAMP; CATR - Zhang Guoying
> knows they need" is a criteria regarding TS size
> 
> B can switch ODU2 only.  The operator requires an ODU2 H-LSP
connecting
> A and C, and is going to use it to carry ODU0 or ODUflex LSPs.  The BC
> link therefore must have a 1.25G TS granularity.

I think stating that the *link* B-C is using a 1.25 TS granularity is
misleading
because node B do not see or know any TS.
When the ODU2 H-LSP is created it will create in the data plane a link
A-C, the 
ODU2 trail will be terminated using an ODTU2.ts (i.e using 1.25 TS).  

>  If the operator
> merely requests an ODU2 H-LSP without giving a TS size, they might not
> get what they wanted.
> 
> >> 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
> 
> Agree.  You might want to force a 1.25G TS granularity, but I can't
see
> a use case for forcing a 2.5G TS granularity.
> 
> Regards
> Jon
> 
> 
> Of Jonathan Hardwick
for
> I think it would be better to encode the required TS size (where one
is
> Of John E Drake

---

From: "Trowbridge, Stephen J (Steve)" <[email-masked]>
Date: Wed, 27 Jul 2011 17:55:32 -0500

Hi all,
A couple of points:
First of all, in the described scenario, if the HW terminating an ODU2 at "A" and the HW terminating the other end of that ODU2 at "C" are 1.25G TS capable, this ODU2 will auto-negotiate to 1.25G TS granularity. Assuming that the ODU2 is just connected through at node B, it does not have anything to do with the auto-negotiation.

While I fully agree that there will be cases like this where you set up a "middle-order" ODUk to tunnel ODU0 or ODUflex traffic across non-1.25G TS capable nodes, I have real doubts about whether these are ever anything but (manually) configured tunnels. I really don't see this ever being something auto-magically created by the control plane. If it were only ODU0 traffic that was of concern, I could see that you might set up ODU1s across a legacy node and use one TS within the ODU1 for the ODU0, making available the other TS to carry another ODU0 if you have another that needs to traverse that node. But for ODUflex, and especially now that ODUflex is resizable, how would you decide to set up an ODU2 instead of an ODU3 to tunnel the traffic across the legacy node? You want enough extra space for what the traffic might grow to inside of the tunnel, but you don't want to waste bandwidth by setting up too much artificial fragmentation.
Regards,
Steve

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 4:17 PM
To: ext Jonathan Hardwick; Trowbridge, Stephen J (Steve)
Cc: CCAMP; CATR - Zhang Guoying
Subject: RE: [CCAMP] TS in Signaling

Hi, 

Please see inline

connecting

see
for
is

---

From: Jonathan Hardwick <[email-masked]>
Date: Thu, 28 Jul 2011 02:07:12 +0000

Cyril, Steve,

I agree with what you say, but I thought the problem we were trying to solve was a bit different.

If node C has several interfaces, some of which are 1.25G TS capable and some of which are not, then the control plane needs to know that it must select one of the former sort.

If none of the hardware at node C is 1.25G TS capable, and the ODU2 auto-negotiates to a 2.5G TS, then the operator does not get what they want.  Although this is a misconfiguration scenario, I think it would be better for the control plane not to establish the LSP in this case.

I don't have a view on whether the control plane should manage the middle-order ODUs, but I would not like to rule it out.

If I have misunderstood the original problem, my apologies.

Regards
Jon

-----Original Message-----
From: Trowbridge, Stephen J (Steve) [mailto:[email-masked]] 
Sent: 27 July 2011 18:56
To: NSN - Cyril Margaria; Jonathan Hardwick
Cc: CCAMP; CATR - Zhang Guoying
Subject: RE: [CCAMP] TS in Signaling

Hi all,
A couple of points:

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 4:17 PM
To: ext Jonathan Hardwick; Trowbridge, Stephen J (Steve)
Cc: CCAMP; CATR - Zhang Guoying
Subject: RE: [CCAMP] TS in Signaling

Hi, 

Please see inline

connecting

see
for
is

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 28 Jul 2011 10:28:26 +0200

Hello Jonathan,

I think you have stated correctly the problem.

Pardon me, if I use this reply in order to recap possible solutions up to now and considerations I have understood up to now:

1) Dedicated object for TS. It is end to end. It may not be used (for instance if no legacy is present in the network or an operator really does not care about PT).

2) Usage of signal type + TS size (enumerative field) in the label object. It is end to end. Someone noted that it is end-to-end but not so much because it is in the label object and could be interpreted as trying to force intermediate nodes to choose a certain TS granularity while instead
granularity on intermediate nodes is a "don't care". It increases the number of signal types but in very limited way (because only ODU1,ODU2 and ODU3 can be 1.25 or 2.5). It also forces to specify a TS size even if it is a don't care. 

3) Usage of G-PID defining new adaptation values: It is end to end.
I imagine they would be three values: one for PT 20, one for PT21 and the last for "structured with any PT" right ? 

4) Traffic parameter modification. It is end to end.

Pietro    

============================================
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 Jonathan Hardwick
Sent: giovedì 28 luglio 2011 4.07
To: Trowbridge, Stephen J (Steve); NSN - Cyril Margaria
Cc: CCAMP; CATR - Zhang Guoying
Subject: Re: [CCAMP] TS in Signaling

Cyril, Steve,

Regards
Jon

-----Original Message-----
From: Trowbridge, Stephen J (Steve) [mailto:[email-masked]] 
Sent: 27 July 2011 18:56
To: NSN - Cyril Margaria; Jonathan Hardwick
Cc: CCAMP; CATR - Zhang Guoying
Subject: RE: [CCAMP] TS in Signaling

Hi all,
A couple of points:

-----Original Message-----
From: Margaria, Cyril (NSN - DE/Munich) [mailto:[email-masked]] 
Sent: Wednesday, July 27, 2011 4:17 PM
To: ext Jonathan Hardwick; Trowbridge, Stephen J (Steve)
Cc: CCAMP; CATR - Zhang Guoying
Subject: RE: [CCAMP] TS in Signaling

Hi, 

Please see inline

connecting

see
for
is

---

From: [email-masked]
Date: Thu, 28 Jul 2011 11:09:38 +0800

Hi, John

I'm confused about your proposal.

If you add a complete enumeration of all ODUj/tributary slot size to 
Signal Type. 

For example, ODU3/TS=1.25 & ODU3/TS=2.5G. Then my question is how you 
treat them? They are in the same layer or different layers?

Best regards

Qilei Wang

John E Drake <[email-masked]> 
发件人:  [email-masked]
2011-07-28 00:20

收件人
"BELOTTI, SERGIO (SERGIO)" <[email-masked]>, Daniele 
Ceccarelli <[email-masked]>, "GRANDI, PIETRO VITTORIO 
(PIETRO VITTORIO)" <[email-masked]>, Khuzema 
Pithewan <[email-masked]>, "[email-masked]" 
<[email-masked]>
抄送
CCAMP <[email-masked]>
主题
[CCAMP] TS in Signaling

Hi,

Thanks,

John 

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 28 Jul 2011 10:44:31 -0700

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

---

From: "Ong, Lyndon" <[email-masked]>
Date: Thu, 28 Jul 2011 14:02:53 -0400

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,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Thu, 28 Jul 2011 11:06:17 -0700

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
>
>
>
>>> From: Trowbridge, Stephen J (Steve)  
>>> [mailto:steve.trowbridge@alcatel-
>>> lucent.com]

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Thu, 28 Jul 2011 13:09:25 -0500

Yup - it could be supporting 1.25G granularity for ODUflex.

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

Lyndon,

Thanks,

John

Sent from my iPhone

============================================================
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: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 29 Jul 2011 09:03:31 +0200

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,

Thanks,

John

Sent from my iPhone

---

From: "Ong, Lyndon" <[email-masked]>
Date: Fri, 29 Jul 2011 07:13:06 -0400

True, advertisement of ODU0 OR ODUflex support would imply support of 2009 OTN and 1.25 TS size.  You could make it explicit as well.

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

Lyndon,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Fri, 29 Jul 2011 06:05:17 -0700

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

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

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 29 Jul 2011 08:15:52 -0500

Hi John,

The FA/TE-Link that is supported by an H-LSP does have a TS size independent of the TE-Link below the H-LSP.

However, the layer of the FA/TE-Link as well as its adaptation detail (which is what the TS size is a parameter) isn't conveyed in the Signal Type -- its conveyed in the GPID.

For example, if I create a STS-1 H-LSP that is supporting an IP/MPLS FA/TE-Link, the GPID is set to reflect IP/MPLS not the H-LSP's Signal Type.

In this OTN case, the FA/TE-Link is in the upper ODUj layer while the H-LSP is in the ODUk layer.

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, July 29, 2011 8:05 AM
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; CATR - Zhang Guoying
Subject: Re: [CCAMP] TS in Signaling

Sergio,

Thanks,

John

Sent from my iPhone

---

From: "Sadler, Jonathan B." <[email-masked]>
Date: Fri, 29 Jul 2011 08:24:34 -0500

Hi John,

A separate comment re: the advertising of TS information in routing.  As mentioned in my previous email, TS size is an attribute of the adaptation used to put an ODUj into an ODUk.

This ties into the requirement found in ITU-T's G.7715.1 stating the need for links to advertise the adaptations supported by a link end (i.e. TE-Link end).  When the TE-Link advertisement (whether a TE-Link created by an FA or a TE-Link that uses a physical link) includes this detail, it is possible for routing to validate the compatibility of the endpoints with the service requested.

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of John E Drake
Sent: Friday, July 29, 2011 8:05 AM
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; CATR - Zhang Guoying
Subject: Re: [CCAMP] TS in Signaling

Sergio,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Fri, 29 Jul 2011 06:33:55 -0700

Jonathan,

I think this means you agree with me 8->?

John

Sent from my iPhone

> Sent: Friday, July 29, 2011 6:25 AM
> To: John E Drake; BELOTTI, SERGIO (SERGIO)
> A separate comment re: the advertising of TS information in routing.
> As mentioned in my previous email, TS size is an attribute of the
> adaptation used to put an ODUj into an ODUk.
> 
> This ties into the requirement found in ITU-T's G.7715.1 stating the
> need for links to advertise the adaptations supported by a link end
> (i.e. TE-Link end).  When the TE-Link advertisement (whether a TE-Link
> created by an FA or a TE-Link that uses a physical link) includes this
> detail, it is possible for routing to validate the compatibility of the
> endpoints with the service requested.
> 
> Jonathan Sadler
> 
> 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.)
> 
> > Da: [email-masked] [mailto:[email-masked]] Per conto
> di
> > John E Drake
> > >>> From the perspective of the LO ODU, if you are transporting LO
> ODU1
> > >>> or
> > >>> either 1.25G or 2.5G TS capable HO ODUk. Different segments of
> the
> > >>> same
> > >>> structuring, and if one (or both) ends can only support PT=20
> 2.5G
> > >>> TS
> > >>> hardware is not capable of 1.25G TS operation, then it isn't
> going
> > >>> to
> > >>> auto-negotiation by knowing the HW capabilities of the two
> sides),
> > >>> but
> > >>> an ODU3 signal to have intermediate spans at 2.5G granularity,
> and
> > >>> yet

---

From: John E Drake <[email-masked]>
Date: Fri, 29 Jul 2011 06:32:16 -0700

Jonathan,

Thanks for your note.  GPID is certainly another possibility;  the important thing is that this parameter has end-to-end semantics.  The question of whether this is true is the question from last week with which I started this discussion, and we have had quite an evolution of views.

John

Sent from my iPhone

> Sent: Friday, July 29, 2011 6:16 AM
> The FA/TE-Link that is supported by an H-LSP does have a TS size
> independent of the TE-Link below the H-LSP.
> 
> However, the layer of the FA/TE-Link as well as its adaptation detail
> (which is what the TS size is a parameter) isn't conveyed in the Signal
> Type -- its conveyed in the GPID.
> 
> For example, if I create a STS-1 H-LSP that is supporting an IP/MPLS
> FA/TE-Link, the GPID is set to reflect IP/MPLS not the H-LSP's Signal
> Type.
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Fri, 29 Jul 2011 15:55:45 +0200

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,

Thanks,

John

Sent from my iPhone

---

From: John E Drake <[email-masked]>
Date: Fri, 29 Jul 2011 06:57:32 -0700

Sergio,

That would be fine with me.

Thanks,

John

Sent from my iPhone

> Sent: Friday, July 29, 2011 6:56 AM
> To: John E Drake
> 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
> 
> 
> 
> 
>

---

From: Lou Berger <[email-masked]>
Date: Fri, 29 Jul 2011 10:41:20 -0400

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

---

From: Fatai Zhang <[email-masked]>
Date: Fri, 29 Jul 2011 22:54:05 +0800

Hi Lou,

I could try, please correct me if  my understanding is not correct or accurate.

In the signaling, only need 1 muxing capability. 

In the routing, the full muxing capabilities (OTN muxing) have been advertised in the OSPF draft, non-OTN stuff is for further study, which is captured in Daniele's FWK and Info presentation.

==============================================================================
- all that is needed is TSG
- TSG is useless, need full muxing capabilities
- only need 1 muxing capability

Fatai

Thanks
----- Original Message ----- 
From: "Lou Berger" <[email-masked]>
To: "John E Drake" <[email-masked]>; "CCAMP" <[email-masked]>
Cc: "CATR - Zhang Guoying" <[email-masked]>
Sent: Friday, July 29, 2011 10:41 PM
Subject: Re: [CCAMP] TS in Signaling

So far, I've heard:

Thanks,
Lou

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Fri, 29 Jul 2011 17:13:25 +0200

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.

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

So far, I've heard:

Thanks,
Lou

---

From: Jonathan Hardwick <[email-masked]>
Date: Fri, 29 Jul 2011 16:14:22 +0000

Lou,

I think it depends on what you are trying to do.  Here is my understanding.  Is it right or wrong?

I. Signaling ODUk to carry some non-ODU service
===============================================
I don't think there is a requirement to guarantee the TSG of the LSP is 1.25G or 2.5G.  I am not _certain_ of this because I have heard conflicting opinions.  However, based on Stephen Trowbridge's comments on an earlier thread, I will assume that the operator does not need to control this.

Therefore, in this case, you don't need anything to do with TSG or muxing capabilities in the signalling message.  The TSG will auto-negotiate to one value or the other (it does not matter which), and you are not doing any ODU muxing.

If my assumption is wrong, we might need to signal the TSG in this case (and include it in routing).

II. Signaling ODUk to establish an H-LSP to carry ODUj
======================================================
We can bundle links with dissimilar mux hierarchies.  When we establish an H-LSP, we need to make sure that the component link selected by the penultimate-hop LSR has an endpoint whose mux hierarchy can access the appropriate service or services that the H-LSP is being set up to carry.  Therefore the Path message must describe the ODUj that you want to carry (which might itself be an H-LSP!).

So, in this case you "only need N muxing capabilities" where N is the number of different types of ODUj you want to run over the H-LSP.

In practice, perhaps we only have to worry about N=1.

III. Signaling ODUk to establish an FA-LSP
==========================================
We can bundle links with dissimilar mux hierarchies.  Therefore, path computation cannot guarantee for us what mux hierarchy we are going to end up with when the LSP is established.  We need to discover it before we can use the LSP as an FA-LSP.  One way to do this is to include the full mux hierarchy of the ingress endpoint on the Path, and the full mux hierarchy of the egress endpoint on the Resv.  (Another option is to run LMP on the LSP after establishment, but this has drawbacks, in that there will be some time lag, and you might not want to run LMP over every FA-LSP for scalability reasons.)

So in this case you "need full muxing capabilities".

Regards
Jon

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

So far, I've heard:

Thanks,
Lou