| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Alan:
You're right it has not been explicitly specified and no one has worked on it as yet, but I feel RPR frames can be sent using rfc2615 (POS) framing with HDLC just as other frames are - with the same PSL value, etc. RPR frames (that look like Ethernet frames) can be easily sent using a PPP DLL (Data Link Layer) similar to those defined in rfc1700 (Assigned Numbers). Recall that PPP DLLs are defined for sending other L2 frames such as BPDU, Ethernet, PPP BCP, etc. (rfc1700 has a complete list). So we add a new DLL codepoint (possibly in coordination
with IANA) for sending RPR frames.
RPR frames can also be sent using _existing_ DLL codepoint for Ethernet. With this, an RPR frame with Ethernet-like structure is sent with existing DLL. Because an RPR header (such as TTL, etc.) is sent inside an Ethernet-like frame using an Ethertype, frames can be sent without requiring existing DLL.
The frame would look like:
Address (1 byte = 0xFF) + Control (1 byte = 0x03)
+ PPP DLL for Ethernet (2 bytes)
+ RPR DA (6) + RPR SA (6) + RPR Ethertype (2) + RPR header (TBD bytes) + Ethertype for payload (2) + actual payload (Native Ethernet or other payload)
Using an Ethernet-like framing for RPR helps leverage existing test equipments and other systems to install and test RPR operation and to use transparently existing Ethernet transport codepoints. Thus the only ID that RPR WG needs to apply for is an Ethertype for RPR header from IEEE..
As far as the HDLC header of 0xFF, 0x03 is concerned - it is perfectly ok to have these header, since all packets from one node end up at the next node where the packets are recovered using a de-scrambler and an HDLC controller and passed to RPR MAC for processing. Because optical networks are NBMA, all the packets are actually received at the next node and then the relevant packets are put back on the ring. This is true both for channelized and un-channelized modes of SONET/SDH. So the HDLC headers (with address as 0xFF) are used to deliver all
packets to the next node, and this is the correct operation.
On a related note, a protocol called MAPOS (Multiple Access Protocol over SONET) (rfc2171 - 2175 ) uses the ADDRESS field value to address specific stations over an optical ring network - achieving bandwidth efficiency by destination node addressing for approx. 256 stations
RPR frame transport can be easily achieved using existing mechanisms. The problem comes with those RPR MAC frame structure proposals that attempt to make a RPR frame look different from an Ethernet frame just for the sake of differentiation, even when there is no apparent benefit in doing so. It should be noted that RPR MAC is different not because bytes in framing have been moved around, but because of special media access requirements for ring networks. Frames that have fields like TTL, priority, etc. BEFORE the RPR DA make RPR frame
non-compliant with Ethernet framing - requiring not only special frame transport but special equipments for testing.
It is good you brought this issue up; and please give your recommendations about transport issues the way you see it.
Best regards,
Pankaj
Alan Weissberger wrote:
> 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