Subject: Re: [CCAMP] TS in Signaling - explicit encoding of TSG is not needed but multiplexing/adaptation information is needed for H-LSP

From: Biao Lu <[email-masked]>
Date: Thu, 28 Jul 2011 05:44:42 +0000

Hi folks:

I like to bring everybody attention on a couple of observations on TSG topic. 
Based on these observations, I think there is a way to satisfy the signaling 
requirements without explicitly encoding TSG in the message and without 
knowing remote TSG information of a TE link or H-LSP. But we need to carry 
multiplexing/adaptation information for H-LSP setup but not TSG.

Observations:
    1. Signalling cannot change the TSG 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. (From Macolm's email).
    2. In current signaling draft, the TSG information can be derived from signal type + the
        number of bits set in the bit map. For example, for a ODU1 signal, if there is only 1 bit
        set, we can derive TSG to be 2.5G. If there are 2 bits set, we can derive TSG to be 
        1.25G. So there is no ambiguity in configuring the HW based on current label
        definition which doesn't have explicit TSG information.

How to support signaling over a link (i.e. Node A (TSG=1.25G) ------------- Node B (TSG=2.5G) ) 
without each end knowing the remote TSG information?

      I like suggest a default label allocation scheme. This default scheme should be used 
      whenever those tributary slots are available for each signal type based on the server ODU. 
      The default tributary slot (TS) allocation scheme is:  

          First, try to allocate the TS in the way that is always compatible with remote end as if the
          remote end is with TSG=2.5G regardless local TSG value. If the default TS is not available, 
          other TS can be used. 
      
     With this allocation scheme, if successful, the hardware will automatic pass traffic based on
     observation #1. Since we don't know the remote TSG information, we might get crankback 
     from next hop instead of current hop when the request TS can't supported by remote node
     I think this is acceptable.

H-LSP case:
         There is a need for signaling to ensure that the H-LSP being setup can support the client 
         signal type. It is not about agreeing TSG here. 

         For example, if a ODU2 H-LSP is triggered by a ODU0 LSP setup, 
         the ODU2 H-LSP PATH message needs to indicate that the ODU2 being setup needs 
         to be able to support ODU0.

         In another case, if the ODU2 H-LSP is triggered by a ODU1 LSP setup, then the one end
         of H-LSP can have TSG=1.25G and the other end can have TSG=2.5G. This is still a valid
         H-LSP to support ODU1 over this H-LSP.

        Yet another case, mgmt may request a setup of H-LSP with specific multiplexing 
        hierarchy not a simple adaption.

        Conclusion on H-LSP setup:
           What we need to carry is the requested multiplexing capability of 
           the H-LSP itself. For the simple case, we need to carry what client signal type 
           that can be adapted directly to this H-LSP. For more complex case, more than one 
           signal type or even hierarchical multiplexing capability will need to be carried. 

Biao

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Margaria, Cyril (NSN - DE/Munich)
Sent: Wednesday, July 27, 2011 6:11 PM
To: ext Lou Berger; Khuzema Pithewan
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] TS in Signaling

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.

> -----Original Message-----
> 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
> Subject: Re: [CCAMP] TS in Signaling
> 
> 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
> >
> > -----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
> >
> >
> >> -----Original Message-----
> >> From: Fatai Zhang [mailto:[email-masked]]
> >> Sent: Wednesday, July 27, 2011 10:57 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 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,
> >>
> >> 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
> >>> ----- Original Message -----
> >>> From: "John E Drake" <[email-masked]>
> >>> 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]>
> >>> 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.)
> >>>
> >>> 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

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 28 Jul 2011 18:51:46 +0800

Hi all,

TS field issue induces so much discussion, so I have to repeat something clearly (something I said before). 

Why I introduced TS field in the label format? because there is no length field for the variable bitmap in the label format of section 5.1,  I am trying to use TS (2 bits) to deduce the length of the variable bitmap for validation (ie., the role of TS field is equivalent to length field). If there is length field (at least 8 bits) for the variable bitmap, I agree that it does not need TS field in the label format, :-).

I almost completely agree on what Biao said, more specifically:

(1) A refinement description on TSG deduction: TSG (used by the downstream) can be deduced from signal type (in the traffic parameters) + OTUk/FA (in the RSVP-HOP) + length of the bitmap. 

(2) Fully agree with Biao on H-LSP case analysis.

Fatai

Thanks

---

From: Lou Berger <[email-masked]>
Date: Thu, 28 Jul 2011 07:40:38 -0400

Biao,

