Network Working Group Eswaran Srinivasan, Ed. Internet Draft Juniper Networks Expiration Date: May 31, 2013 Luis Tomotaki, Ed. Verizon November 30, 2012 Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks with Multilink Frame Relay UNI/NNI (FRF.16) Endpoints draft-srinivasan-fr-over-mpls-with-frf-16-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on May 31, 2013. Abstract A Frame Relay pseudowire (PW) with Multilink Frame Relay UNI/NNI (FRF.16) is a mechanism that can be used for transporting the Frame Relay Protocol Data Units (PDUs) got after reassembling the FRF.16 fragments over a MPLS packet switched network (PSN). The goal of this document is to describe the encapsulation that is required for this. 1. Introduction A Frame Relay pseudowire (PW) with Multilink Frame Relay UNI/NNI (FRF.16) allows the Frame Relay Protocol Data Units (PDUs) got after reassembling the FRF.16 fragments to be carried over a MPLS network to a remote Provider Edge (PE) device. The remote PE can interface with a Customer Edge (CE) device running a FRF.16 service or a non-multilink Frame Relay service. Hence, this approach allows interconnecting two heterogeneous type CE devices. In a nutshell, providing this support on a PE will include the following operations: i) Reassembling the FRF.16 fragments received on the member links into Frame Relay PDUs on the local PE end. ii) Encapsulating the Frame Relay specific control information from the multilink fragments into the PW packet. iii) Transmitting the PW packets across the MPLS network to the peer PE. iv) Extracting the Frame Relay specific control information from the PW packet on the remote PE end. v) Fragmenting the Frame Relay PDUs into FRF.16 fragments on the remote PE end. vi) Forwarding the Frame Relay packets to the CE device associated with the PW on the remote PE end. The figure below (Figure 1) describes the reference model to support Frame Relay PW with FRF.16 services. |<--- Pseudowire (PW) -->| | | FRF.16 | |<-- PSN Tunnel -->| | FRF.16 or Frame Relay Service V V V V Service | +----+ +----+ | +----+ | | PE1|==================| PE2| | +----+ | |----------|............PW1.............|----------| | | CE1| | | | | | | |CE2 | | |----------|............PW2.............|----------| | +----+ | | |==================| | | +----+ ^ | +----+ +----+ | ^ | Provider Edge 1 Provider Edge 2 | | | |<-------------- Emulated Service ---------------->| Customer Customer Edge 1 (CE1) Edge 2 (CE2) Figure 1: Frame Relay PW with FRF.16 Service Reference Model 2. Specification of Requirements 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. 3. Applicability Statement Frame Relay PW with FRF.16 service is not intended to emulate the traditional Frame Relay service perfectly. However, it can be used for the applications that need Frame Relay transport service. The following are the notable differences between the traditional Frame Relay service and the protocol described in this document. - The PE device connected to one of the two CE endpoints MUST support FRF.16 services. The other PE device MUST support FRF.16 or non-multilink Frame Relay services. All the implementations MUST support this. - The frame ordering can be preserved using the OPTIONAL sequence number field in the control word. However, the implementations are not required to support this feature. - The Quality Of Service (QOS) model for traditional Frame Relay can be emulated. But, this is outside the scope of this document. - The Frame Relay FECN, BECN, DE and C/R bits transparent to the MPLS network and they won't reflect the status of the MPLS network. - Support for the Frame Relay Switched Virtual Circuit (SVC) and Switched Permanent Virtual Circuit (SPVC) is outside the scope of this document. - The Frame Relay Local Management Interface (LMI) protocol will be terminated locally on the PE devices connected to the Frame Relay attachment circuits. - The Frame Relay Link Integrity Protocol (LIP) protocol will be terminated on each of the FRF.16 member links. 4. MPLS Pseudowire Type There are two modes defined by [RFC4446] to map the Frame Relay specific bits in the pseudowire control word. The legacy mapping mode is identified by the pseudowire type 0x0001 and is referred as Frame Relay DLCI (Martini Mode). The new mapping mode is identified by the pseudowire type 0x0019 and is referred as Frame Relay DLCI. An implementation MUST support both these mapping modes while signaling the pseudowire type to the remote PE. 5. General Encapsulation Method In general, the encapsulation method followed for carrying the Frame Relay PDUs over the MPLS network will be exactly same as the one described in [RFC4619]. Each Frame Relay VC will be mapped to a separate pseudowire and the implementations MUST support the "one-to-one" mapping mode described in [RFC4619]. However, the implementations MUST NOT support "port mode" mapping mode described in [RFC4619]. 6. Encapsulation of Frame Relay Frames 6.1. Encapsulation of Frame Relay Frames for Frame Relay Service The encapsulation method used by a PE device running the Frame Relay service is identical to the one described in [RFC4619]. 6.2. Encapsulation of Frame Relay Frames for FRF.16 Service The encapsulation method used by a PE device running the FRF.16 service is similar to the one described in [RFC4619]. The following are the prominent differences for this protocol. - The PE device running the FRF.16 service will be reassembling the FRF.16 fragments into complete Frame Relay PDUs. - The PE device will generate the Frame Relay protocol specific fields in the control word as below. i) The PE MUST perform the bitwise logical OR of the Command/Response (C/R) bits in the fragments associated with a Frame Relay PDU and copy the result as the C bit in the control word. ii) The PE MUST perform the bitwise logical OR of the Discard Eligible (DE) bits in the fragments associated with a Frame Relay PDU and copy the result as the D bit in the control word. If the D bit is not already set, the PE MAY set this bit based on the ingress frame policing. iii) The PE MUST perform the bitwise logical OR of the Forward Explicit Congestion Notification (FECN) bits in the fragments associated with a Frame Relay PDU and copy the result as the F bit in the control word. If the F bit is not already set, the PE MAY set this bit to reflect the congestion detected by the PE. iv) The PE MUST perform the bitwise logical OR of the Backward Explicit Congestion Notification (BECN) bits in the fragments associated with a Frame Relay PDU and copy the result as the B bit in the control word. If the B bit is not already set, the PE MAY set this bit to reflect the congestion detected by the PE. 7. Decapsulation of Frame Relay Frames 7.1. Decapsulation of Frame Relay Frames for Frame Relay Service The decapsulation method used by a PE device running the Frame Relay service is identical to the one described in [RFC4619]. 7.2. Decapsulation of Frame Relay Frames for FRF.16 Service The decapsulation method used by a PE device running the FRF.16 service is similar to the one described in [RFC4619]. The following are the prominent differences for this protocol. - The PE device will process the Frame Relay protocol specific fields in the control word as below. i) The PE MUST copy the C bit in the control word as the C/R bit in the Frame Relay header of all the FRF.16 fragments associated with this PDU. ii) The PE MUST copy the D bit in the control word as the DE bit in the Frame Relay header of all the FRF.16 fragments associated with this PDU. iii) The PE MUST copy the F bit in the control word as the FECN bit in the Frame Relay header of all the FRF.16 fragments associated with this PDU. If the F bit is set to 0, the FECN bit may be set to 1, depending on the congestion state of the PE device in the forward direction. Changing the state of this bit by a PE is OPTIONAL. iv) The PE MUST copy the B bit in the control word as the BECN bit in the Frame Relay header of all the FRF.16 fragments associated with this PDU. If the B bit is set to 0, the BECN bit may be set to 1, depending on the congestion state of the PE device in the backward direction. Changing the state of this bit by a PE is OPTIONAL. - The PE device running the FRF.16 service will be fragmenting the Frame Relay PDUs into FRF.16 fragments. 8. Fault Management A PE device MUST provide the following fault management handling operations. - If a PE detects a service affecting failure on the CE end for a Frame Relay DLCI, it MUST communicate to the remote PE with the Frame Relay PVC status. - When a PE receives a Frame Relay PVC failure status message from the remote PE, it SHOULD communicate to the CE with the Frame Relay PVC status. A PE SHOULD send a Frame Relay LMI PVC status message to the CE to indicate the Frame Relay DLCI failure. A PE SHOULD select the best matching FRF.16 member link to send the Frame Relay PVC status message. 9. Security Considerations PWE3 provides no means of protecting the contents or delivery of the PW packets on behalf of the native service. PWE3 may, however, leverage security mechanisms provided by the MPLS Tunnel Layer. A more detailed discussion of PW security is given in [RFC3985, RFC4447, RFC3916]. 10. Normative References [RFC4619] Martini, L., Kawa, C., and Malis, A., "Encapsulation Methods for Transport of Frame Relay over Multiprotocol Label Switching (MPLS) Networks", RFC 4619, September 2006. [RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006. [FRF16.1] FRF.16.1, Multilink Frame Relay UNI/NNI Implementation Agreement, Frame Relay Forum, May 2002. 11. Informative References [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. [RFC4448] Martini, L., Rosen, E., El-Aawar, N., and G. Heron, "Encapsulation Methods for Transport of Ethernet over MPLS Networks", RFC 4448, April 2006. [RFC4717] Martini, L., Jayakumar, J., Bocci, M., El-Aawar, N., Brayley, J., and Koleyni, G., "Encapsulation Methods for Transport of Asynchronous Transfer Mode (ATM) over MPLS Networks", RFC 4717, December 2006. 12. Contributors Authors's Addresses Eswaran Srinivasan Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089, USA EMail: esriniva@juniper.net Luis Tomotaki Verizon 400 International Parkway Richardson, TX 75081, USA EMail: luis.tomotaki@verizon.com Contributing Author Information Richard Li Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 EMail: rli@juniper.net Intellectual Property The IETF Trust takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in any IETF Document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Copies of Intellectual Property disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement any standard or specification contained in an IETF Document. Please address the information to the IETF at ietf-ipr@ietf.org. The definitive version of an IETF Document is that published by, or under the auspices of, the IETF. Versions of IETF Documents that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of IETF Documents. The definitive version of these Legal Provisions is that published by, or under the auspices of, the IETF. Versions of these Legal Provisions that are published by third parties, including those that are translated into other languages, should not be considered to be definitive versions of these Legal Provisions. For the avoidance of doubt, each Contributor to the IETF Standards Process licenses each Contribution that he or she makes as part of the IETF Standards Process to the IETF Trust pursuant to the provisions of RFC 5378. No language to the contrary, or terms, conditions or rights that differ from or are inconsistent with the rights and licenses granted under RFC 5378, shall have any effect and shall be null and void, whether published or posted by such Contributor, or included with or in such Contribution. Disclaimer of Validity All IETF Documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.