[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: GMPLS Last Calls
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.
>
>