WRT topic 1: link level
Label allocation will certainly need to represent the TS(s) allocated
for an LSP.  A scheme along the lines you suggest is likely to be needed
and is likely to fall out of standard label negotiation, but it would be
better for nodes to know this per link information before signaling
begins and to avoid "probes"/negotiation.  Historically such "discovery"
is supported in GMPLS through link management, i.e., configuration or
LMP.  As others have said before, and I agree, I'd expect that a node to
learn it's neighbor's supported TSG via configuration or LMP.  Of course
this does mean that we'll need some work on LMP.

WRT topic 2: H-LSPs
I think what you're saying is consistent with the general discussion
(and the reverse).  It sounds to me that you're proposing that in the
simple case, the end-to-end information indicate the smallest ODU
supported by the H-LSP. Is this correct?

What do think is needed to represent the cases where this is insufficient?

Lou

---

From: John E Drake <[email-masked]>
Date: Thu, 28 Jul 2011 05:40:04 -0700

Biao,

Wrt your comments about TS size, there doesn't seem to be consensus as to whether the auto-detect procedure is mandatory between the nodes at either end of an ODUk/OTUk link.  If it is then it will determine the correct tributary size and tell both nodes' control planes;  hence, TS size is not required in signaling.

If auto-discovery is not mandatory, then the nodes at either end of the link can each announce the TS size of their interface in routing by adding a field (or fields) in the ISCD.  The control planes in the nodes can then effectively run the auto-discovery procedure and determine the correct tributary size; again, TS size is not required in signaling.  

Lou, Fatai, and I proposed yesterday to have a common definition between routing and signaling simply to keep everything consistent and to anticipate the case of different TS size by signal type in the future.

Wrt your comments about hierarchical LSPs, I think they are correct but apply more generally to ODUk/OTUk links as well.  Viz, either a hierarchical LSP or an ODUk/OTUk link can concurrently support multiple paths (single or multi-stage) through the OTN hierarchy.

I think this means that when a hierarchical LSP between a pair of interfaces is established, *none* of the paths through the OTN hierarchy should be specified at the time of its establishment.  So, what we are establishing is a pipe, very similar to an ODUk/OTUk link.  (Jonathan used something like "GPID = explicit null" to refer to this mode of LSP establishment.)

Subsequently, as we discussed earlier this week, if an ODUj needs to established over either a hierarchical LSP or an ODUj/OTUk link, any necessary intermediate LSPs are explicitly signaled and then the ODUj is signaled.

Should I use 'sequence of OTN multiplexing stages' rather the 'path through the OTN hierarchy'?

Thanks,

John 

Sent from my iPhone

> Of Biao Lu
> Sent: Wednesday, July 27, 2011 10:45 PM
> To: Margaria, Cyril (NSN - DE/Munich); ext Lou Berger; Khuzema Pithewan
> Subject: Re: [CCAMP] TS in Signaling - explicit encoding of TSG is not
> needed but multiplexing/adaptation information is needed for H-LSP
> 
> Hi folks:
> 
> Of Margaria, Cyril (NSN - DE/Munich)
> 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.
> 
> 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

---

From: Fatai Zhang <[email-masked]>
Date: Thu, 28 Jul 2011 21:14:55 +0800

Hi Lou,

Sorry for without careful review on some of the words from Biao.

I agree that TS size should be known by the both ends of a link through configuration or LMP before connection establishment, because crankback is not a good idea.

This kind of work for LMP has been captured in [draft-zhang-ccamp-gmpls-g709-lmp-discovery-04.txt].

Fatai

Thanks

---

From: Biao Lu <[email-masked]>
Date: Thu, 28 Jul 2011 13:24:52 +0000

Lou,

WRT topic #1: I agree with your points. I was referring to signaling encoding/procedure. We need link mgmt to understand tributary slot usage (this may include the TSG information). The point that I am trying to make is that signaling will still work if such information is absent if a default allocation scheme is used. 

WRT topic #2: I won't say that I am suggesting a simple case here. :) It is probably a more general case. The discussion in the group so far seems mostly focusing on TSG. But I think it is more important to focus on adaption capability of the H-LSP (i.e. the client signal needs to be mapped to the H-LSP). Once we have the adaptation information, the TSG information is not needed. Of course, topic #1 also applies here for H-LSP. Cyril Margaria's email also touched on adaption topic.

Biao

