Re: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)

[Fatai Zhang <[e-mail]>]

Hi Lou,



I incorporated your proposal into my table to facilitate the readers.



I think you still insist on reusing some existing G-PIDs like 58, 56.  For 0x04, why you think that RFC4328 does not cover it (ie., G-PID=54)?



Technically, I am not convince by your proposal, but I would like to reserve my opinion for your same motivation (ie., to conclude the discussion as soon as possible).



Any opinions on Lou's proposal from the WG? I will update the signaling draft based on Lou's proposal if there is no comment on Lou's proposal.



Note that all the new G-PID values will be re-ordered with TBA.


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


Payload Type in Hex code defined in G.709


G-PID



LSP Encoding


Note


Interpretation from G.709


0x01


None





Not needed


Experimental mapping (Note 3)


0x02


49


G.709 ODUk, G.709 OCh


1)G-PID defined in RFC4328;

2) Updated in this draft.


Asynchronous CBR mapping, see clause 17.2


0x03


50


G.709 ODUk


ditto


Bit synchronous CBR mapping, see clause 17.2


0x04


32


SDH, G.709 ODUk


ditto


ATM mapping, see clause 17.3


0x05


54

or

TBA (Suggested by Lou)

G.709 ODUk (and SDH)




G-PIDs defined in RFC4328 for framed GFP




GFP mapping, see clause 17.4


0x06


None





Not needed and Not defined in RFC4328


Virtual Concatenated signal, see clause 18 (Note 5)


0x07


61(TBA)

Or 55(Suggested by Lou)


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


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


0x08


62(TBA)

Or 58(Suggested by Lou)


G.709 ODUk (k=2e)


ditto


FC-1200 into OPU2e mapping, see clause 17.8.2


0x09


63(TBA)


G.709 ODUk (k=2)


ditto


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


0x0A


64(TBA)


G.709 ODUk (k=0)


ditto


STM-1 mapping into OPU0, see clause 17.7.1


0x0B


65(TBA)


G.709 ODUk (k=0)


ditto


STM-4 mapping into OPU0, see clause 17.7.1


0x0C


66(TBA)

Or 58(Suggested by Lou)


G.709 ODUk (k=0)


ditto


FC-100 mapping into OPU0, see clause 17.7.1


0x0D


67(TBA)

Or 58(Suggested by Lou)


G.709 ODUk (k=1)


ditto


FC-200 mapping into OPU1, see clause 17.7.2


0x0E


68(TBA)

Or 58(Suggested by Lou)


G.709 ODUflex


ditto


FC-400 mapping into OPUflex, see clause 17.9


0x0F


69(TBA)

Or 58(Suggested by Lou)


G.709 ODUflex


ditto


FC-800 mapping into OPUflex, see clause 17.9


0x10


51


G.709 ODUk


1)G-PID defined in RFC4328;

2) Updated in this draft.


Bit stream with octet timing mapping, see clause 17.6.1


0x11


52


G.709 ODUk


ditto


Bit stream without octet timing mapping, see clause 17.6.2


0x12


70(TBA)


G.709 ODUflex


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


IB SDR  mapping into OPUflex, see 17.9


0x13


71(TBA)


G.709 ODUflex


ditto


IB DDR mapping into OPUflex, see 17.9


0x14


72(TBA)


G.709 ODUflex


ditto


IB QDR mapping into OPUflex, see 17.9


0x15


73(TBA)


G.709 ODUk (k=0)


ditto


SDI  mapping into OPU0, see 17.7.1


0x16


74(TBA)


G.709 ODUk (k=1)


ditto


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


0x17


75(TBA)


G.709 ODUk (k=1)


ditto


1.485 Gbit/s SDI mapping into OPU1, see 17.7.2


0x18


76(TBA)


G.709 ODUflex


ditto


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


0x19


77(TBA)


G.709 ODUflex


ditto


2.970 Gbit/s SDI mapping into OPUflex, see 17.9


0x1A


78(TBA)

Or 56(Suggested by Lou)


G.709 ODUk (k=0)


ditto


SBCON/ESCON mapping into OPU0, see 17.7.1


0x1B


79(TBA)


G.709 ODUk (k=0)


ditto


DVB_ASI mapping into OPU0, see 17.7.1


0x20


47


G.709 ODUk


1) G-PIDs defined in RFC4328.

2) Updated in this draft.


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


0x21


59/60(TBA)


G.709 ODUk


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)


55


None





Not needed


Not available (Note 2)


66


None





Not needed


Not available (Note 2)


80-8F


None





Not needed


Reserved codes for proprietary use (Note 4)


FD


None

Or TBA(Suggested by Lou)





Not needed


NULL test signal mapping, see clause 17.5.1


FE


None

Or TBA(Suggested by Lou)





Not needed


PRBS test signal mapping, see clause 17.5.2


FF


None





Not needed


Not available (Note 2)
























Best Regards



Fatai





-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Lou Berger
Sent: Tuesday, May 21, 2013 9:17 PM
To: CCAMP
Cc: [e-mail]
Subject: [CCAMP] Closing Issue #49 (Was: Re: R: Closing G.709 open issues)



All,



In the interest of moving this discussion quickly to closure, I spent

some time trying to come up with the full list of G.709 PT to G-PID

mappings.  In coming up with this list I tried to be consistent with

the last consensus point that I can identify on this topic (the

previously referenced July 2012 thread & presentation), which included:



A) Defining new G-PIDs for client types not identified by an assigned

G-PID (per

http://www.iana.org/assignments/gmpls-sig-parameters/gmpls-sig-parameters.xml)



B) Reusing G-PID wherever {G-PID, ODU rate} unambiguously identify a

G.709 payload type, and define new G-PIDs when reuse not possible.



C) No G-PID value for unused, reserved, or proprietary 709 Payload Type.



Here's what I've come up with:



    G.709

   Payload

    Type   G-PID   Type/Comment    LSP Encoding

    ====   =====   ==============  ===================

    0x01           No standard value

    0x02    49     CBRa            G.709 ODUk

    0x03    50     CBRb            G.709 ODUk

    0x04    32     ATM             G.709 ODUk

    0x05    TBA1   Framed GFP      G.709 ODUk

    0x06    ???    Is any valued needed?

    0x07    55     Ethernet PHY    G.709 ODUk (k=0)

                   (transparent    G.709 ODUk (k=3)

                   GFP)            G.709 ODUk (k=4)

    0x08    58     Fiber Channel   G.709 ODUk (k=2e)

    0x09    TBA1   Framed GFP      G.709 ODUk (k=2e)

    0x0A    TBA2   STM-1           G.709 ODUk (k=0)

    0x0B    TBA3   STM-4           G.709 ODUk (k=0)

    0x0C    58     Fiber Channel   G.709 ODUk (k=0)

    0x0D    58     Fiber Channel   G.709 ODUk (k=1)

    0x0E    58     Fiber Channel   G.709 ODUflex

    0x0F    58     Fiber Channel   G.709 ODUflex

    0x10    51     BSOT            G.709 ODUk

    0x11    52     BSNT            G.709 ODUk

    0x12    TBA4   InfiniBand      G.709 ODUflex

    0x13    TBA4   InfiniBand      G.709 ODUflex

    0x14    TBA4   InfiniBand      G.709 ODUflex

    0x15    TBA5   Serial Digital  G.709 ODUk (k=0)

                   Interface

    0x16    TBA6   Serial Digital  G.709 ODUk (k=1)

                   Interface/1.001

    0x17    TBA5   Serial Digital  G.709 ODUk (k=1)

                   Interface

    0x18    TBA6   Serial Digital  G.709 ODUflex

                   Interface/1.001

    0x19    TBA5   Serial Digital  G.709 ODUflex

                   Interface

    0x1A    56     SBCON/ESCON     G.709 ODUk (k=0)

                   (IANA to update Type field)

    0x1B    TBA7   DVB_ASI         G.709 ODUk (k=0)

    0x1C    58     Fiber Channel   G.709 ODUk

    0x20    47     G.709 ODU-2.5G  G.709 ODUk

                                     (k=2,3)

                   (IANA to update Type field)

            TBA8   G.709 ODU-1.25G G.709 ODUk

                                     (k=1,2,3)

    0x21    TBA8   G.709 ODU-1.25G G.709 ODUk

                                     (k=2,3,4)

            TBA9   G.709 ODU-Any   G.709 ODUk

                                   (k=2,3)

    0x55           No standard value

    0x66           No standard value

    0x80-0x8F      No standard value

    0xFD    TBA10  Null Test       G.709 ODUk

    0xFE    TBA11  Random Test     G.709 ODUk

    0xFF           No standard value



Note that there are a few differences with Fatai's list, which doesn't

format well in e-mail, but is available in the archive

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



Please speak up if you think the above is not aligned with prior

consensus or if you have an issue with any of the above.



Much thanks,

Lou





On 5/20/2013 5:09 AM, Fatai Zhang wrote:

> Hi Lou,

>

>

>

> I think my mail on March 13rd may have answered your following comments.

> My response quoted as follows.

>

>

>

> In addition, if people look at the full list that I provided, I think

> people can realize that RFC4328 (section 3.1.3) used the same approach

> as the current approach of this draft (ie., 1:1 mapping between GPIDs

> and payload types defined by G.709), ie., we are following what RFC4328

> did.

>

>

>

> BTW, I am not sure if we need spend so much on discussing this point

> (because there is no issue to stick to the data plane by using the

> current approach of this draft).

>

>

>

> ======================================================================================================================

>

> (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 17, 2013 11:16 PM

> To: Fatai Zhang

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

> [e-mail]

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

>

>

>

> Fatai,

>

>

>

> That's a great start for the WG.  Thank you.

>

>

>

> To answer your implied question as to why my request for the full list.

>

> My feeling is that there have been too many "surprises" on the 709

>

> documents in areas that I thought were either obvious (but from the IETF

>

> & GMPLS context, not ITU-T or G.709 perspectives) or resolved by past

>

> discussions.  At this point, as co-chair and Document shepherd, I want

>

> to ensure that any open point on the documents are unambiguously closed

>

> and that past discussions (i.e., points of consensus) are 100% captured,

>

> so that we can smoothly move through the planned second LC and

>

> publication request.

>

>

>

> To that end, in my previous message I asked two questions about points

>

> where it seems you are proposing moving away from what has been

>

> previously been discussed & agreed to by the WG.  Can you answer the

>

> following:

>

>

>

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

>

>>>

>

>

>

> Much thanks,

>

> Lou

>

>

>

>

>

_______________________________________________

CCAMP mailing list

[e-mail]

https://www.ietf.org/mailman/listinfo/ccamp