PWE3 Working Group Claude Kawa Internet Draft Nortel Networks Expires: October 2002 Andrew G. Malis Vivace Networks, Inc. Prayson Pate Overture Networks, Inc. Ravi Bhat Nishit Vasavada Amber Networks April 2002 Frame Relay Transport and Encapsulation over Pseudo-Wires draft-kamapabhava-fr-pwe3-01.txt 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. Copyright Notice Copyright(C) The Internet Society (2001). All Rights Reserved. Abstract This document defines frame relay pseudo-wire specific aspects. A frame relay pseudo wire exists between network edge nodes and support as faithfully as possible an instance of a frame relay service. A frame relay pseudo-wire is a mechanism that allows frame relay protocol control information and payload to be carried over IP or MPLS Packet Switched Networks. Kawa/Malis/Pate/Bhat/Vasavada [Page 1] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 3 4. Requirements for Frame Relay Over PWE3 . . . . . . . . . . . . 3 5. Reference model . . . . . . . . . . . . . . . . . . . . . . . 4 6. General Encapsulation and FRoPW packet processing . . . . . . 5 7. Configuration prerequisites . . . . . . . . . . . . . . . . . 10 8. Frame Relay over MPLS PSN . . . . . . . . . . . . . . . . . . 10 9. Frame Relay over IP PSN. . . . . . . . . . . . . . . . . . . 11 10.Use of L2TP with frame relay pseudo-wires over IP PSN . . . . 12 11 Frame relay port to port mode . . . .. . . . . . . . . . . . . 13 12.Security Considerations. . . . . . . . . . . . . . . . . . . 13 13 References . . . . . . . . . . . . . . . . . . . . . . . . . 13 14.Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 15.Author's Addresses . . . . . . . . . . . . . . . . . . . . . 14 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1. Introduction This document defines frame relay pseudo-wire (PW) specific aspects. A frame relay PW allows frame relay protocol control information and payload to be carried over IP or MPLS Packet Switched Networks (PSNs) using MPLS or L2TP for multiplexing as specified in the framework draft [PWE3FW]. A frame relay PW is a mechanism that emulates the essential attributes of frame relay service over a PSN. The required functions to support frame relay PW by a network edge node include: - Encapsulation of frame relay specific information in a suitable frame relay over pseudo wire packet, - Transfer of this information across a PSN for delivery to a peer edge, node, - Extraction of frame relay specific information by the remote edge node, - Generation of native frame relay frames for forwarding across an egress port of the remote PE device, - Execution any other operations required to support frame relay service. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Below are the definitions for the terms used throughout the document. Packet Switched Network: A Packet Switched Network (PSN) is a network using IP, MPLS or L2TP as the unit of switching. Kawa/Malis/Pate/Bhat/Vasavada [Page 2] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 Pseudo Wire Emulation Edge to Edge: Pseudo Wire Emulation Edge to Edge (PWE3) is a mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN. Customer Edge: A Customer Edge (CE) is a device where one end of an emulated service originates and terminates. The CE is not aware that it is using an emulated service rather than a "real" service. Provider Edge: A Provider Edge (PE) is a device that provides PWE3 to a CE. Pseudo Wire: A Pseudo Wire (PW) is a connection between two PEs carried over a PSN. The PE provides the adaptation between the CE and the PW. PW End Service: A Pseudo Wire End Service (PWES) is the interface between a PE and a CE. This can be a physical interface like a T1 or Ethernet, or a virtual interface like a VC or VLAN. Pseudo Wire PDU: A Pseudo Wire PDU is a PDU sent on the PW that contains all of the data and control information necessary to provide the desired service. PSN Tunnel: A PSN Tunnel is a tunnel inside which multiple PWs can be nested so that they are transparent to core network devices. 3. Acronyms and Abbreviations CE Customer Edge FCS Frame Check Sequence FR Frame Relay FRoPW Frame Relay over Pseudo Wire LSP Label Switched Path LSR Label Switching Router MPLS Multiprotocol Label Switching MTU Maximum Transfer Unit NNI Network-Network Interface PE Provider Edge PSN Packet Switched Network PW Pseudo-wire POS Packet over Sonet/SDH PVC Permanent Virtual Circuit SPVC Switched/Soft permanent virtual circuit SVC Switched Virtual Circuit UNI User-Network Interface VC Virtual Circuit 4. Requirements for Frame Relay Over Pseudo-Wire Emulation Edge to edge The section lists the main frame relay pseudo-wires requirements to be met between two edge nodes (known as provider edges (PEs): 1. Frame Transport: It must be possible to carry between two PEs both user and maintenance traffic on the same pseudo-wire. It must be possible also to distinguish between the two types of traffic. Kawa/Malis/Pate/Bhat/Vasavada [Page 3] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 2. Frame Length: Must transport variable length FR frames without being limited by the PSN MTU. 3. Bi-directional traffic: Must support bi-directional traffic. 4. Frame ordering: Must preserve FR frames order. 5. Control bits: Must support the transport of FR Discard Eligibility (DE), Forward Explicit Congestion Notification (FECN), Backward Explicit Congestion Notification (BECN) and Command/Response (C/R) bits [Q922]. 6. PVC Status Maintenance: Must support the mapping and transport of frame relay PVC status indications defined in Q933 Annex A [Q933]. The support of PVC continuity check should be provided. Note PVC status maintenance will be addressed in another IETF draft. 7. Traffic Management: Should be able to map the following FR traffic management parameters to PWs traffic parameters: a) CIR (Committed Information Rate) or throughput, b) Bc (Committed burst size), c) Be (Excess Burst Size), e) Maximum frame size. 8. Frame Priority and QoS: Should support the ability to map different FR priorities or QoS classes as defined in [X36,X76] to appropriately engineered PWs and tunnel PSNs. 9. Frame relay VC type: Must support PVC, support of SVC and SPVC is optional and will be addressed in the future. 5. Reference model Figure 1 shows PWE3 reference model with additional frame relay concepts. This section will be completed with additional details imported from [PWE3REQ and PWE3FW] and specific information related to frame relay. |<------- Pseudo Wire ------>| | | | |<-- PSN Tunnel -->| | PW V V V V PW End Service +----+ +----+ End Service (FR UNI or NNI)| | | | (FR UNI or NNI) +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ | | |==================| | | +-----+ ^ +----+ +----+ | ^ | Provider Edge 1 Provider Edge 2 | | | |<------------- Emulated Service ----------------->| (i.e. FR PVC, SVC or SPVC) Customer Customer Edge 1 Edge 2 Figure 1 - PWE3 Reference Model Kawa/Malis/Pate/Bhat/Vasavada [Page 4] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 6. General Encapsulation and FRoPW packet processing 6.1. General Encapsulation The general Frame Relay over Pseudo Wires (FRoPW) packet format to carry frame relay information (user's payload and frame relay control information) from one PE to another is shown in Figure 2. +-------------------------------+ | | | Delivery Header | | | +-------------------------------+ | | | FRoPW Header | | | +-------------------------------+ | | | Payload packet | | | +-------------------------------+ Figure 2 - General format of FRoPW packet The delivery header is a header specific to the PSN, it is discussed in the following sections addressing each type of PSN. FRoPW header contains protocol control information, its structure is shown in Figure 3. The packet payload field is the content of the information field of frame relay frame defined in ITU-T Recommendation Q.922 Annex A [Q922]. 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|B|F|D|C|I|L| 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 used by the PEs. B - BECN (bit 4): FR BECN (Backward Explicit Congestion Notification) bit [Q.922]. F - FECN (bit 5): FR FECN (Forward Explicit Congestion Notification) bit [Q922]. D - DE (bit 6) FR DE bit indicates the discard eligibility [Q922]. C/R - Command/Response (bit 7) FR frame C/R (command/response) bit [Q922]. Kawa/Malis/Pate/Bhat/Vasavada [Page 5] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 I, L - Initial and Last fragment indicators (bits 8 and 9): 0 1: First fragment of a fragmented FRoPW packet 1 0: Last fragment of a fragmented FRoPW packet 0 0: Complete FRoPW packet 1 1: Neither the first nor the last fragment of a fragmented FRoPW packet I and L bits are used for fragmentation and re-assembly of FRoPW packet 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 when Ethernet links are used in the PSN. The length field is used as follows: If the length of a frame relay frame (consisting of control information and 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 it is 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 value of zero indicates that the sequence number field is not used. The sequence number must be used when fragmentation 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. 6.2. FRoPW packet processing 6.2.1. Generating FRoPW packets The generation process of a FRoPW packet is initiated when a PE receives a frame relay frame from one of its frame relay UNI or NNI. The PE takes the following actions (not necessarily in the order shown): - It generates the following fields of FRoPW header from the corresponding fields of the frame relay frame as follows: - C/R bit is copied unchanged in the FRoPW header. - DE bit is copied as follows into the FRoPW header: If it was set to one in the incoming frame relay frame, it must be copied unchanged in the FRoPW header. Otherwise if it was set to zero, it may be set to zero or one, depending on the traffic policing performed by the PE device. - FECN is copied as follows into the FRFoPW header: If it was set to one in the incoming frame relay frame, it must be copied unchanged in the FRoPW header. Otherwise if it was set to zero, it may be set to zero or one, depending on the congestion state of the PE device in the forward direction. - BECN follows the same processing rules as FECN, except that it applies to the backward direction. Kawa/Malis/Pate/Bhat/Vasavada [Page 6] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 - The length field will be addressed in the next iteration of this draft. - The sequence field is set according to the configuration parameters. Details are provided below. - The payload field is the contents of the frame relay information field stripped from any bit or byte stuffing. Once the FRoPW packet has been generated, additional processing specific to the type of PW used and the underlying PSN is performed. 6.2.1.1. Setting the sequence number If the two PEs terminating a PSN tunnel support the sequence number capability then the following procedure to number FRoPW packets is used: - The initial packet transmitted on the frame relay PW MUST use sequence number 1, - For a subsequent packet, the sequence number corresponds to the sequence number of the preceding packet incremented by 1 modulo 2**16, - When the sequence number reaches the maximum 16 bit value (65535) the next sequence number wrap to 1. If the PEs do not support sequence number processing, then the sequence number field MUST be set to 0. 6.2.2. Receiving FRoPW packets When a PE receives a FRoPW packet, it processes the different FRoPW header fields in order to synthesize a new frame relay frame for transmission across one of its frame relay UNI or NNI. The PE performs the following act ions (not necessarily in the order shown): - The PE checks the P bit to ensure that it is set to "user's data", - It generates the following frame relay header fields from the corresponding fields of the FRoPW packet as follows: - C/R bit is copied unchanged in the frame relay header. - DE bit is copied as follows into the frame relay header: If it was set to one in the incoming FRoPW packet, it must be copied unchanged in the frame relay header. Otherwise if it was set to zero, it may be set to zero or one, depending on the traffic policing performed by the PE device. - FECN is copied as follows in the frame relay header: If it was set to one in the incoming FRoPW packet, it must be copied unchanged in the frame relay header. Otherwise if it was set to zero, it may be set to zero or one, depending on the congestion state of the PE device in the forward direction. - BECN follows the same processing rules as FECN, except that it applies to the backward direction. Kawa/Malis/Pate/Bhat/Vasavada [Page 7] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 - It processes the length and sequence field, the details are in the subsequent sub-sections. - It generates the frame relay information field from the contents of the FRoPW packet payload and retrieves the appropriate DLCI. Once the frame relay frame has been generated, it is queued for transmission across the selected frame relay UNI or NNI after the FCS and HDLC flags have been added and any bit or byte stuffing has been performed. 6.2.2.1 Checking the sequence number If the receiving PE support packet sequencing, the processing is done as follows: When a FRoPW packet is received the sequence number is processed as follows: - If the sequence number of the packet is 0, then the packet passes the sequence number check. - Otherwise if the packet sequence number >= the expected sequence number and the packet sequence number - the expected sequence number < 32768, then the packet is in order. - Otherwise if the packet sequence number < the expected sequence number and the expected sequence number - the packet sequence number >= 32768, then the packet is in order. - Otherwise the packet is out of order. If a FRoPW packet passes the sequence number check, it is further processed in order to be forwarded to its next destination. If the packet is in order, then the expected sequence number is set as per the following assignment: expected_sequence_number := packet_sequence_number + 1 mod 2**16 if (expected_sequence_number = 0) then expected_sequence_number := 1; FRoPW packets, which are received out of order are dropped. Packet re-ordering by the receiver is not supported in this version of the draft. If the receiving PE does not support sequence number processing, then the sequence number field is ignored. Note support of the sequence number capability is agreed upon by the two PEs either by configuration or by signalling prior to any packet exchange. 6.2.2.3 Processing of the length field by the receiver (To be completed) Kawa/Malis/Pate/Bhat/Vasavada [Page 8] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 6.3. Fragmentation and Re-assembly procedures 6.3.1. Fragmentation procedure Fragmentation is performed when a FRoPW packet is too long for transmission across the PSN and when the configuration of the PSN tunnel and/or PW allows fragmentation to be performed. I and L bits of a FRoPW fragment are used to indicate the type of fragment: First fragment (I = 0 and L = 1), last fragment (I = 1 and L = 0) neither the first not the last fragment(I = L = 1). The sequence number is used to number the fragments. If packet sequencing is used for every FRoPW packet, the numbering of FRoPW fragments follows the same procedure as the numbering of complete packets: For every fragment, the sequence number is the sequence number of the previous FRoPW packet/fragment incremented by one modulo 2**16. When packet sequencing is not used for every packet but only with fragmentation and re-assembly, the sequence number is re-initialized for every long frame relay frame that requires fragmentation. The first FRoPW packet fragment has a sequence number equal to 1 and for each subsequent fragment, the sequence number is incremented by 1 modulo 2**16. If fragmentation is not supported and a frame relay frame is too long for transmission in a single FRoPW packet, it shall be discarded. 6.3.2. Re-assembly procedure When a frame relay frame has been fragmented into multiple FRoPW fragments by the sending PE and fragmentation/re-assembly is supported by the receiving PE, the receiving PE will re-assemble the FRoPW fragments to synthesize the original frame relay frame. 6.4. Handling of error conditions To be completed. 6.5. FR SVC and SPVC Signalling between PEs Not supported in this document. 6.6. FR PVC provisioning Provisioning of frame relay VCs requires the following actions: Frame relay VC segments (see Figure 1) are provisioned between each CE and the corresponding PE. A FR PW is established between the two PEs to complete the Frame Relay VC. The two PEs terminating a frame relay PW executed a PVC maintenance protocol to exchange PVC status information and for "keep-alive" purposes. The PVC maintenance protocol will be defined in another document. Kawa/Malis/Pate/Bhat/Vasavada [Page 9] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 7. Configuration prerequisites Since frame relay VCs are bi-directional and carry traffic in the two opposite directions, at least one pair of tunnel PSN must be available between two PEs with appropriate traffic and QoS capabilities before they can start exchanging FRoPW packets. Some PSN tunnels require to be created and maintained, other do not. Establishing, maintaining and releasing PSN tunnel are outside the scope of this document. Binding between a pair of frame relay interfaces/DLCI and a PW is done when the PW and FR VC segments are created. In addition a PE must be configured with the following parameters per tunnel PSN. These parameters will apply to all Frame Relay PWs nested inside the tunnel PSN: 1. Maximum transfer unit (MTU) of the PSN, 2. Whether fragmentation and re-assembly will be supported or not, 3. Use of the sequence number: With fragmentation only, always or never, 4. Additional configuration parameters specific to each PW and PSN are listed in the section covering each PSN. 8. Frame Relay over MPLS PSN 8.1. MPLS tunnel and VC LSPs MPLS label switched paths (LSPs) called "Tunnel LSPs" establish an association between a pair of PEs. A tunnel LSP correspond to a "PSN tunnel" of Figure 1. Several "Virtual Circuit LSPs" (VC LSPs) may be nested inside one Tunnel LSP. Each VC LSP carries the traffic of a frame relay PVC or SVC in one direction. Since LSPs are uni-directional, a pair of VC LSPs (and corresponding tunnel LSPs) carrying traffic in opposite directions will be required usually for each frame relay PVC or SVC. 8.2. Relationship between FR VCs and MPLS VC LSPs Frame Relay VCs are considered to be bi-directional objects mainly because of the way they are created and identified. A single frame relay identifier (DLCI) refers to the two directions of a frame relay VC and frame relay signalling establishes the two directions simultaneously with the same message flows. In general each direction of a frame relay VC may have different traffic and QoS characteristics. The resource management of a frame relay implementation treats each direction separately and independently. MPLS LSPs, on the other hand are uni- directional and are established separately. In the case of frame relay over MPLS, during the creation of a frame relay VC, a pair of VC LSPs will have to be established between two PEs. For one end-to-end frame relay VC two VC LSPs exists: One VC LSP to transport the traffic from PE1 to PE2 and another one to transport the traffic in the opposite direction. The VC LSP in each direction must comply with the characteristics of the corresponding direction of the frame relay VC. The VC LSP from PE1 to PE2 is the transmit VC LSP for PE1 and the receive LSP for PE2. Likewise, the VC LSP from PE2 to PE1 is the transmit LSP for PE2 and the receive LSP for PE1. In the frame relay domain, a DLCI identifies a frame relay VC and in the MPLS domain, VC LSP labels with possible different values identify the pair of VC LSPs, one label value for each LSP. Kawa/Malis/Pate/Bhat/Vasavada [Page 10] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 In PE1 to PE2 direction a tunnel LSP transmits MPLS packets from PE1 to PE2,the corresponding label is not related to any frame relay VC. When PE1 sends a FRoPW packet to PE2, it first pushes a VC label on its label stack, and then pushes on a tunnel LSP label. The VC label is not visible until the FRoPW packet reaches PE2. PE2 forwards FRoPW packet based on the LSP VC label. The VC label must be always at the bottom of the label stack. While the packet is transported across the MPLS network, additional labels may be pushed on (and then popped off) as needed. The processing is similar in the opposite direction from PE2 to PE1. 8.3. FRoPW packet format over MPLS PSN In the case of frame relay over MPLS PSN, the generic FRoPW packet format of Figure 2 becomes as shown in Figure 4. +-------------------------------+ | Tunnel LSP label(s) | n words (4n bytes per label) +-------------------------------+ | VC LSP label | 1 word +-------------------------------+ | FRoPW Header | | (See Figure 3) | 1 word +-------------------------------+ | Payload packet | |(Q.922 frame information field)| Maximum N bytes | | (to be specified) +-------------------------------+ Figure 4 - Frame relay over MPLS packet format (Section to be completed) 9. Frame relay over IP PSN {Section and subsections to be completed) Note both IP v4 and IP v6 are supported. 9.1. General aspects of frame relay over IP PSN 9.2 Frame relay over IP PSN FRoPW packet format Two FRoPW packet format used over IP (v4 or v6) PSN are defined. One when MPLS is not used for switching and the other, when MPLS is used. When MPLS is not used, FRoPW packet format is shown in Figure 5. +-------------------------------+ | IP v4 or v6 header | m words +-------------------------------+ | FR PW identifier | | (See Figure 6) | 1 word +-------------------------------+ | FRoPW Header | | (See Figure 3) | 1 word +-------------------------------+ | Payload packet | |(Q.922 frame information field)| Maximum N bytes | | (to be specified) +-------------------------------+ Figure 5 -FRoPW packet format over IP PSN without MPLS Kawa/Malis/Pate/Bhat/Vasavada [Page 11] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 FR PW identifier field shown in Figure 5 identifies a frame relay VC between two PEs in the case of frame relay over IP PSN without MPLS switching. The format of this field is shown in Figure 6. This format of this identifier is similar to MPLS LSP label format. This format allows to have one size for identifying a frame relay VC between two PEs, instead of having two formats as allowed in FRF.1.2 and FRF.2.2 (see [Q922, FRF1 and FRF2]). The use of the other fields will be described in a subsequent version of this draft. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FR PW Identifier | Exp |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FR PW Identifier: Frame relay PW identifier, 20 bits Exp: Experimental Use, 3 bits TTL: Time to Live, 8 bits Figure 6 - Frame relay PW identifier for frame relay over IP PSN When MPLS is used with IP PSN, FRoPW packet format is shown in Figure 7. +-------------------------------+ | Tunnel LSP label(s) | n words (4n bytes per label) +-------------------------------+ | VC LSP label | 1 word +-------------------------------+ | IP v4 or v6 header | n words +-------------------------------+ | FRoPW Header | | (See Figure 3) | 1 word +-------------------------------+ | Payload packet | |(Q.922 frame information field)| Maximum N bytes | | (to be specified) +-------------------------------+ Figure 7 -FRoPW packet format over IP PSN with MPLS 9.3. Frame relay over IP PSN processing (To be completed). 9.4. Additional configuration objects for frame relay over IP PSN (To be completed as required). 10. Use of L2TP with frame relay pseudo-wires over IP PSN When the PSN is an IP PSN, L2TP may be used as the multiplexing protocol as per the framework document [PWE3FW]. (To be completed). Kawa/Malis/Pate/Bhat/Vasavada [Page 12] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 11. Frame relay port to port mode Frame relay port to port mode of operation applies to both IP and MPLS PSN. This mode provides transport of frame relay frames encapsulated in their entirety, including the address (with the control bits and DLCI) and information fields, but excluding the flags and the FCS. Bit or byte stuffing is undone. Frame relay control bits (F, B, D and C bits) carried in FRoPW header are not used and must be set to 0 when transmitting ignored upon receipt. It must be noted that this mode is transparent to the FECN, BECN and DE bits; these bits are carried unchanged by the sending PE. Frame relay port mode is an OPTIONAL capability. 12. Security Considerations (To be completed). 13. References [I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer service, Geneva, October 1991 [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2000 [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, 2001 [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement, Frame Relay Forum, January 2000 Kawa/Malis/Pate/Bhat/Vasavada [Page 13] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement, Frame Relay Forum, January 2000 [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3- requirements-01.txt, July 2001 [PWE3FW] Prayson Pate, et al., Internet draft, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) [Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer Specification for Frame Mode Bearer Services, ITU, Geneva, 1992. [Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification for Frame Mode Bearer Services, Geneva, October 1995. [RFC3032] E. Rosen, et al., RFC 3032 MPLS Label Stack encoding, January 2001. [RFC3031] E. Rosen, et al., RFC 3031 MPLS Architecture, January 2001. [RFC2615] A. G. Malis, RFC 2615 PPP over SONET/SDH, June 1999. Kawa/Malis/Pate/Bhat/Vasavada [Page 13] Internet Draft draft-kamapabhava-fr-pwe3-01.txt April 2002 [X36] ITU-T Recommendation X.36, Interface between a DTE and DCE for public data networks providing frame relay, Geneva, 2000 [X76] ITU-T Recommendation X.76, Network-to-network interface between public data networks providing frame relay services, Geneva, 2000 14. Acknowledgements To be completed. 15. Author's Addresses Claude Kawa Nortel Networks 3500 Carling Ave. Ottawa, Ontario, Canada email: kawa@nortelnetworks.com Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 e-mail: Andy.Malis@vivacenetworks.com Prayson Pate Overture Networks P. O. Box 14864 RTP, NC, USA 27709 email: prayson.pate@overturenetworks.com Ravi Bhat Amber Networks 50 Vanivalas Road Bangalore 560 004 India email: rbhat@nokia.com Nishit Vasavada Amber Networks
email: nishit@nokia.com Kawa/Malis/Pate/Bhat/Vasavada [Page 14]