Re: [CCAMP] R: Closing G.709 open issues

[Khuzema Pithewan <[e-mail]>]

Hi,

After offline discussion, agreed that G.709' Payload code is required to have 1:1 mapping with GPid, to resolve STM-1 and STM-4 ambiguity and to achieve, in general coherency between spec of Data plane and Control plane for interpretation of payload Identifier.

However, there is another question that has popped up. Need WG opinion on this.

G.709-2012 Table 15-8 defines some reserved code point  to be used for proprietary payloads and also says that these payloads code will not be subject to standardization.

Question is, Should we also reserve equivalent number of GPIds in signaling that can be used along with those reserved dataplane code points? For reference, pls look at the bottom few lines in the table that Fatai sent out.

Best Regards
Khuzema




From: [e-mail] [mailto:[e-mail]] On Behalf Of Khuzema Pithewan
Sent: Sunday, May 19, 2013 5:57 PM
To: Fatai Zhang; Lou Berger; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; [e-mail]
Subject: Re: [CCAMP] R: Closing G.709 open issues

Hi Fatai,

I think we should (continue to)  keep GPid as technology indicator and use rate in signal Type to make sense of payload.

For example, FC-100, GPid = 43 (FiberChannel) and SignalType=ODU0 (10), will give you payload FC-100.

Do you see any case, where it can be ambiguous?

Thanks
Khuzema

From: [e-mail] [mailto:[e-mail]] On Behalf Of Fatai Zhang
Sent: Friday, May 17, 2013 1:28 PM
To: Lou Berger; BELOTTI, SERGIO (SERGIO)
Cc: CCAMP; [e-mail]
Subject: Re: [CCAMP] R: Closing G.709 open issues


Hi Lou,



I thought it should be sufficient for me to identify the *updated* and *new* G-PIDs in this draft (I compared [G.709-2003] and [G.709-2012], and checked RFC4328), but I would be happy to provide a full list for your request.



Please see the list below, and the new payload types introduced by [G.709-2012] (and the corresponding new G-PIDs defined in this draft) are in the light blue cells.



Please check if there is anything missed or wrong. Note that GPIDs like 32,47,49-52 have been updated in this draft.



Note that we as authors welcome any contributors for their contribution.



For you convenience, I also attached the word document.




G-PIDs vs Payload types defined in Table 15-8 of G.709


G-PID


LSP Encoding


Payload Type in Hex code defined in G.709


Note


Interpretation from G.709


None





0x01


Not needed


Experimental mapping (Note 3)


49


G.709 ODUk, G.709 OCh


0x02


1)G-PID defined in RFC4328;

2) Updated in this draft.


Asynchronous CBR mapping, see clause 17.2


50


G.709 ODUk


0x03


ditto


Bit synchronous CBR mapping, see clause 17.2


32


SDH, G.709 ODUk


0x04


ditto


ATM mapping, see clause 17.3


54

G.709 ODUk (and SDH)




0x05


G-PIDs defined in RFC4328 with two kinds of GFPs (Ethernet MAC (framed GFP)




GFP mapping, see clause 17.4


None





0x06


Not needed and Not defined in RFC4328


Virtual Concatenated signal, see clause 18 (Note 5)


61(TBA)


G.709 ODUk (k=0,3,4)


0x07


Is being defined in this draft (new payload type defined in [G.709-2012])


PCS codeword transparent Ethernet mapping:

·         1000BASE-X into OPU0, see clauses 17.7.1 and 17.7.1.1

·         40GBASE-R into OPU3, see clauses 17.7.4 and 17.7.4.1

·         100GBASE-R into OPU4, see clauses 17.7.5 and 17.7.5.1


62(TBA)


G.709 ODUk (k=2e)


0x08


ditto


FC-1200 into OPU2e mapping, see clause 17.8.2


63(TBA)


G.709 ODUk (k=2)


0x09


ditto


GFP mapping into Extended OPU2 payload, see clause 17.4.1 (Note 6)


64(TBA)


G.709 ODUk (k=0)


0x0A


ditto


STM-1 mapping into OPU0, see clause 17.7.1


65(TBA)


G.709 ODUk (k=0)


0x0B


ditto


STM-4 mapping into OPU0, see clause 17.7.1


66(TBA)


G.709 ODUk (k=0)


0x0C


ditto


FC-100 mapping into OPU0, see clause 17.7.1


67(TBA)


G.709 ODUk (k=1)


0x0D


ditto


FC-200 mapping into OPU1, see clause 17.7.2


68(TBA)


G.709 ODUflex


0x0E


ditto


FC-400 mapping into OPUflex, see clause 17.9


69(TBA)


G.709 ODUflex


0x0F


ditto


FC-800 mapping into OPUflex, see clause 17.9


51


G.709 ODUk


0x10


1)G-PID defined in RFC4328;