-----Original Message-----
From: Lou Berger [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 7:41 AM
To: Biao Lu
Cc: Margaria, Cyril (NSN - DE/Munich); Khuzema Pithewan; CCAMP; [email-masked]
Subject: Re: [CCAMP] TS in Signaling - explicit encoding of TSG is not needed but multiplexing/adaptation information is needed for H-LSP

Biao,

WRT topic 1: link level
Label allocation will certainly need to represent the TS(s) allocated for an LSP.  A scheme along the lines you suggest is likely to be needed and is likely to fall out of standard label negotiation, but it would be better for nodes to know this per link information before signaling begins and to avoid "probes"/negotiation.  Historically such "discovery"
is supported in GMPLS through link management, i.e., configuration or LMP.  As others have said before, and I agree, I'd expect that a node to learn it's neighbor's supported TSG via configuration or LMP.  Of course this does mean that we'll need some work on LMP.

WRT topic 2: H-LSPs
I think what you're saying is consistent with the general discussion (and the reverse).  It sounds to me that you're proposing that in the simple case, the end-to-end information indicate the smallest ODU supported by the H-LSP. Is this correct?

Lou

On 7/28/2011 1:44 AM, Biao Lu wrote:
> Based on these observations, I think there is a way to satisfy the 
> signaling requirements without explicitly encoding TSG in the message 
> and without knowing remote TSG information of a TE link or H-LSP. But 
> we need to carry multiplexing/adaptation information for H-LSP setup but not TSG.
> 
> Observations:
> How to support signaling over a link (i.e. Node A (TSG=1.25G) 
> ------------- Node B (TSG=2.5G) ) without each end knowing the remote TSG information?
> 
> 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 
>> From: [email-masked] [mailto:[email-masked]] On 
>> Behalf Of ext Lou Berger

---

From: Biao Lu <[email-masked]>
Date: Thu, 28 Jul 2011 13:52:52 +0000

John:

For TS size, there might be a confusion on this. The hardware is not doing TS size negotiation. Here is my understanding from current definition of G.709v3 (correct me if I am wrong):

   For a link of OTU2 with Node A (TSG=1.25G) ------------ Node B (TSG=2.G), if there is no path 
   provisioned or sending traffic on this link, hardware will _not_ know remote TSG information.
 
   What hardware can do is: 
   Once a ODU1 is provisioned and passing traffic, initially, Node A will 
   send with PT=21 for the ODU1, and node B will send with PT=20 for the ODU1. Once Node A 
   receives PT=20, it will start sending using PT=20 instead of PT=21.

   This is adaption fallback procedure not TSG negotiation procedure. Node B may or may not know
   The TSG information of Node A even after passing traffic.

As for future proof for new TS size, it is probably better not to explicit encode TSG at all 
because we don't know what kind of TS size is going to come in the future.

I agree that H-LSP case applies more generally to ODUk/OTUk links as well. I need to sync up
with you on the rest.

Thanks,
Biao

-----Original Message-----
From: John E Drake [mailto:[email-masked]] 
Sent: Thursday, July 28, 2011 8:40 AM
To: Biao Lu; Margaria, Cyril (NSN - DE/Munich); ext Lou Berger; Khuzema Pithewan
Cc: CCAMP; [email-masked]
Subject: RE: [CCAMP] TS in Signaling - explicit encoding of TSG is not needed but multiplexing/adaptation information is needed for H-LSP

Biao,

Thanks,

John 

Sent from my iPhone

> ---------
> ---- Node B (TSG=2.5G) )
> 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
> Behalf
> > 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
> > > 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
> > >

---

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

Hi, 
I think the correct reference would be to refer to G.798 (10/2010)
clause 14.4.10 
"PT: 

The function shall insert code "0010 0001" (ODU multiplex structure
supporting ODTUk.ts or
ODTUk.ts and ODTUjk) into the PT byte position of the PSI overhead as
defined in clause 15.9.2.1
of [ITU-T G.709] for k=4.

For k=2,3 the inserted PT code shall default to code "0010 0001". This
code may be replaced by
code "0010 0000" under control of the PT=21-to-PT=20 interworking
process described hereafter.
**When MI AUTOpayloadtype is activated** the function shall adapt a PT21
supporting port to a PT20
structure.
If the corresponding adaptation Sink provides the information of a PT=20
at the RI_ AcPT the
function shall fall back to PT=20 under the following conditions: The
MI_AUTOpayloadtype is
true and the HO ODU source is either not provisioned for any traffic
signal structure, or the HO
ODU2 source configured for one or more ODU1 signals to be mapped into
TS1/TS5 and/or
TS2/TS6 and/or TS3/TS7 and/or TS4/TS8, or the HO ODU3 source is
configured to support one or
more ODU1 signals mapped into TS1/TS17, TS2/TS18, TSi/TS16+I and/or one
or more ODU2
signals mapped into TSa/TS16+a/TSb/TS16+b/TSc/TS16+c/TSd/TS16+16 and no
other ODU type
signals. In this case the function shall insert PT20 into the PSI
positions.
In the case the ODU2 or ODU3 adaptation source is configured for either
ODU0,
or an ODUflex, or
an ODU2e, or for an ODU1 in TSi/TSj with j<>4+i (for ODU2) or j<>16+I
(for ODU3) then PT21
is to be inserted. The inserted PT shall be reported at the
ODUkP/ODUj-21_A_So_RI_TrPT to the
corresponding adaptation sink function and the
ODUkP/ODUj-21_A_So_MI_TrPT."

