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

From: Lou Berger <[email-masked]>
Date: Tue, 27 Sep 2011 09:20:23 -0400

All / G.709 draft authors,

	We have a few slightly unaligned proposals on where to indicate the
[G.709-v3] Tributary Slot Granularity:

1: G-PID
    draft-ietf-ccamp-otn-g709-info-model-01 says:
    One possible solution is the G-PID field of the GENERALIZED LABEL
    REQUEST Object.

2: A new field:
   draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
      - TSG: Tributary Slot Granularity (2bit): Used for the
      advertisement of the supported Tributary Slot granularity

3: Implicitly:
   draft-zhang-ccamp-gmpls-evolving-g709-09 doesn't explicitly
   signal TSG, but rather has it implied in the new ODU label.

Some other alternatives include:

4: GMPLS Encoding
   Currently used to indicate G.709 (which is also what the Switch
   cap essentially indicates) An alternative would use:
      12              G.709 ODUk (Digital Path, 2.5G)[RFC4328]
      TBA (e.g., 15)  G.709 ODUk (Digital Path, 1.25G)

   In routing, 15 would imply support for both 1.25 and 2.5G, as
   support for both by 1.25 capable interfaces is required by
   [G.709-v3]. (At least as I understand it.)

5: Signal Type
   Carried in routing ISCD/SCSI and signaling traffic parameters.
   Could enumerate all ODUx types to indicate either 1.25G or 2.5G.
   Existing types indicate 2.5G, new types would need to be enumerated
   for the new 1.25 and 2.5 types.  Hereto, the 1.25 types would imply
   support for both 1.25 and 2.5 types in routing.

As I understand it, TSG is needed at:
  (a) the endpoints that terminate the signal/LSP to ensure proper
      adaptation.
  (b) the 2nd and penultimate hops to ensure the proper
      interface/H-LSP selection.
  (c) Intermediate nodes for proper TS allocation.

It seems to me that we have enough existing fields in GMPLS (for G.709)
that we should consider these before introducing new ones.  Of the
existing fields, we have 1, 4 and 5.:

   Option 1, G-PID, is really designed to support end-point client
   adaptation, so as an end-point only field it really only supports
   need (a), so I don't think G-PID is the right place to indicate TSG.

   Option 4, Encoding, is used to support (a) and (b)-type checks in
   GMPLS, but not (c).  So, while this field is definitely a better
   place than G-PID to indicate TSG, it doesn't satisfy all the needs.

   Option 5, Signal Type, is used to support all needs.