2) Updated in this draft.


Bit stream with octet timing mapping, see clause 17.6.1


52


G.709 ODUk


0x11


ditto


Bit stream without octet timing mapping, see clause 17.6.2


70(TBA)


G.709 ODUflex


0x12


Is being defined in this draft (new payload type defined in [G.709-2012])


IB SDR  mapping into OPUflex, see 17.9


71(TBA)


G.709 ODUflex


0x13


ditto


IB DDR mapping into OPUflex, see 17.9


72(TBA)


G.709 ODUflex


0x14


ditto


IB QDR mapping into OPUflex, see 17.9


73(TBA)


G.709 ODUk (k=0)


0x15


ditto


SDI  mapping into OPU0, see 17.7.1


74(TBA)


G.709 ODUk (k=1)


0x16


ditto


(1.485/1.001) Gbit/s SDI mapping into OPU1, see 17.7.2


75(TBA)


G.709 ODUk (k=1)


0x17


ditto


1.485 Gbit/s SDI mapping into OPU1, see 17.7.2


76(TBA)


G.709 ODUflex


0x18


ditto


(2.970/1.001) Gbit/s SDI mapping into OPUflex, see 17.9


77(TBA)


G.709 ODUflex


0x19


ditto


2.970 Gbit/s SDI mapping into OPUflex, see 17.9


78(TBA)


G.709 ODUk (k=0)


0x1A


ditto


SBCON/ESCON mapping into OPU0, see 17.7.1


79(TBA)


G.709 ODUk (k=0)


0x1B


ditto


DVB_ASI mapping into OPU0, see 17.7.1


47


G.709 ODUk


0x20


1) G-PIDs defined in RFC4328.

2) Updated in this draft.


ODU multiplex structure supporting ODTUjk only, see clause 19 (AMP only)


59/60


G.709 ODUk


0x21


1)Are being defined in this draft (new payload type defined in [G.709-2012]);

2) 59 for G.709 ODU-1.25G; 60 for G.709 ODU-any


ODU multiplex structure supporting ODTUk.ts or ODTUk.ts and ODTUjk, see clause 19 (GMP capable) (Note 7)


None





55


Not needed


Not available (Note 2)


None





66


Not needed


Not available (Note 2)


None





80-8F


Not needed


Reserved codes for proprietary use (Note 4)


None





FD


Not needed


NULL test signal mapping, see clause 17.5.1


None





FE


Not needed


PRBS test signal mapping, see clause 17.5.2


None





FF


Not needed


Not available (Note 2)


























Best Regards



Fatai





-----Original Message-----
From: Lou Berger [mailto:[e-mail]]
Sent: Wednesday, May 15, 2013 10:58 PM
To: BELOTTI, SERGIO (SERGIO); Fatai Zhang
Cc: Daniele Ceccarelli; CCAMP; [e-mail]
Subject: Re: R: Closing G.709 open issues



Sergio/Fatai,



On 5/15/2013 7:54 AM, BELOTTI, SERGIO (SERGIO) wrote:

> We (as authors" were asked to cope with the remaining issues to start second LC.

> One these "remaining issues" was as fro Lou's mil of May 9th

>

> 2) Verify that the complete list of G-PIDs are defined [SIGNALING]

