[RPRWG] RE: Potential Problem with P802.17/D0.1 PHY proposal Draft 0.34 and related .pdf slides=incorrect mapping to SONET/SDH
All,
A point of clarification on Alan's first point. T1X1.5 and ITU-T Q11/15 have made no decision regarding the extension header use for GFP with RPR frames. The liaison that came to T1X1.5 from 802.17 indicated that the null extension header was one of the possible (likely?) options to be recommended by 802.17, so we made due note of that possibility in our discussions. My interpretation of the T1X1.5 discussion do date is that we prefer to defer to the 802.17 recommendation regarding GFP extension header and MAC protocol for RPR frames. We don't like the idea of competing standards and would rather work closely with the IEEE to develop a common standard with each group contributing based on their core expertise. (In the case of T1X1.5, that expertise is in public transport networks and PSTNs.) It should be said, however, that, depending on the outcome and timing of the 802.17 work, the ITU-T may also retain its current definition of an optional ring extension header for !
GFP ring topologies.
Regards,
Steve Gorshe
Technical Editor:
ITU-T G.7041 (ex-G.gfp)
T1.105
T1.105.02
-----Original Message-----
From: Alan Weissberger
Sent: Saturday, November 17, 2001 11:26 AM
To: stds-802-17@xxxxxxxx
Cc: Steve Gorshe; 'weissber@xxxxxxxxxxxx'
Subject: 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