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

Comments on GMPLS generalized signaling



I am sending this e-mail with comments on draft-ietf-mpls-generalized-signaling again as I haven't received any comments on it and the proposed changes were not introduce in the 05 version.

In addition under LSP Encoding Type the date should be removed from SDH and SONET type, which makes the second SDH and SONET type (11 and 12) superfluous. This was already mentioned at the meeting.
Further Digital Wrapper should be changed to G.709.

Regards

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 introduction 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 following G-PIDs have to be removed as the mappings 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 (in a STS/STM LSP)
>                 Line/Multiplex Section (in a STS/STM LSP)
>                 Section/Regenerator Section (in a STS/STM LSP)
>                 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 the payload of an PDH LSP again, only of a SONET/SDH LSP and this is already defined. So they should be removed. 
> 
> 
> 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.
>                 
>