>

>   In signaling document section 4, verify that all payload types

>   defined in G.709 (Summarized in Table 15-8) can be represented.

>   This issue can be resolved via an update or message to the list

>   stating that the verification took place.

>

> This is concluded by Fatai answer regarding G-PID check and 1:1 mapping.



And, based on the discussion, I (to be clear, as WG chair) have revised

the request by asking:

  "that the editors of the draft provide (and include in the document)

   a full list of Payload Type values (with the 0x value prefix or the

   values in decimal) and their corresponding G-PID values.  Also

   including Encoding Type as you [Fatai] have below is a good addition

   -- great idea!"



Given the level of discussion of this thread, I think this is a

completely reasonable way to avoid future confusion, particularly in

implementations.



Do the Authors/Editor need help in generating this complete list?



Do the Authors/Editor want (me) to issue a call for input on this list?

I suspect some in WG will be happy to jump in as it's an easy way to

get added as a contributor to the signaling draft.



>

> FATAI> For point 2), I compared [G.709-2003] and [G.709-2012], and checked the GPIDs defined in [RFC4328], I think the following new GPIDs (values could be 59-79) should be added (besides updating some GPIDs defined in RFC4328, like 32,47,49-52):

>

>     Value       G-PID Type             LSP Encoding Type

>      -----       ----------             -----------------

>    59(TBA)     G.709 ODU-1.25G        G.709 ODUk

>    60(TBA)     G.709 ODU-any          G.709 ODUk

>    61(TBA)     PCS                    G.709 ODUk (k=0)

>    62(TBA)     FC-1200                G.709 ODUk (k=2e)

>    63(TBA)     eOPU2                 G.709 ODUk (k=2)

>    64(TBA)     STM-1                  G.709 ODUk (k=0)

>    65(TBA)     STM-4                  G.709 ODUk (k=0)

>    66(TBA)     FC-100                 G.709 ODUk (k=0)

>    67(TBA)     FC-200                 G.709 ODUk (k=1)

>    68(TBA)     FC-400                 G.709 ODUflex

>    69(TBA)     FC-800                 G.709 ODUflex

>    70(TBA)     IB SDR                 G.709 ODUflex

>    71(TBA)     IB DDR                 G.709 ODUflex

>    72(TBA)     IB QDR                 G.709 ODUflex

>    73(TBA)     SDIa                   G.709 ODUk (k=0)

>    74(TBA)     SDIb                   G.709 ODUk (k=1)

>    75(TBA)     SDIc                   G.709 ODUk (k=1)

>    76(TBA)     SDId                   G.709 ODUflex

>    77(TBA)     SDIe                   G.709 ODUflex

>    78(TBA)     SB/ESCON              G.709 ODUk (k=0)

>    79(TBA)     DVB_ASI                G.709 ODUk (k=0)

>



> All this has nothing to do with specifc ADAPTATION object , for which  I was always in favour but it seems as though it is linked to MRN discussion and out of specifc OTN.

>



So I went looking for past discussions on this, and this is what I find:



- From http://www.ietf.org/mail-archive/web/ccamp/current/msg13598.html

On 7/19/2012 11:45 AM, Lou Berger wrote:

> (As participant in thread) I read that the conclusion is to not optimize

> for a very special corner case and:

> 1) basically treat the intra-OTN case the same as any other MRN/MLN case

>    (leveraging GPID, and no new hierarchy object)

> 2) Use Daniele's new draft on MRN/MLN as the starting point in the

> discussion of how to address the limitations in MRN/MLN identified in

> this discussion.



>From http://tools.ietf.org/agenda/84/slides/slides-84-ccamp-7.pdf

> G-PID Value Extension

> o Extended G-PID for G.709 ODU client signals:

>   Value G-PID Type TSG (LO ODU into requested LSP)

>   ----- ---------- ----------------

>   47 G.709 ODU 2.5Gbps [RFC4328]

>   59(TBA) G.709 ODU-1.25G 1.25Gbps (new)

