Stewart Bryant Internet Draft Lloyd Wood Document: draft-bryant-pwe3-fr-compare-00.txt Cisco Systems Ltd Expires: May 2002 October 2001 A Commentary on Approaches to Frame Relay Encapsulation in PWE3 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document compares and contrasts four approaches to Frame Relay encapsulation over a pseudo-wire that have been proposed in the Pseudo-Wire Edge-to-Edge (PWE3) IETF working group. This document then shows that the general-purpose encapsulation previously proposed for HDLC, Ethernet and VLAN is also the most efficient approach for Frame Relay. Bryant internet-draft - expires May 2002 1 draft-bryant-pwe3-fr-compare-00.txt October 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Overview........................................................2 2. The Martini encapsulation.......................................3 2.1 Comments on the Martini encapsulation..........................3 3. The Kawa encapsulation..........................................4 3.1 Comments on the Kawa encapsulation.............................5 4. Bryant Optimized Frame-Relay-specific control word..............6 4.1 Comments on Bryant Optimized Frame-Relay-specific control word.7 5. General Pseudo-wire Payload Encapsulation.......................7 5.1 Comments on General Pseudo-wire Payload Encapsulation..........8 6. Mapping between the Control Word and the Frame Relay Header.....8 6.1 Mapping between Martini control word and Frame Relay header....8 6.2 Mapping between Kawa control word and Frame Relay header.......9 6.3 Mapping between Bryant optimized Frame-Relay-specific control word and Frame Relay header.......................................10 6.4 Mapping between the General Pseudo-wire Payload Encapsulation and Frame Relay...................................................11 7. Frame Relay header translation.................................11 8. Conclusions....................................................13 9. IANA considerations............................................13 10. Security considerations.......................................13 11. References....................................................14 Authors' addresses................................................14 Full copyright statement..........................................15 1. Overview The design of the pseudo-wire encapsulation header can have considerable impact on the performance of the system using it. Drafts describing four Frame Relay encapsulation approaches have been presented. This document compares and contrasts these approaches and analyses their computational efficiency. From this analysis it is evident that the general-purpose encapsulation proposed for HDLC, Ethernet and VLAN is also the most efficient approach for Frame Relay. Bryant internet-draft - expires May 2002 2 draft-bryant-pwe3-fr-compare-00.txt October 2001 2. The Martini encapsulation The following relevant text is extracted from section 4.1 (Frame Relay) of [MARTINI] for convenient immediate reference. "A Frame Relay PDU is transported without the Frame Relay header or the FCS. The control word is REQUIRED; however, its use is optional, although desirable. Use of the control word means that the ingress and egress LSRs follow the procedures below. If an ingress LSR chooses not to use the control word, it MUST set the flags in the control word to 0; if an egress LSR chooses to ignore the control word, it MUST set the Frame Relay control bits to 0. "The BECN, FECN, DE and C/R bits are carried across the network in the control word. The edge routers that implement this document MAY, when either adding or removing the encapsulation described herein, change the BECN and/or FECN bits from zero to one in order to reflect congestion in the network that is known to the edge routers, and the D/E bit from zero to one to reflect marking from edge policing of the Frame Relay Committed Information Rate. The BECN, FECN, and D/E bits MUST NOT be changed from one to zero. "The following is an example of a Frame Relay packet: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd |B|F|D|C| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Relay PDU | | " | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ " As a reminder, definitions of bits as used in these drafts and in [Q.922] are: B is the BECN (Backward Explicit Congestion Notification) bit F is the FECN (Forward Explicit Congestion Notification) bit D is the DE (Discard Eligibility) bit C is the C/R (Command/Response) bit 2.1 Comments on the Martini encapsulation [MARTINI] takes the approach of copying Frame Relay payload- dependent bits to fields in the control word, stripping the Frame Relay header from the Frame Relay PDU, and reconstructing the header at the far end of the pseudo-wire. The reason for this approach is not given in [MARTINI]. Bryant internet-draft - expires May 2002 3 draft-bryant-pwe3-fr-compare-00.txt October 2001 The [MARTINI] approach to handling Frame Relay headers is inconsistent with the approaches used in the same draft for other encapsulation types. The encapsulation and de-capsulation processes can be made more efficient if the Frame Relay header is transmitted along with its accompanying PDU, in a manner consistent with the HDLC, Ethernet and VLAN encapsulation types. The layout and ordering of the B, F, D and C bits in the control word differ from the layout and ordering of these bits in the Frame Relay header. Resulting necessary bit manipulation in both encapsulation and decapsulation introduces unnecessary processing overhead in any implementation. We will show that this overhead can be avoided. 3. The Kawa encapsulation The following relevant text is extracted from section 6.1 of [KAWA] for reference: "FRoPW header structure is shown in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res |P|F|B|D|C|X|Y| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - FRoPW header structure "The meaning of the fields is as follows: Res (bits 0 to 2): Reserved bits. They are set to zero on transmission and ignored on reception. "P - Payload Type (bit 3): If set to zero then the payload field contains user's data else it contains network maintenance data. "X, Y (bits 8 and 9): 1 0: First segment of a segmented FRoPW packet 0 1: Last segment of a segmented FRoPW packet 0 0: Neither the first nor the last segment of a segmented FroPW packet 1 1: Complete FRoPW packet "X and Y bits are used for segmentation and re-assembly of FroPW packet fragments when these capabilities are enabled in the two PEs terminating a PW. "Length (bits 10 to 15): The length field is used to pad short FRoPW packets over Ethernet PSN. The length field is used as follows: If the length of the layer 2 frame (consisting of layer two control information and layer 2 Bryant internet-draft - expires May 2002 4 draft-bryant-pwe3-fr-compare-00.txt October 2001 payload) is less than 64 bytes, the length field MUST be set to the FRoPW packet length. Otherwise the length field MUST be set to zero. The value of the length field, if non-zero, is used to remove any padding. "Sequence number (Bit 16 to 31): If not used it is set to zero by the sender and ignored by the receiver. Otherwise it specifies the sequence number of a complete FRoPW packet or a fragment. A circular list of sequence numbers is used. A sequence number takes a value from 1 to 65535 (2**16-1). Arithmetic modulo 2**16 is used to generate a new sequence number. "The sequence number must be used when segmentation and re-assembly are enabled between two peer PEs terminating a PSN tunnel. The sequence number may be used to detect out-of-order delivery of FRoPW packets when the PSN does not guarantee in-order delivery." 3.1 Comments on the Kawa encapsulation As with the [MARTINI] approach, the Frame Relay payload-dependent bits are copied to fields in the control word, the Frame Relay header is stripped from the Frame Relay PDU, and the header must be reconstructed at the far end of the pseudo-wire. Again, the reason for doing this is not given. The grouping and ordering of the payload-dependent bits in the [KAWA] control word is more consistent with Q.922, allowing them to be processed as a three bit group (FBD) and a single bit (C). This reduces the processing overhead in comparison with [MARTINI]. However, the [KAWA] draft fails to take advantage of the additional performance gains to be made by closely following the layout specified in [Q.922]. We have found the naming and polarity of the fragmentation bits introduced in [KAWA] confusing. Use of the name 'X' for the first segment indicator conflicts with common usage of the symbol 'X' to indicate "don't care" about the value of the bit. The polarity chosen fails to take advantage of the performance optimizations normally available in processor instruction sets. A common case is likely to be that the frame length is greater than 64 bytes, but less than the MTU. In the scheme described in [KAWA], this is indicated by setting bits 8..15 to the binary value <11000000>. We propose that the sense of the X and Y bits be reversed, and renamed to notStart (A) and notEnd (B) bits respectively. This is represented in the following two-bit state table: Bryant internet-draft - expires May 2002 5 draft-bryant-pwe3-fr-compare-00.txt October 2001 A, B (bits 8 and 9): 0 0: Complete packet (start and end) 0 1: First segment (start and not end) 1 1: Continuing segment (not start and not end) 1 0: Last segment (not start and end) This leads to the use of an ordered stream: 0{1111}0 , where the common case of an unfragmented frame that is greater than 64 bytes, but less than the MTU, is sent as <00000000>. This is straightforward and optimal to detect in normal software implementations. To provide space for the fragmentation bits, [KAWA] reduces the length of the length field from 8 bits to 6 bits. Some rationale needs to be provided that explains the reason for this approach rather than maintaining 8-bit length compatibility with the other encapsulation drafts, and using an additional two bits from the reserved field instead. The need to fragment a payload for transmission across a pseudo-wire is common to all payload types. It would therefore seem appropriate to move this to a common PWE3 header to be defined, rather than to use it in a specific Frame Relay method and later reinvent it for other payload types. This would restore the length field in [KAWA] to the expected 8 bits. The absence of a fragmentation mechanism in MPLS and IPv6 raises the question of whether fragmentation is a unique problem to PWE3 or a general problem that will need to be addressed by other transport types, such as [GRE]. If it were a general problem it would be better to further abstract the fragmentation support to a separate fragmentation layer above the PSN and below PWE3. The [KAWA] control word specifies the length field as a MUST, indicating that it is compulsory. This is wasteful of resources when the PSN is IP, because the IP payload length will always be present. 4. Bryant Optimized Frame-Relay-specific control word The following relevant text is extracted from section 2 (An Optimized Frame-Relay-specific control word) of [BRYANT] for reference: "An optimized Frame-Relay-specific control word would require no bit-manipulation operators to transform to and from the Frame Relay header. Such a control word is presented here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length |C|X|X|X|X|X|F|B|D|X| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bryant internet-draft - expires May 2002 6 draft-bryant-pwe3-fr-compare-00.txt October 2001 "The meaning of the fields is as follows: "Length (bits 0 to 5): The length field is used to indicate the payload length of a packet that may have been padded during transmission, if that information is not provided by the PSN encapsulation. If the length of the layer-two frame (consisting of layer-two control information and layer-two payload) is less than 64 bytes, the length field MUST be set to the Frame Relay PDU length. Otherwise the length field MUST be set to zero." 4.1 Comments on Bryant Optimized Frame-Relay-specific control word In this proposal the first two octets of the control word and the first two octets of a frame-relay header have the same payload specific bit layout, i.e. the CFB and D bits are located at the same positions in both the control word and header, allowing one to be constructed from the other using a read, mask, write operation. The length field is placed in the same location at the unused high- order DLCI bits and the remaining bits in the first two octets are unused. The length field is only used with PSN types that do not provide that information, and is therefore not required when an IP encapsulation is used. 5. General Pseudo-wire Payload Encapsulation The following relevant text is extracted from section 3 (General Pseudo-wire Payload Encapsulation) of [BRYANT] for reference: "The most computationally-efficient encapsulation approach is the general pseudo-wire encapsulation approach proposed by [MARTINI] for HDLC, Ethernet and VLAN. The Frame Relay PDU is transported in its entirety, excluding only HDLC flags and the FCS. Bit stuffing is undone. The control word follows the general control word definition in [MARTINI]. The control word is OPTIONAL. If the control word is used then the flag bits in the control word are not used, and MUST be set to 0 when transmitting, and MUST be ignored upon receipt. "If a fragmentation scheme is required within the pseudo-wire protocol layer, then this should be incorporated into the general control word for use by all encapsulation types. A general encapsulation is shown here: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res |A|B| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bryant internet-draft - expires May 2002 7 draft-bryant-pwe3-fr-compare-00.txt October 2001 The meaning of the fields is as follows: Res (bits 0 to 5): Reserved bits. These are set to zero on transmission and ignored on reception. A, B (bits 6 and 7): 0 0: Complete packet (start and end) 0 1: First segment (start and not end) 1 1: Continuing segment (not start and not end) 1 0: Last segment (not start and end)" Use of the length and sequence number fields is similar to that of the Bryant optimised Frame-relay-specific header discussed in section 4 above, except that we adopt the 8-bit length and position preferred by [MARTINI]. 5.1 Comments on General Pseudo-wire Payload Encapsulation This approach treats Frame Relay as a general packet transport and transports and uses an encapsulation common to HDLC, VLAN and Ethernet. The [KAWA] fragmentation scheme is optionally included, with the changes to [KAWA] recommended in this document. Note that this proposal makes no comment about the mapping between L2TP sessions (MPLS labels) and Frame Relay DLCIs. This approach, with the associated computational efficiencies demonstrated below, is valid both when there is a one-to-one relationship between DLCI and L2TP session (MPLS labels), and when multiple DLCIs share a common L2TP session (MPLS label). 6. Mapping between the Control Word and the Frame Relay Header This section explores the computational complexity of the mapping between the proposed control words and the Frame Relay header. 6.1 Mapping between Martini control word and Frame Relay header This section looks at the issue of mapping between the Martin control work and the Frame Relay header in software. The control word defined in [MARTINI] is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rsvd |D|B|F|C| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The two-octet Frame Relay header in normal IETF (DoD) notation is: Bryant internet-draft - expires May 2002 8 draft-bryant-pwe3-fr-compare-00.txt October 2001 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hi dlci |C|0|lo dlci|F|B|D|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bits 7 and 15 are the Q.922 EA (Extended Address) bits used for address field extension. In the unextended two-octet header these are defined to be 0 and 1 respectively. Processors rarely have efficient bit manipulation operations, so you cannot normally just assign the bits to their new positions easily. It therefore becomes necessary to isolate each of the DBFC bits in the control word using an AND operation, to use a shift operator to move each bit to its correct position in the Frame Relay header, and then to load the isolated bit into the header buffer using an OR operator. This requires four operations on each of four bits: - Move first octet of control word to temporary location. - AND to isolate bit. - Shift bit to corresponding location in Frame Relay header octet. - Write or OR bit into Frame Relay header. A similar number of operations in needed in constructing the Control Word from the received Frame Relay header. For comparison we can regard this construction as having a cost of: (4 bits * 4 operations) + (4 bits * 4 operations) = 32 operations. Note that we have not included the processing of the DLCI bits (normally an OR operation) in this analysis, since that is an overhead common to all transmission formats. Also note that, for the purposes of Frame Relay header manipulation, the EA bits can normally be included in the pro-forma DLCI definition. 6.2 Mapping between Kawa control word and Frame Relay header This section looks at the issue of mapping between the [KAWA] control word and the Frame Relay header in software. The Kawa control word is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res |P|F|B|D|C|X|Y| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Again for comparison, the two-octet Frame Relay header in normal IETF (DoD) notation is: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hi dlci |C|0|lo dlci|F|B|D|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bryant internet-draft - expires May 2002 9 draft-bryant-pwe3-fr-compare-00.txt October 2001 In this case we can isolate the FBD bits as group, and knowing that they are in the same position and order in the octet in both Control Word and the Frame Relay header, we can write them directly to the header buffer in three operations: - Move first octet of control word to temporary location. - AND to isolate FBD bits. - Write bits into Frame Relay header. The C bit requires isolation with an AND operator, shifting and writing into the header buffer (4 operations). - Move second octet of control word to temporary location. - AND to isolate C bit. - Shift bit to corresponding location in Frame Relay header octet. - Write C bit into Frame Relay header. This same number of operations is needed in construction of the control word making a comparative cost of: (3 + 4) + (3 + 4) operations = 14 operations. 14 operations compares well with the 32 operations needed for the [MARTINI] implementation. Technical considerations suggest that the [KAWA] proposal is superior in allowing a simpler, higher-performance implementation. However, it has been proposed that [KAWA] be changed to follow the [MARTINI] control word. The analysis presented here suggests that this would be a backwards step. 6.3 Mapping between Bryant optimized Frame-Relay-specific control word and Frame Relay header The optimized Frame Relay control word described in [BRYANT] is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length |C|X|X|X|X|X|F|B|D|X| Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ this must be transformed to : 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hi dlci |C|0|lo dlci|F|B|D|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bryant internet-draft - expires May 2002 10 draft-bryant-pwe3-fr-compare-00.txt October 2001 If two-octet operations are available to the processor, it is simply necessary to isolate the CFB and D bits in the control word through an AND operation and write them into the Frame Relay header. - Move first word of control word to temporary location. - AND to isolate CFBD bits. - Write bits into Frame Relay header. The operation to create the Control Word has similar steps, making a comparative total cost of 6 operations, rising to a comparative cost of 12 operations if only single-octet, rather than word, operators are available. This is the fastest control word design for use with the [MARTINI] and [KAWA] approach of transmitting Frame Relay over pseudo-wire via an intermediate format. 6.4 Mapping between the General Pseudo-wire Payload Encapsulation and Frame Relay The general pseudo-wire encapsulation technique also discussed in [BRYANT] transports the Frame Relay header intact, and does not move any of the payload specific bits to the control word. This effectively has a Frame Relay header bit processing cost of zero. 7. Frame Relay header translation A common justification for the use of an intermediate format for the transmission of a Frame Relay header is the need to translate the header from one format to another across the pseudo-wire. There are two Frame Relay header formats in common usage: the two- octet version used in the examples in this draft, and the four-octet version. If the intermediate format is used, the encapsulator has to implement two cases (two-octet to intermediate and four-octet to intermediate), and the decapsulator has to implement two cases (intermediate to two-octet, and intermediate to four-octet). If the frame is transmitted across the pseudo-wire un-translated, then there are three translation cases (Nothing, 2->4 and 4->2). This results in a net reduction in translation and implementation complexity, and an increase in performance. It is useful to review the memory organization of the two-octet and four-octet Frame Relay headers, to fully appreciate the complexity of the translation operation. In normal IETF notation, the two- octet frame relay header is (yet again): Bryant internet-draft - expires May 2002 11 draft-bryant-pwe3-fr-compare-00.txt October 2001 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hi dlci |C|0|lo dlci|F|B|D|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and for comparison the four-octet frame relay header is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | hi dlci |C 0| dlci |F|B|D|0| dlci |0| dlci_lo |0|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Bit 30 is the D/C bit. This is set to zero to indicate that the last octet contains DLCI, rather than control, information. Note that the two least-significant (leftmost) octets in the header have an almost identical format, the only difference being that the EA bit in bit 15 is a zero to indicate a four-octet header. Translating from a two-byte Frame Relay header to a four-byte frame relay header requires the following operations: - Move first word of the header to temporary location. - AND to clear bit 15 (EA = 0). - Write word into Frame Relay header at new buffer offset. Correct setting of the remaining EA bits (bits 23 and 31) and the DLCI Core indicator (D/C) bit (bit 30) can be considered an integral part of writing the least significant thirteen bits of the DLCI. Translation from a two-octet Frame Relay header to a four-octet Frame relay header has similar complexity: - Move first word of the header to temporary location. - OR to set bit 15 (EA = 0). - Write word into Frame Relay header at new buffer offset. The minimal additional computational cost of translation is therefore one additional branch plus one read plus one write, i.e. branch plus 3 operations. This cost is much lower than the cost Of translating to and from an intermediate format. Bryant internet-draft - expires May 2002 12 draft-bryant-pwe3-fr-compare-00.txt October 2001 8. Conclusions Based on this analysis the authors make the following recommendations to the IETF PWE3 Working Group: Based on the reduced computational complexity, the simplicity of translation and the compatibility with the VLAN encapsulation type, the pseudo-wire Frame Relay service should transmit the frame as received rather than in an intermediate format, and perform any necessary translations as a local operation during the decapsulation processing. The general-purpose encapsulation presented in [BRYANT] is ideal for this, and should be used. If the use of an intermediate Frame Relay format is objectively judged desirable, the optimised frame-relay-specific intermediate control word proposed by [BRYANT] is computationally more efficient than that proposed by [KAWA] and [MARTINI], and should therefore be adopted. If the use of an intermediate Frame Relay format is objectively judged desirable, and there are also good reasons why the reserved bits are required and why the length field should remain unchanged, then the payload-dependent bit layout proposed in [KAWA] is computationally preferable to that proposed by [MARTINI], so [KAWA] is therefore preferred. The naming and polarity of the fragmentation bits proposed by [KAWA] should be changed to the definitions proposed in this draft to reduce computational complexity. (We understand from recent list discussion that this is in progress.) If a fragmentation mechanism is needed in PWE3, then it should be defined as a general method used by all encapsulation types. The general-purpose encapsulation presented in [BRYANT] is ideal for this, and should be used. 9. IANA considerations There are no IANA considerations for this document. 10. Security considerations There are no security implications for this document. Bryant internet-draft - expires May 2002 13 draft-bryant-pwe3-fr-compare-00.txt October 2001 11. References Internet-drafts are works in progress available from http://www.ietf.org/internet-drafts/ [BRYANT] S. Bryant and Wood, L. 'Two Efficient PWE3 Frame Relay Encapsulations', work in progress as an internet-draft: <draft-bryant-pwe3-fr-encap-00.txt> [GRE] D. Farinacci et al, 'Generic Routing Encapsulation (GRE)', IETF RFC2784, standards-track. [KAWA] C. Kawa, Malis, A., et al., 'Frame relay over Pseudo-Wire Emulation Edge-to-Edge', work in progress as an internet-draft: <draft-kamapabhava-fr-pwe3-00.txt> [MARTINI] L. Martini, Tappan, D., et al. 'Encapsulation Methods for Transport of Layer 2 Frames Over IP and MPLS Networks', work in progress as an internet-draft: <draft-martini-l2circuit-encap-mpls-03.txt> [Q.922] ITU-T Recommendation Q.922, ISDN Data Link Layer Specification for Frame Mode Bearer Services, ITU, Geneva, 1992. Authors' addresses Stewart Bryant Cisco Systems Ltd 4, The Square Stockley Park Uxbridge UB11 1BL Email: stbryant@cisco.com United Kingdom Phone: +44-20-8756-8828 Lloyd Wood Cisco Systems Ltd 4, The Square Stockley Park Uxbridge UB11 1BL Email: lwood@cisco.com United Kingdom Phone: +44-20-8734-4236 Bryant internet-draft - expires May 2002 14 draft-bryant-pwe3-fr-compare-00.txt October 2001 Full copyright statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Bryant internet-draft - expires May 2002 15