Given all this, I'd like to propose that we use Option 5, Signal Type,
to indicate TSG, and that this be reflected in the relevant WG drafts.
(Authors, let me know if you'd like specific text proposals.)

Comments?

Much thanks,
Lou (as WG contributor)

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Sep 2011 07:23:05 -0700

Lou,

In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise tributary slot granularity in a new field.  In signaling (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from the length of the TS bit map and the size of the ODUk/OTUk on which the LSP is to be established.

Thanks,

John

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Lou Berger
> Sent: Tuesday, September 27, 2011 9:20 AM
> To: CCAMP
> Subject: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> _______________________________________________
> CCAMP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ccamp

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Sep 2011 10:31:51 -0400

John,
	I guess I should have titled my mail "Proposal on..." so that the
proposal would actually get read...

Lou

On 9/27/2011 10:23 AM, John E Drake wrote:
> Lou,
> 
> In routing (draft-ceccarelli-ccamp-gmpls-ospf-g709-07) we advertise
> tributary slot granularity in a new field.  In signaling
> (draft-zhang-ccamp-gmpls-evolving-g709-09), it is derived from the
> length of the TS bit map and the size of the ODUk/OTUk on which the
> LSP is to be established.
> 
> Thanks,
> 
> John
>

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Sep 2011 07:37:18 -0700

Nevermind.  What is wrong with the current signaling approach, which by the way I think is great?

> From: Lou Berger [mailto:[email-masked]]
> Sent: Tuesday, September 27, 2011 10:32 AM
> To: John E Drake
> Cc: CCAMP
> Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG
> 
> John,

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Sep 2011 10:58:19 -0400

John,
	There isn't alignment in the WG info-model and the individual routing
and signaling drafts.  I think we have enough ways of explicitly
carrying signal information that we can leverage to come up with a clean
an unified approach that satisfies all the needs for TSG information, i.e.:

> Given all this [see below], I'd like to propose that we use Option 5,
> Signal Type, to indicate TSG

Do you see an issue with using Signal Type to indicate the *service*
TSG?  I don't think there would be any change to your proposed
(hop-by-hop) label encoding.

Lou

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Sep 2011 08:13:20 -0700

Lou,

Clearly, the info-model draft needs to be updated, but I am quite happy with the what is currently in the signaling and routing drafts and I haven't heard a compelling reason to change.

Thanks,

John

> Sent: Tuesday, September 27, 2011 10:58 AM
> To: John E Drake
> Cc: CCAMP

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Sep 2011 11:28:45 -0400

John,
	Two points:

As a general rule, it doesn't make sense to invent yet another way to
carry information when an existing one will do.  This is actually a
pretty fundamental tenant of GMPLS.

Also, in GMPLS the general model for allocation is to carry resource
requirements in the TS not the label.  Such use of the TS ensures that
the information is unambiguous in all cases.  (For example, consider the
corner case where you have a unidirectional LSP, where is TSG
requirements of the sender/upstream node indicated in the Path message.)

Lou

On 9/27/2011 11:13 AM, John E Drake wrote:
> Lou,
> 
> Clearly, the info-model draft needs to be updated, but I am quite
> happy with the what is currently in the signaling and routing drafts
> and I haven't heard a compelling reason to change.
> 
> Thanks,
> 
> John
>

---

From: John E Drake <[email-masked]>
Date: Tue, 27 Sep 2011 09:40:33 -0700

Lou,

Using Signal Type in signaling in addition to the bit map label is probably okay.  I don't think it makes any sense in routing and would prefer to continue to just have the two bits.

Thanks,

John

> Sent: Tuesday, September 27, 2011 11:29 AM
> To: John E Drake
> Cc: CCAMP
> >> an unified approach that satisfies all the needs for TSG
> information,
> >> i.e.:
> >>
> >>> Nevermind.  What is wrong with the current signaling approach,
> which
> >> by the way I think is great?
> >>>
> >>>>>> 	We have a few slightly unaligned proposals on where to
> indicate
> >>>>>> the
> >>>>>>    need (a), so I don't think G-PID is the right place to
> indicate
> >>>> TSG.
> >>>>>>
> >>>>>>    Option 4, Encoding, is used to support (a) and (b)-type
> checks
> >> in

---

From: Lou Berger <[email-masked]>
Date: Tue, 27 Sep 2011 17:12:37 -0400

On 9/27/2011 12:40 PM, John E Drake wrote:
> Lou,
> 
> Using Signal Type in signaling in addition to the bit map label is
> probably okay. 

> I don't think it makes any sense in routing and would
> prefer to continue to just have the two bits.
> 

On what basis?

Lou

---

From: "Ong, Lyndon" <[email-masked]>
Date: Tue, 27 Sep 2011 19:36:32 -0400

Hi Lou,

Not quite sure what you are proposing - would this mean the signal type changes hop by hop if you are creating a connection that goes over links supporting different TS granularity?

Thanks,

Lyndon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Lou Berger
Sent: Tuesday, September 27, 2011 2:13 PM
To: John E Drake
Cc: CCAMP
Subject: Re: [CCAMP] Thought on where to carry G.709-v3 TSG

On what basis?

Lou

---

From: Lou Berger <[email-masked]>
Date: Wed, 28 Sep 2011 07:36:10 -0400

Lyndon,
	This is actually one of the reasons to make the change. Signal type
will represent the e2e constant connection characteristics, i.e., not
change, while label can change hop-by-hop as is needed to represent
how/where the connection is being carried on a a link.

Lou

On 9/27/2011 7:36 PM, Ong, Lyndon wrote:
> Hi Lou,
> 
> Not quite sure what you are proposing - would this mean the signal
> type changes hop by hop if you are creating a connection that goes
> over links supporting different TS granularity?
> 
> Thanks,
> 
> Lyndon
> 
> 
>

---

From: "BELOTTI, SERGIO (SERGIO)" <[email-masked]>
Date: Wed, 28 Sep 2011 14:02:40 +0200

Hi Lou,

Please see in line .

BR

Sergio and Pietro

-----Messaggio originale-----
Da: [email-masked] [mailto:[email-masked]] Per conto di Lou Berger
Inviato: martedì 27 settembre 2011 15.20
A: CCAMP
Oggetto: [CCAMP] Thought on where to carry G.709-v3 TSG

1: G-PID

[ALU]What inserted in the INFO draft , is the result of the discussion made in July on the subject, in the mailing , taking into account suggestion and comments coming from John, Jonathan and others participating at the discussion.
Our opinion is that the ending draft for signaling should be aligned to the info model draft incorporating the required changes to GPID. The motivations behind our opinion can be better understood reading the other comments.

2: A new field:
   draft-ceccarelli-ccamp-gmpls-ospf-g709-07 says:
      - TSG: Tributary Slot Granularity (2bit): Used for the
      advertisement of the supported Tributary Slot granularity
[ALU] In the INFO we have explained the need also for TSG in routing (following conclusion of mailing list discussion) and the routing draft simply proposes a possible encoding of the information.
This solution, for the sake of truth, can be getting better, taking into account the AutoPayloadtype flag information. This information is a typical MI information , described in in G.798, and it simply tells us whether Fallback procedure is enabled or not. 
Since this information is typically configured by the manager we do not think it has to be considered directly in the control plane (neither signaled or advertised ). However we have to take into account the fact that
auto-payload type set to off generates interfaces that can support 1.25 TSG only. 

This fact can be incorporated in routing by adding a new meaning in the two bits encodings:

         - 00 - 1.25 Gbps (AutoPayloadtype off)

         - 01 - 1.25 Gbps (AutoPayloadType on)

         - 10 - 2.5 Gbps 

         - 11 - Reserved

3: Implicitly:

[ALU] There is nothing implicitly. The reality is that at the moment signaling draft does not address the problem . What you consider as "implicitly deduced" is in fact the TSG granularity with which the client is mapped in the server ODUk/OTUK or FA/H-LSP. What has to be clarified is that what we need to signal is an adaptation information regarding what the server can expose to the client regarding TS granularity capability. 
TS size is an attribute of the adaptation used to put an ODUj into an ODUk.
What you consider as implicit is just how ODUj is mapped into ODUk, but the problem is to signal ODUk with the correct adaptation attribute.

4: GMPLS Encoding

[ALU] Encoding field should define the nature of the LSP : RFC 4328 defined two OTN new values G.709 ODUk (Digital Path) and G.709 Optical Channel. We do not see any reason to link encoding with information that would need to choose interfaces (as TSG) since the "nature " of LSP does not change dependently of the usage of 1.25 or 2.5 ODUk tributary slot.

5: Signal Type

[ALU] During the discussion in July the usage of Signal Type was one of the first possibilities analyzed. We definitely leave out signal type for the reason above regarding adaptation information.
TS granularity is an information that server LSP has to expose to client LSP. What is related to the client is conveyed in the G-PID not in the Signal Type . 
There are no different Signal Type for the same ODU in OTN: e.g. ODU2 it is the same , what can change is the adaptation attribute towards client (e.g. 1.25 or 2.5 TSG for ODU1 client). 

[ALU] Item (c) is not correct. Intermediate nodes do not need to demultiplex client, you can have ODU0 LSPs , that surely need to have 1,25 interfaces in the end points but using 2.5 TSG in the middle of the network since they have tunneled on 2.5 structured containers. 

[ALU] G-PID is the correct place :
 1) It contains information related to client of an LSP that is exactly what we need.
2) As reported in RFC 3471 " This is used by the nodes at the endpoints of the LSP, and in some cases by the penultimate hop." We are exactly in these "some cases"