>   60(TBA) G.709 ODU-any either 1.25 or 2.5Gbps(new)

>

> o Added other new G-PID values for new client signals supported by G.709V3

>   Value G-PID Type

>   ----- ----------

>   61(TBA) CBRc (via GMP)

>   62(TBA) 1000BASE-X

>   63(TBA) FC-1200

>

> o Updated some existing G-PID description to support new 1.25G, 100G,

>   supra-2.488G client signals, such as 32 for ATM, 49 for asynchronous

>   CBR , 50 for synchronous CBR , 51 for BSOT, 52 for BSNT.



I have not interest/need to revist past consensus on G-PIDs & TSGs, so

will limit my comments to the newly defined G-PIDs.



My questions on the new G-PIDs come down to:

- Why are rate specific G-PIDs being proposed (rather than

  continuing to use the previous approach documented in the draft

  and in Section 3.1.3 of rfc4328)?



- Why are new values being defined rather than using existing

  values, e.g., G-PID 56?



That's it.



Lou



> Hope this can help.

>

> Best Regards

> Sergio

>

> Belotti Sergio-  System Architect

> ALCATE-LUCENT  Optics Division

> via Trento 30 Vimercate (MB) - Italy

> phone [phone]

>

> -----Messaggio originale-----

> Da: Lou Berger [mailto:[e-mail]]

> Inviato: mercoledì 15 maggio 2013 13.22

> A: Daniele Ceccarelli; Fatai Zhang

> Cc: BELOTTI, SERGIO (SERGIO); CCAMP; [e-mail]; [e-mail]

> Oggetto: RE: Closing G.709 open issues

>

> Daniele,

>

> On May 15, 2013 4:20:25 AM Daniele Ceccarelli

> <[e-mail]<mailto:[e-mail]>> wrote:

>> Hi Lou,

>>

>> Just a bit.

>>> My memory is that the consensus at the time was that G.709 would continue

>> to use the current generic approach to edge adaptation & G-PIDs, and that

>> (some of) the G.709 authors would submit a draft that would address

>> adaptation in a generic fashion.

>>>

>>

>> If i correctly remember we agreed to solve the routing issu in a generic

>> approach, not the signaling one.

>

> We must be thinking of different threads. The one I'm thinking of started

> with the comment along the lines of "why only some G-PIDs represented in

> the ADAPTATION object" and concluded with the agreement to drop the object

> and follow the current generic approach as well as look into a non-OTN

> specific solution in a new draft.  At least that's how I remember it....

>

>> It is possible to assume that the adaptation is a known info to the

>> operator and hence that the advertisement can be postponed and addressed in

>> a generic way but it needs to be signaled.

>>

>> This is an hortogonal issue with respect to the mapping of G-PID, which has

>> always been assumed to be 1:1 with G.709 values.

>

> humm, this seems inconsistent with Fatai  recently suggesting that i was

> asking for a "non-grouped" approach.  At the time, I was really just

> thinking about the values missing in the list I sent out. I don't recall

> any other discussion on moving away from the past 709 G-PID assignment

> approach.

>

>> The 1:1 *mapping* approach used by Fatai is different from the *mapping"

>> protocol like GFP, AMP that we discussed before.

>>

>

> It looks like we both/all should take a look at the archives to refresh our

> memories....

>

> Thanks,

>  Lou

>

>> BR

>> Daniele, Sergio, Fatai

>>

>>

>>> -----Original Message-----

>>> From: Lou Berger [mailto:[e-mail]] Sent: martedì 14 maggio 2013 16.01

>>> To: Fatai Zhang

>>> Cc: BELOTTI, SERGIO (SERGIO); Daniele Ceccarelli; CCAMP;

>> [e-mail];

>> [e-mail]

>>> Subject: Re: Closing G.709 open issues

>>>

>>> Fatai, Sergio,

>>>          I haven't had time to go find the old mail covering the topic you

