[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Comments on GMPLS generalized signaling/Question on gmpls-sdh-sonet last call
1. mpls-generalized-signaling-05:
I agree with the following mail from Juergen.
I had previously commented to remove the version numbers and
SDH/SONET/ETSI/ANSI specific labels. I thought it was agreed and so was
surprised to see it in the latest draft. These generalized LSP encoding
types are archaic and overly restrictive for allowing global connections.
Also, the G-PID is technology specific, as Juergen states. Including it in
the generalized-signaling draft creates confusion as there is
overlap/redundancy with the technology specific parameters.
The generalized-signaling draft should only provide general LSP encoding
types; referring to the technology-specific documents for specifics.
2. gmpls-sonet-sdh-01
Is this document for final comment by Aug 27 or will it be revised first?
Deborah Brungard
AT&T
-----Original Message-----
From: Heiles Juergen [mailto:Juergen.Heiles@icn.siemens.de]
Sent: Thursday, August 23, 2001 10:45 AM
To: 'ccamp@ops.ietf.org'
Subject: 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.
>
>