So my understanding of this rather dense statement is that if
auto-negotiation is active 
(it seems allowed to de-activate it) the PT will be negotiated by the
data plane, but this
Is not strictly mandatory.

If both end of the ODUk link do not agree compatibility rules have to be
used.

Feel free to correct me if I missed something.

> From: ext Biao Lu [mailto:[email-masked]]
> Sent: Thursday, July 28, 2011 9:53 AM
> To: John E Drake; Margaria, Cyril (NSN - DE/Munich); ext Lou Berger;
> Khuzema Pithewan
> Subject: RE: [CCAMP] TS in Signaling - explicit encoding of TSG is not
> For TS size, there might be a confusion on this. The hardware is not
> doing TS size negotiation. Here is my understanding from current
> definition of G.709v3 (correct me if I am wrong):
> 
> As for future proof for new TS size, it is probably better not to
> explicit encode TSG at all because we don't know what kind of TS size
> is going to come in the future.
> 
> I agree that H-LSP case applies more generally to ODUk/OTUk links as
> well. I need to sync up with you on the rest.
> 
> Thanks,
> Biao
> 
> 
> To: Biao Lu; Margaria, Cyril (NSN - DE/Munich); ext Lou Berger;
Khuzema
> Pithewan
> Subject: RE: [CCAMP] TS in Signaling - explicit encoding of TSG is not
> Wrt your comments about TS size, there doesn't seem to be consensus as
> to whether the auto-detect procedure is mandatory between the nodes at
> either end of an ODUk/OTUk link.  If it is then it will determine the
> correct tributary size and tell both nodes' control planes;  hence, TS
> size is not required in signaling.
> 
> If auto-discovery is not mandatory, then the nodes at either end of
the
> link can each announce the TS size of their interface in routing by
> adding a field (or fields) in the ISCD.  The control planes in the
> nodes can then effectively run the auto-discovery procedure and
> determine the correct tributary size; again, TS size is not required
in
> signaling.
> 
> Lou, Fatai, and I proposed yesterday to have a common definition
> between routing and signaling simply to keep everything consistent and
> to anticipate the case of different TS size by signal type in the
> future.
> 
> Wrt your comments about hierarchical LSPs, I think they are correct
but
> apply more generally to ODUk/OTUk links as well.  Viz, either a
> hierarchical LSP or an ODUk/OTUk link can concurrently support
multiple
> paths (single or multi-stage) through the OTN hierarchy.
> 
> I think this means that when a hierarchical LSP between a pair of
> interfaces is established, *none* of the paths through the OTN
> hierarchy should be specified at the time of its establishment.  So,
> what we are establishing is a pipe, very similar to an ODUk/OTUk link.
> (Jonathan used something like "GPID = explicit null" to refer to this
> mode of LSP establishment.)
> 
> Subsequently, as we discussed earlier this week, if an ODUj needs to
> established over either a hierarchical LSP or an ODUj/OTUk link, any
> necessary intermediate LSPs are explicitly signaled and then the ODUj
> is signaled.
> 
> > I like to bring everybody attention on a couple of observations on
> TSG
> > topic.
> >         A link that uses 1.25G TS can support any of the OTN
> payloads.
> > A link that uses
> >     2. In current signaling draft, the TSG information can be
derived
> > from signal type + the
> >         set, we can derive TSG to be 2.5G. If there are 2 bits set,
> we
> > can derive TSG to be
> >         1.25G. So there is no ambiguity in configuring the HW based
> on
> > current label
> >          There is a need for signaling to ensure that the H-LSP
being
> > setup can support the client
> >          In another case, if the ODU2 H-LSP is triggered by a ODU1
> LSP
> > setup, then the one end
> > Overall the TS is independent of the signal type, TS is a property
of
> > a single multiplexing stage.

---

From: Daniele Ceccarelli <[email-masked]>
Date: Sun, 31 Jul 2011 22:00:40 +0200

Lou,

[cut]
"I'd expect that a node to learn it's neighbor's supported TSG via configuration or LMP.  Of course this does mean that we'll need some work on LMP."

Fully agree with your statement. Moreover the work has already been started a couple of years ago (-00 version)
 http://tools.ietf.org/id/draft-zhang-ccamp-gmpls-g709-lmp-discovery-04

We interrupted the work on LMP for a while given the higher priority on requirements, signaling and routing but is already there.

Thanks
Daniele

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: giovedì 28 luglio 2011 13.41
To: Biao Lu
Cc: CCAMP; [email-masked]
Subject: Re: [CCAMP] TS in Signaling - explicit encoding of TSG is not needed but multiplexing/adaptation information is needed for H-LSP

Biao,

WRT topic 1: link level

WRT topic 2: H-LSPs

Lou