>> mentioned (which is why I didn't respond yesterday):

>>>> I think this has been discussed for quite long time before Vancouver

>> meeting, which was famous as "penultimate" issue.

>>>>

>>>> I don't think we need discuss this anymore.

>>>

>>> My memory is that the consensus at the time was that G.709 would continue

>> to use the current generic approach to edge adaptation & G-PIDs, and that

>> (some of) the G.709 authors would submit a draft that would address

>> adaptation in a generic fashion.

>>>

>>> Do you think this characterization is mistaken?  (If so, time to go

>> searching for the old discussion, if not we can move on.)

>>>

>>> Assuming no, then it seems to me that you are going against this

>> discussion & consensus by now introducing a 1:1/bandwidth specific mapping

>> approach. Do you disagree?  If not, do you think there's justification to

>> reopen this discussion?

>>>

>>> Independent of the mapping approach and in order to ensure this issue is

>> closed and does not again resurface, I also request (again) that the

>> editors of the draft provide (and include in the document) a full list of

>> Payload Type values (with the 0x value prefix or the values in

>>> decimal) and their corresponding G-PID values.  Also including Encoding

>> Type as you have below is a good addition -- great idea!

>>>

>>> Lou

>>>

>>> On 5/14/2013 1:53 AM, Fatai Zhang wrote:

>>>> Hi all,

>>>> Thanks, Sergio.

>>>> I would like to double check if everything is OK before we >update the

>> signaling draft.

>>>> I would assume the WG is happy with 1:1 mapping approach and >the new

>> GPIDs listed below if there is no more comment until this Wed.

>>>>

>>>> Best Regards

>>>> Fatai

>>>>

>>>> -----Original Message-----

>>>> From: BELOTTI, SERGIO (SERGIO) [mailto:[e-mail]]

>>>> Sent: Monday, May 13, 2013 3:45 PM

>>>> To: Fatai Zhang; Lou Berger

>>>> Cc: Daniele Ceccarelli; CCAMP;

>> [e-mail];

>> [e-mail]

>>>> Subject: R: Closing G.709 open issues

>>>> Hi Fatai,

>>>> I agree with you, for both point 1 and 2.

>>>> Best Regards

>>>> Sergio

>>>> Belotti Sergio-  System Architect

>>>> ALCATE-LUCENT  Optics Division

>>>> via Trento 30 Vimercate (MB) - Italy

>>>> phone [phone]

>>>> -----Messaggio originale-----

>>>> Da: Fatai Zhang [mailto:[e-mail]]

>>>> Inviato: lunedì 13 maggio 2013 5.33

>>>> A: Lou Berger

>>>> Cc: Daniele Ceccarelli; CCAMP;

>> [e-mail];

>> [e-mail]

>>>> Oggetto: RE: Closing G.709 open issues

>>>> Hi Lou,

>>>> I think you have two major points here.

>>>> (1) Do you really need 3 G-PID types for an ODU (I thought >TSG was

>> already covered)?

>>>> I think this has been discussed for quite long time before >Vancouver

>> meeting, which was famous as "penultimate" issue. >Note that this TSG in

>> GPID is different from the *implicit* >TSG in label format.

>>>> I don't think we need discuss this anymore.

>>>> (2) 'Grouped GPID' vs '1:1' mapping (between G.709-2012 and GPIDs

>> defined in this draft)

>>>> We realize that it is safe to use 1:1 mapping approach to >avoid some

>> potential issues after investigation. We know this >payload types have been

>> defined by G.709 (data plane), so >physically it is better to use 1:1

>> mapping approach. For the potential issues I mentioned above, for example,

>> we >cannot use the existing 34 to represent 'STM-1' and 'STM-4 ', >because

>> it is impossible to differentiate which one is 'STM-1' >or 'STM-4'. In

>> addition, from the concept of payload type, we >know that e.g, FC-100 is

>> different from FC-800, right? So, it >is better to assign different GPIDs

>> to these different payload >types defined by the data plane.

>>>> Furthermore, I think it is much cheaper to create new GPIDs >in the

>> control plane than in the data plane (these payload >types will be carried

>> in the OH).

>>>>

>>>> Best Regards

>>>> Fatai

>>>>

>>>> -----Original Message-----

>>>> From: Lou Berger [mailto:[e-mail]]

>>>> Sent: Friday, May 10, 2013 8:51 PM

>>>> To: Fatai Zhang

>>>> Cc: Daniele Ceccarelli; CCAMP;

>> [e-mail];

>> [e-mail]

>>>> Subject: Re: Closing G.709 open issues

>>>>

>>>> On 5/9/2013 9:41 PM, Fatai Zhang wrote:

>>>>> Hi Lou,

>>>>>

>>>>> For point 1), "1" should be dropped and "7" should be >corrected to "8"

