| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Alan,
regarding point 2
I took a look at GR-253, G.707 and T1.105.02 and could not find PPP specifically called out as a requirement. So I don't see any problem with using the "HDLC over SONET" code for the PSL as long as we comply with the stated requirements which include byte synchronous hdlc, payload scrambling etc..
I feel the PSL defines the mapping onto the SONET/SDH payload but does not restrict the use of the mapping to one protocol or another. If the PSL indicates "Asynchronous mapping for DS3", it does not preclude c-bit parity mode or m13 mode or hdlc encoding.
I agree with you in regards to the use of the term "POS". POS does imply PPP but that was not the intent. We should replace "POS" with "HDLC over SONET/SDH" and remove any references to PPP or the RFCs that define PPP or POS. Thanks for pointing this out.
Chuck Lee
-----Original Message-----
From: Alan Weissberger [SMTP:Alan_Weissberger@xxxxxxxxxxxxxx]
Sent: Saturday, November 17, 2001 2:26 PM
To: stds-802-17@xxxxxxxx
Cc: Steve Gorshe; 'weissber@xxxxxxxxxxxx'
Subject: [RPRWG] Potential Problem with P802.17/D0.1 PHY proposal Draft 0.34 and related .pdf slides=incorrect mapping to SONET/SDH
All
1. T1X1.5 and ITU SG15 have decided that RPR MAC frames are to be mapped to SONET/SDH using Frame Mode GFP with a null extension hdr. This was a direct result of the liaison that we sent to T1X1.5 as output from our Sept 2001 meeting (there was no mention of byte stuffed HDLC as an alternative mapping in that liaison). At the SG15 Nov meeting, GFP Ring mode text was removed in deference to the RPR-to GFP frame mode mapping.
This means there is currently no other way to map RPR MAC frames to SONET/SDH! In particular, RPR mapping over "POS" would not be recogized (there would be an incompatibility if one RPR node used GFP and the other used "POS" mapping)
2. Even more important, the Path Signal Label (PSL) code point assigned to "HDLC" in T1.105.02 (SONET) and G.707/G.783 (SDH) is for PPP over byte stuffed HDLC (AKA Packet over SONET or POS) with a specific payload scrambler. Using byte stuffed HDLC without PPP is not POS, as it is defined by the IETF. Thus, it would be a violation of use of that PSL code point. Hence, the referenced RPR PHY proposal for RPR- "POS" mapping to SONET/SDH violates the definition of POS (RFC ___), in addition to both T1.105.02 (SONET)and G.707/G.783 (SDH) stds.
I have copied Steve Gorshe -the editor of T1.105 series standards and G.gfp- in on this mail and have dissucesed this issue with him
I will be writing separate mails on why I feel the current RPR proposal are too complicated to be deployed and maintained by service providers
Rgds
alan
Alan J Weissberger
DCT
PO Box 3441
Santa Clara, CA 95055-3441
1 408 330 0564 voice
1 408 565 0335 fax