[ALU] Already commented why not the right places.

Comments?

Much thanks,
Lou (as WG contributor)

---

From: Lou Berger <[email-masked]>
Date: Wed, 28 Sep 2011 11:36:59 -0400

Sergio and Pietro,

It sounds like we should get in-sync on where TSG information is needed

>From your mail, I infer that you agree on (a) and (b).  Is this correct?

WRT to (c) you said:
> [ALU] Item (c) is not correct. Intermediate nodes do not need to
demultiplex client, you can have ODU0 LSPs , that surely need to have
1,25 interfaces in the end points but using 2.5 TSG in the middle of the
network since they have tunneled on 2.5 structured containers.

I'm having a hard time parsing your statement.  Are you saying (i) you
client ODU0 carried over an ODUn (n>0) H-LSP or (ii) and ODU0 which is
carried over links OTUn links and 2.5G slots in the intermediate links,
or (iii) something completely different.

Either way, isn't the case that it would be optimal to use 1.25 TSs for
certain ODUs (e.g., OD0, ODUFlex) on transit links when both ends of the
link support 1.25?

You also said:
> [ALU] In the INFO we have explained the need also for TSG in routing
> (following conclusion of mailing list discussion) and the routing
> draft simply proposes a possible encoding of the information.
>
> This solution, for the sake of truth, can be getting better, taking
> into account the AutoPayloadtype flag information. This information
> is a typical MI information , described in in G.798, and it simply
> tells us whether Fallback procedure is enabled or not.
> 
> Since this information is typically configured by the manager we do
> not think it has to be considered directly in the control plane
> (neither signaled or advertised ). However we have to take into
> account the fact that auto-payload type set to off generates
> interfaces that can support 1.25 TSG only.
> 

