Stewart Bryant Internet Draft Lloyd Wood Document: draft-bryant-pwe3-fr-encap-00.txt Cisco Systems Ltd Expires: May 2002 October 2001 Two Efficient PWE3 Frame Relay Encapsulations 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 draft presents two alternative Frame Relay encapsulations that are computationally more efficient than those already proposed to the IETF Pseudo-Wire Edge-to-Edge (PWE3) working group. The first is an optimized Frame Relay specific encapsulation. The second (which is the more efficient) is a general packet encapsulation. Bryant internet-draft - expires May 2002 1 draft-bryant-pwe3-fr-encap-00.txt October 2001 Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1. Overview........................................................2 2. An optimised Frame-Relay-specific control word..................3 3. General Pseudo-wire Payload Encapsulation.......................4 4. Frame Relay header translation..................................5 5. Conclusions.....................................................6 6. IANA considerations.............................................6 7. Security considerations.........................................6 8. References......................................................7 Authors' addresses.................................................7 Full copyright statement...........................................8 1. Overview The design of the pseudo-wire encapsulation header can have considerable impact on the performance of the system using it. Drafts describing two Frame Relay encapsulation approaches have been proposed. This document proposes two alternative encapsulations that are computationally more efficient. Bryant internet-draft - expires May 2002 2 draft-bryant-pwe3-fr-encap-00.txt October 2001 2. An optimised Frame-Relay-specific control word 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Relay PDU | | " | | " | | " | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. C/R (bit 6) FR frame C/R (command/response) bit [Q.922]. X (bits 7 to 11 and bit 15): Reserved bits. They are set to zero on transmission and ignored on reception. F - FECN (bit 12): FECN (Forward Explicit Congestion Notification) bit [Q.922]. B - BECN (bit 13): BECN (Backward Explicit Congestion Notification) bit [Q.922]. D - DE (bit 14) DE indicates the Discard Eligibility [Q922]. 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 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. In normal IETF notation, the two-octet frame relay header is: Bryant internet-draft - expires May 2002 3 draft-bryant-pwe3-fr-encap-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 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. In generating a Frame Relay header from the control word, 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 DLCI bits and the 1 in bit 31 are then included through an OR operation in a manner common to all proposed encapsulations. This approach minimizes the bit manipulation necessary and is computationally the most efficient Frame Relay specific encapsulation. 3. General Pseudo-wire Payload Encapsulation 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: Bryant internet-draft - expires May 2002 4 draft-bryant-pwe3-fr-encap-00.txt October 2001 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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) Length (bits 8 to 15): 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 2 frame (consisting of layer two control information and layer 2 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. 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 pseudo-wire packets when the PSN does not guarantee in-order delivery. 4. 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. In Section 2 above, we presented the commonly used two and four- octet Frame Relay headers. As can be seen by inspecting these definitions, the translation of a two-octet Frame Relay header to a four-octet Frame Relay header is a relatively simple operation requiring. Bryant internet-draft - expires May 2002 5 draft-bryant-pwe3-fr-encap-00.txt October 2001 - 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. 5. Conclusions Given the simplicity of the Frame Relay header translation process, it is not clear why an intermediate frame format is needed by the pseudo-wire service. It is therefore recommended that the general payload encapsulation method specified in [MARTINI] for HDLC, Ethernet and VLAN also be used for Frame Relay payloads. If a Frame Relay specific encapsulation using an intermediate format is objectively justified, then it is recommended that the computationally efficient control word specified in section 2 of this document be used. 6. IANA considerations There are no IANA considerations for this document. 7. Security considerations There are no security implications for this document. Bryant internet-draft - expires May 2002 6 draft-bryant-pwe3-fr-encap-00.txt October 2001 8. References Internet-drafts are works in progress available from http://www.ietf.org/internet-drafts/ [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: [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 7 draft-bryant-pwe3-fr-encap-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 8