[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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.