Okay, now I'm really confused.  This seems to imply that you are saying
the (c) above is needed.  What am I missing?

Much thanks,
Lou

---

From: "GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)" <[email-masked]>
Date: Thu, 29 Sep 2011 10:48:25 +0200

Hello Lou,

we try to make further clarification, with a long explanation in line ( sorry for this :-))

Pietro and Sergio

============================================
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: Lou Berger [mailto:[email-masked]] 
Sent: mercoledì 28 settembre 2011 17.37
To: BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; GRANDI, PIETRO VITTORIO (PIETRO VITTORIO)
Subject: Re: R: [CCAMP] Thought on where to carry G.709-v3 TSG

Sergio and Pietro,

>From your mail, I infer that you agree on (a) and (b).  Is this correct?
[[ALU]] We agree on (a) and (b). 

 
[[ALU]] We think that the better way to understand the problem is having in mind a reference model composed by:

A) The current LSP that we are drawing. 

B) The server resources used by the current LSP. These resources can be different link by link. The server resources can be represented in control plane either by TE-link or FA-LSP. When the server capacity is higher then
the capacity of the current LSP (we mean not at the same rate of the client) , the server is structured and the current LSP is adapted in the server using 1.25 or 2.5 tributary slots depending
from the capability of both the endpoints of the server.

C) A resource that is a client of the current LSP. This client can either be
an ODU or use a different technology. 

If the client in point c) is an ODU (or better a set of ODUs at different rates) then the current LSP will have (in future) to be structured in such a way that the ODU client(s) will be carried. 
In order to ensure that a client can be set two things must happen at the endpoint of the current LSP. The first one is that both endpoints declare the same set of clients, and the second is that both endpoint can support
the same tributary slot granularity. Note that it is not possible to infer the tributary slot granularity from the client-server hierarchies declared
by a TE-link. Just to make an example, take a TE-link that declares to support ODU2 over ODU3, ODU2 can be mapped over ODU3 either using 2.5 or 1.25 tributary slots. 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.   

In conclusion to this reasoning, when we signal the current LSP (of point A)
we need to transfer two information: The desired tributary slot granularity
that the current LSP will export to future clients and the set of clients (point C) that has to be supported (if known).
The desired tributary slot granularity to be exported to future clients directly affects the adaptation that will be instantiated when drawing a client. 
The desired tributary slot granularity is the entity that we are debating. Note that the desired tributary slot granularity for client does not
affect the label signaled for the current LSP. These labels are only affected by the tributary slot granularity exported by the server that is
carrying the current LSP.

Last but not least, note that the tributary slot granularity is not 
part of current LSP in the sense that does not exist an ODU2 at 1.25 TS
and does not exist an ODU2 at 2.5 TS. It only exist an ODU2 at a nominal rate mapped over a higher rate server using 2.5 or 1.25 TS.      

> certain ODUs (e.g., OD0, ODUFlex) on transit links when both ends of the

[[ALU]] Tributary Slots were originally introduced in order to avoid link defragmentation. They started at 2.5 that was correct for all ODUs (at that time) and following it was introduced 1.25 in order to better accommodate GbEthernet client (into ODU0 at 1,25) and also ODU-flex (CBR) .

ODU0 and ODU flex MUST be mapped over their server at 1.25. Just to make an example let's take an ODU0 LSP that has to be carried over an ODU2 LSP that in turn is mapped over several ODU3 LSPs. 

When signaling the ODU2 LSP we must ensure that at the endpoints the ODU2 LSP supports at the endpoints the 1.25 TS granularity. There is no need
(and it is not an optimization) to force the ODU2 LSP to use ODU3 LSPs
that export 1.25 TS.  

> the (c) above is needed.  What am I missing?

[[ALU]] the advertising of TS information in routing is coming from 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). As said before TS size is an adaptation attribute. When the TE-Link advertisement (whether a TE-Link created by an FA or a TE-Link that uses a physical link) includes details related to TSG, it is possible for routing to validate the compatibility of the endpoints with the service requested.
This has nothing to do with point c of your statement that would imply always along the path to have only one type of TS size.

Much thanks,
Lou