>> in your proposed text. >> >> Great.

>>>>>>>

>>>>> I hesitate to make a decision on either approach, I would >like to

>> defer to the WG consensus.

>>>>>

>>>> I believe we already have a consensus position.  The question in my mail

>> was do we need to revisit it.  I take your response as a no. (thank you!)

>>>>>>> For point 2), I compared [G.709-2003] and [G.709-2012], and checked

>>>>> the GPIDs defined in [RFC4328], I think the following new GPIDs >>>

>> (values could be 59-79) should be added (besides updating >some GPIDs >>>

>> defined in RFC4328, like 32,47,49-52):

>>>>>

>>>> I suggest going through the full PT list and identifying them in the

>> table (as I started in my last message) so that there is no >confusion in

>> implementations.

>>>> In the list below it looks like you have moved away from the >'grouped

>> G-PID' approach.  Is there a reason for this change?

>>>> Refer to

>>>>> http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-paramet

>>>> ers.xml

>>>> in subsequent comments.

>>>>>>>     Value       G-PID Type             LSP Encoding Type

>>>>>      -----       ----------             -----------------

>>>>>    59(TBA)     G.709 ODU-1.25G        G.709 ODUk 60(TBA)     G.709

>> ODU-any          G.709 ODUk

>>>> Do you really need 3 G-PID types for an ODU (I thought TSG >was already

>> covered)?

>>>>>>>    61(TBA)     PCS                    G.709 ODUk (k=0)

>>>>>    62(TBA)     FC-1200                G.709 ODUk (k=2e)

>>>> Why not us existing G-PID 58?

>>>>>>>    63(TBA)     eOPU2                 G.709 ODUk (k=2)

>>>>>>>    64(TBA)     STM-1                  G.709 ODUk (k=0)

>>>>>    65(TBA)     STM-4                  G.709 ODUk (k=0)

>>>> Why not us existing G-PID 34?

>>>>>>>    66(TBA)     FC-100                 G.709 ODUk (k=0)

>>>>>    67(TBA)     FC-200                 G.709 ODUk (k=1)

>>>>>    68(TBA)     FC-400                 G.709 ODUflex

>>>>>    69(TBA)     FC-800                 G.709 ODUflex

>>>> Why not us existing G-PID 58?

>>>>>>>    70(TBA)     IB SDR                 G.709 ODUflex

>>>>>    71(TBA)     IB DDR                 G.709 ODUflex

>>>>>    72(TBA)     IB QDR                 G.709 ODUflex

>>>> Can these be one value with rate implying SDR/DDR/QDR?

>>>>>>>    73(TBA)     SDIa                   G.709 ODUk (k=0)

>>>>>    74(TBA)     SDIb                   G.709 ODUk (k=1)

>>>>>    75(TBA)     SDIc                   G.709 ODUk (k=1)

>>>>>    76(TBA)     SDId                   G.709 ODUflex

>>>>>    77(TBA)     SDIe                   G.709 ODUflex

>>>> Can these be one value with rate implying a-e?

>>>>>>>    78(TBA)     SB/ESCON              G.709 ODUk (k=0)

>>>> Why not us existing G-PID 56?

>>>>>>>    79(TBA)     DVB_ASI                G.709 ODUk (k=0)

>>>>>

>>>>>

>>>>>

>>>>>

>>>> Thanks,

>>>> Lou

>>>>

>>>>

>>>>

>>>

>

>

>

>

>

>