The MPLS WG Archive

[Heiles Juergen <Juergen.Heiles@icn.siemens.de>]

I am sending this email again as comments on the GMPLS last call, as I havent received any response up to now on my comments.

Juergen

> -----Original Message-----
> From:	Heiles Juergen [SMTP:Juergen.Heiles@icn.siemens.de]
> Sent:	Monday, May 07, 2001 5:08 PM
> To:	mpls@UU.NET; ccamp@ops.ietf.org
> Subject:	Comments on G-PID
> 
> I have several comments on the G-PID defintion in draft-ietf-mpls-generalized-signaling-04.txt.
> 
> Juergen
> 
> 
> 
> The G-PID not only identifies the payload type of a LSP, it also identifies the specific mapping method if several mapping methods exist for the same paylaod type into one LSP. This should be reflected in the G-PID intorduciton text
> "An identifier of the payload carried by an LSP (client layer of that LSP) and if necessary of the mapping method used for this payload."
> 
> Moreover the G-PID makes only sense in the context of the specific LSP type and technology. As already a technology specific document is introduce for SONET/SDH it would make more sense to move the G-PID to the technology specific documents. That would make it a lot easier to maintain the G-pid values and documents. As the G-PID is always related to a specific LSP type/technology it is not necessary to assign unique numbers for all paylaod and mapping types. The same value can be reused with tidfferent LSP types/technologies. If a new technology is introduced in the future (e.g. G.709) with a new ID, the specific G-PIDs for this technology can also be defined as part of the ID and no update to the main document is required.
> 
> Now to the detailed comments:
> The follwoing G-PIDs have to be removed as they are not defined:
>             8     Bit synchronous mapping of E3
>             9     Byte synchronous mapping of E3
>            12     Byte synchronous mapping of DS2/T2
> 
> As the VC type in which a payload is carried is defined by the LSP signal type itself it is not necessary to indicate it in additon in the G-PID. The following G-PIDs have to be removed therefore:
>            19     Same as 12 but in a VC-12
>            20     Same as 13 but in a VC-12
>            21     Same as 14 but in a VC-12
> 
> SONET and SDH uses the same payloads and mapping schemes. It is therefore possible to use the same G-PID values for SONET and SDH and remove some of the duplicated values. Furthermore additional mappings have to be added (e.g. FDDI, DQDB, GFP, transparent PDH signals):
> The whole set of SONET/SDH G-PIDs:
>                 Asynchronous mapping of E4 PDH framed
>                 Asynchronous mapping of E4 SDH framed
>                 Asynchronous mapping of E4 transparent
>                 Asynchronous mapping of DS3 M23
>                 Asynchronous mapping of DS3 C-Bit Parity
>                 Asynchronous mapping of DS3 transparent
>                 Asynchronous mapping of E3 PDH framed 
>                 Asynchronous mapping of E3 SDH framed 
>                 Asynchronous mapping of E3 transparent 
>                 Asynchronous mapping of DS2/T2
>                 Bit synchronous mapping of DS2/T2
>                 Asynchronous mapping of E1 framed
>                 Asynchronous mapping of E1 transparent
>                 Byte synchronous mapping of E1 framed
>                 Byte synchronous mapping of 31 * 64kbit/s
>                 Asynchronous mapping of DS1/T1 SF
>                 Asynchronous mapping of DS1/T1 ESF
>                 Asynchronous mapping of DS1/T1 transparent
>                 Bit synchronous mapping of DS1/T1 SF
>                 Bit synchronous mapping of DS1/T1 ESF
>                 Bit synchronous mapping of DS1/T1 transparent
>                 Byte synchronous mapping of DS1/T1 SF
>                 Byte synchronous mapping of DS1/T1 ESF
>                 VTG/TUG  
>                 STS Group/AUG
>                 POS - No Scrambling, 16 bit CRC
>                 POS - No Scrambling, 32 bit CRC> 
>                 POS - Scrambling, 16 bit CRC
>                 POS - Scrambling, 32 bit CRC
>                 ATM mapping
>                 FDDI mapping
>                 DQDB mapping
>                 GFP mapping
>                 LAPS IP (X.85)
>                 LAPS Ethernet (X.86)
>                 SDL, set-reset scrambler
>                 SDL, self-synchronizing scrambler
>                 O.181 test signal
> 
> Under the ANSI-PDH types DS3 M23 and DS3 C-Bit are listed. However as DS3 is at the bottom of the ANSI PDH hierachy it cannot be payload of an PDH LSP, only of a SONET/SDH and this is already defined. As I assume that no one will setup PDH LSPs the ANSI-PDH technology should be removed completley. The mapping into SONET/SDH is covered under SONET/SDH technology.
> 
> 
> The G-PIDs
> 
>            33     Ethernet                               Lambda, Fiber specific
>            34     SDH                                    Lambda, Fiber    "
>            35     SONET                                  Lambda, Fiber    "
>            36     Digital Wrapper                        Lambda, Fiber    "
>            37     Lambda                                 Fiber            "
> are not very specific as one doesn't get information on the specific signal (e.g. STM-64, STS-48, wavelenghts of the lambda signal). So how usefull are these values compared to unknown?
> "Digital Wrapper" should be removed. ITU defines in G.709 the OTH, however the OTH consits of several network layers (ODU, OTU, OCH, OMS, OTS) with a multi-wavelength signal at the bottom. The assignment of G.709 G-PIDS shouldbe done in a G.709 specific ID.
>                 
>