Network Working Group Luca Martini (Editor) Internet Draft Cisco Systems, Inc. Expiration Date: October 2005 Claude Kawa (Editor) Andrew Malis (Editor) Oz Communications Tellabs April 2005 Encapsulation Methods for Transport of Frame Relay Over MPLS Networks draft-ietf-pwe3-frame-relay-05.txt Status of this Memo By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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/1id-abstracts.html The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract A frame relay pseudo-wire is a mechanism that exists between a provider's edge network nodes and support as faithfully as possible frame relay services over MPLS packet switched network (PSN). This document describes the detailed encapsulation necessary to transport frame-relay packets over an MPLS network. Martini, et al. [Page 1] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 Table of Contents 1 Specification of Requirements .......................... 2 2 Co-authors ............................................. 3 3 Acronyms and Abbreviations ............................. 3 4 Introduction ........................................... 4 5 General encapsulation method ........................... 5 6 Frame Relay over MPLS PSN for the One-to-One Mode ...... 6 6.1 MPLS PSN Tunnel and PW ................................. 6 6.2 Packet Format over MPLS PSN ............................ 7 6.3 The Control Word ....................................... 8 6.4 The Martini Legacy Mode Control Word ................... 9 6.5 PW packet processing ................................... 9 6.5.1 Generation of PW packets ............................... 9 6.5.2 Setting the sequence number ............................ 10 6.6 Reception of PW packets ................................ 11 6.6.1 Processing the sequence number ......................... 11 6.6.2 Processing of the Length Field by the Receiver ......... 12 6.7 MPLS Shim EXP Bit Values ............................... 13 6.8 MPLS Shim S Bit Value .................................. 13 6.9 Control Plane Details for Frame Relay Service .......... 13 6.9.1 Frame-Relay Specific Interface Parameters .............. 13 7 Frame Relay Port Mode .................................. 14 8 IANA Considerations .................................... 14 9 Security Considerations ................................ 14 10 Full Copyright Statement ............................... 14 11 Intellectual Property Statement ........................ 15 12 Normative References ................................... 15 13 Informative References ................................. 16 14 Author Information ..................................... 17 15 Contributing Author Information ........................ 18 1. 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 Below are the definitions for the terms used throughout the document. PWE3 definitions can be found in [PWE3REQ, RFC3985]. This section defines terms specific to frame relay. Martini, et al. [Page 2] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 - Backward direction. In frame relay it is the direction opposite to the direction taken by a frame being forwarded (see also forward direction). - Forward direction. The forward direction is the direction taken by the frame being forwarded. 2. Co-authors The following are co-authors of this document: Nasser El-Aawar Level 3 Communications, LLC Eric C. Rosen Cisco Systems Daniel Tappan Cisco Systems Thomas K. Johnson Litchfield Communications Kireeti Kompella Juniper Networks, Inc. Steve Vogelsang Laurel Networks, Inc. Vinai Sirkay Reliance Infocomm Ravi Bhat Nokia Nishit Vasavada Nokia Giles Heron Tellabs Dimitri Stratton Vlachos Mazu Networks,Inc. Chris Liljenstolpe Cable & Wireless Prayson Pate Overture Networks, Inc 3. Acronyms and Abbreviations Bc Committed burst size Be Excess burst size BECN Backward Explicit Congestion Notification CE Customer Edge CIR Committed Information Rate C/R Command/Response DE Discard Eligibility DLCI Data Link Connection identifier FCS Frame Check Sequence FECN Forward Explicit Congestion Notification FR Frame Relay L2TP Layer 2 Tunneling Protocol FRS Frame Relay Service LSP Label Switched Path LSR Label Switching Router Martini, et al. [Page 3] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 MPLS Multiprotocol Label Switching MTU Maximum Transfer Unit NNI Network-Network Interface PE Provider Edge PSN Packet Switched Network PW Pseudo-Wire PWE3 Pseudo-Wire Emulation Edge to Edge POS Packet over SONET/SDH PVC Permanent Virtual Circuit QoS Quality of Service SLA Service Level Agreement SPVC Switched/Soft permanent virtual circuit SVC Switched Virtual Circuit UNI User-Network Interface VC Virtual Circuit 4. Introduction In an MPLS or IP network, it is possible to use control protocols such as those specified in [CONTROL] to set up "Pseudo Wires" that carry the the Protocol Data Units of layer 2 protocols across the network. A number of these emulated Pseudo Wires (PW) may be carried in a single tunnel. The main functions required to support frame relay PW by a PE include: - Encapsulation of frame relay specific information in a suitable pseudo wire (PW) packet, - Transfer of a PW packet across an MPLS network for delivery to a peer PE. - Extraction of frame relay specific information from a PW packet by the remote peer PE, - Regeneration of native frame relay frames for forwarding across an egress port of the remote peer PE, - Execution of any other operations as required to support frame relay service. This document specifies the encapsulation for the emulated frame relay VC over an MPLS PSN. Although different layer 2 protocols require different information to be carried in this encapsulation, an attempt has been made to make the encapsulation as common as possible for all layer 2 protocols. Other layer 2 protocols are described in separate documents. [ATM] [ETH] [PPP] The following two figures describe the reference models which are derived from [RFC3985] to support the frame relay PW emulated services. Martini, et al. [Page 4] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | PW End V V V V PW End | V Service +----+ +----+ Service V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | (PE1) (PE2) | | Customer | | Customer Edge 1 | | Edge 2 | | | | Attachment Circuit (AC) Attachment Circuit (AC) native frame relay service native frame relay service Figure 1: PWE3 frame relay PVC Interface Reference Configuration Two mapping modes can be defined between frame relay VCs and pseudo wires: The first one is called "one-to-one" mapping, because there is a one-to-one correspondence between a frame-relay VC and one Pseudo Wire. The second mapping is called "many-to-one" mapping or "port mode" Because multiple frame-relay VCs assigned to a port are mapped to one pseudo wire. The "port mode" encapsulation is identical to HDLC pseudo wire encapsulation which is described in [PPP]. 5. General encapsulation method The general frame relay pseudo wire packet format for carrying frame relay information (user's payload and frame relay control information) between two PEs is shown in Figure 2. Martini, et al. [Page 5] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 +-------------------------------+ | | | MPLS Transport header | | (As required) | +-------------------------------+ | Pseudo Wire (PW) Header | +-------------------------------+ | Control Word | +-------------------------------+ | FR Service | | Payload | +-------------------------------+ Figure 2 - General format of frame relay encapsulation over PSN The PW packet consists of the following fields: Control word, and Payload preceded by the MPLS Transport and pseudo wire header. The meaning of the different fields is as follows: -i. MPLS Transport header is specific to the MPLS network. This header is used to switch the PW packet through the MPLS core. -ii. PW header contains an identifier for multiplexing PWs within an MPLS tunnel. -iii. Control Word contains protocol control information for providing a frame relay service. Its structure is provided in the following sections. -iv. The contents of the frame relay service payload field depends on the mapping mode. In general it contains the layer 2 frame relay frame. 6. Frame Relay over MPLS PSN for the One-to-One Mode 6.1. MPLS PSN Tunnel and PW MPLS label switched paths (LSPs) called "MPLS Tunnels" are used between PEs and within the MPLS core network for forwarding purposes of PW packets. A MPLS tunnel corresponds to "PSN Tunnel" of Figure 1. Several "Pseudo-Wires" may be nested inside one MPLS tunnel. Each PW carries the traffic of a single frame relay VC. Martini, et al. [Page 6] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 6.2. Packet Format over MPLS PSN For the one-to-one mapping mode for frame relay over an MPLS network, the PW packet format is shown in Figure 3. +-------------------------------+ | MPLS Tunnel label(s) | n*4 octets (four octets per label) +-------------------------------+ | PW label | 4 octets +-------------------------------+ | Control Word | | (See Figure 5) | 4 octets +-------------------------------+ | Payload | | (Frame relay frame | | information field) | n octets | | +-------------------------------+ Figure 3 - frame relay Over MPLS PSN Packet for the One-to-One Mapping The meaning of the different fields is as follows: - MPLS Tunnel label(s) The MPLS Tunnel label(s) corresponds to the PSN transport header of Figure 3. The label(s) is/are used by MPLS LSRs to forward a PW packet from one PE to the other. - PW Label The PW label identifies one PW (i.e. one LSP) assigned to a frame relay VC in one direction. It corresponds to the PW header of Figure 3. Together the MPLS Tunnel label(s) and PW label form an MPLS label stack [RFC3032]. - Control Word The Control Word contains protocol control information. Its structure is shown in Figure 4. - Payload The payload field corresponds to X.36/X.76 frame relay frame information field with bit/byte stuffing, frame relay header removed, and FCS removed . It is RECOMMENDED to support a frame Martini, et al. [Page 7] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 size of at least 1600 bytes. The maximum length of the payload field MUST be agreed upon by the two PEs. This can be achieved by using the MTU interface parameter when the PW is established. [CONTROL] 6.3. The Control Word When carrying frame relay over an MPLS network, sequentiality may need to be preserved. The REQUIRED control word defined here addresses this requirement. The Control Word contains protocol control information. Its structure is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|F|B|D|C|Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - Control Word structure for the one-to-one mapping mode The meaning of the Control Word fields (Figure 5) is as follows (see also [X36 and X76] for frame relay bits): - bits 0 to 3 In the above diagram the first 4 bits MUST be set to 0 to indicate PW data. - F (bit 4) FR FECN (Forward Explicit Congestion Notification) bit. - B (bit 5) FR BECN (Backward Explicit Congestion Notification) bit. - D (bit 6) FR DE bit (Discard Eligibility) bit. - C (bit 7) FR frame C/R (Command/Response) bit. - Res (bits 8 and 9): These bits are reserved and MUST be set to 0 upon transmission and ignored upon reception. - Length (bits 10 to 15) If the Pseudo Wire traverses a network link that requires a minimum frame size (a notable example is Ethernet), padding is Martini, et al. [Page 8] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 required to reach its minimum frame size. If the frame's length (defined as the length of the layer 2 payload plus the length of the control word) is less than 64 octets, the length field MUST be set to the PW payload length. Otherwise the length field MUST be set to zero. The value of the length field, if non-zero, is used to remove the padding characters by the egress PE. - Sequence number (Bit 16 to 31) Sequence numbers provide one possible mechanism to ensure the ordered delivery of PW packets. The processing of the sequence number field is OPTIONAL. The sequence number space is a 16 bit, unsigned circular space. The sequence number value 0 is used to indicate that the sequence number check algorithm is not used. 6.4. The Martini Legacy Mode Control Word For backward compatibility to existing implementations the following version of the control word is defined as the "martini mode CW" for frame relay. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 0|B|F|D|C|Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note that the "B" and "F" bits are reversed. This control word format is used for PW type "Frame Relay DLCI ( Martini Mode )" 6.5. PW packet processing 6.5.1. Generation of PW packets The generation process of a PW packet is initiated when a PE receives a frame relay frame from one of its frame relay UNI or NNI interfaces. The PE generates the following fields of the Control word from the corresponding fields of the frame relay frame as follows: - Command/Response (C/R or C) bit: The C bit is copied unchanged in the PW Control Word. Martini, et al. [Page 9] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 - The DE bit of the frame relay frame is copied into the D bit field. However if the D bit is not already set, it MAY be set as a result of ingress frame policing. If not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1). - The FECN bit of the frame relay frame is copied into the F bit field. However if the F bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1). - The BECN bit of the frame relay frame is copied into the B bit field. However if the B bit is not already set, it MAY be set to reflect a congestion situation detected by the PE. If not already set by the copy operation, setting of this bit by a PE is OPTIONAL. The PE MUST NOT clear this bit (set it to 0 if it was received with the value of 1). - If the PW packet length (defined as the length of the payload plus the length of the control word) is less than 64 octets, the length field MUST be set to the packet's length. Otherwise the length field MUST be set to zero. - The sequence number field is processed if the PW uses sequence numbers. - The payload of the PW packet is the contents of ITU-T Recommendations X.36/X.76 [X36, X76] frame relay frame information field stripped from any bit or byte stuffing. 6.5.2. Setting the sequence number For a given PW, and a pair of routers PE1 and PE2, if PE1 supports packet sequencing then the following procedures should be used: - the initial packet transmitted on the PW MUST use sequence number 1 - subsequent packets MUST increment the sequence number by one for each packet - when the transmit sequence number reaches the maximum 16 bit value (65535) the sequence number MUST wrap to 1 If the transmitting router PE1 does not support sequence number processing, then the sequence number field in the control word MUST be set to 0. Martini, et al. [Page 10] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 6.6. Reception of PW packets When a PE receives a PW packet, it processes the different fields of the control word in order to generate a new frame relay frame for transmission to a CE on a frame relay UNI or NNI. The PE performs the following actions (not necessarily in the order shown): - It generates the following frame relay frame header fields from the corresponding fields of the PW packet. - The C/R bit is copied in the frame relay header. - The D bit is copied into the frame relay header DE bit. - The F bit is copied into the frame relay header FECN bit. If the F bit is set to zero, the FECN bit may be set to one, depending on the congestion state of the PE device in the forward direction. Changing the state of this bit by a PE is OPTIONAL. - The B bit is copied into the frame relay header BECN bit. If the B bit is set to zero, the BECN bit may be set to one, depending on the congestion state of the PE device in the backward direction. Changing the state of this bit by a PE is OPTIONAL. - It processes the length and sequence field, the details of which are in the subsequent sub-sections. - It generates the frame relay information field from the contents of the PW packet payload after removing any padding. Once the above fields of a FR frame have been generated, the FCS has to be computed, HDLC flags have to be added and any bit or byte stuffing has been performed (these final actions typically take place in a hardware framer). The FR frame is queued for transmission on the selected frame relay UNI or NNI interface. 6.6.1. Processing the sequence number If a router PE2 supports receive sequence number processing, then the following procedures should be used: When a PW is initially set up, the "expected sequence number" associated with it MUST be initialized to 1. When a packet is received on that PW, the sequence number should be processed as follows: - if the sequence number on the packet is 0, then the sequence number check is skipped. ( sequence check disabled ) Martini, et al. [Page 11] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 - 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 packet passes the sequence number check, or is in order then, it can be delivered immediately. If the packet is in order, then the expected sequence number should be set using the algorithm: expected_sequence_number := packet_sequence_number + 1 mod 2**16 if (expected_sequence_number = 0) then expected_sequence_number := 1; Packets which are received out of order MAY be dropped or reordered at the discretion of the receiver. If a PE router negotiated not to use receive sequence number processing, and it received a non zero sequence number, then it SHOULD send a PW status message indicating a receive fault, and disable the PW. If an egress PE receives an excessive number of out-of-sequence PW packets, it SHOULD inform the management plane responsible for PW setup/maintenance, and take the appropriate actions. The threshold for declaring that out-of-sequence PW packets are excessive is not defined in this document. 6.6.2. Processing of the Length Field by the Receiver Any padding octet, if present, in the payload field of a PW packet received MUST be removed before forwarding the data. - If the Length field is set to zero then there are no padding octets following the payload field. - Else if the payload is longer then the length specified in the control word padding characters are removed based on the length field. Martini, et al. [Page 12] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 6.7. MPLS Shim EXP Bit Values If it is desired to carry Quality of Service information, the Quality of Service information SHOULD be represented in the EXP field of the PW MPLS label. If more than one MPLS label is imposed by the ingress LSR, the EXP field of any labels higher in the stack SHOULD also carry the same value. 6.8. MPLS Shim S Bit Value The ingress LSR, PE1, MUST set the S bit of the PW label to a value of 1 to denote that the PW label is at the bottom of the stack. 6.9. Control Plane Details for Frame Relay Service When emulating a frame relay service, the frame relay PDUs are encapsulated according to the procedures defined herein. The PE MUST provide frame relay PVC status signaling to the frame relay network. If the PE detects a service-affecting condition for a particular DLCI, as defined in [ITUQ] Q.933 Annex A.5 sited in IA FRF1.1, the PE MUST communicate to the remote PE the status of the PW that corresponds to the frame relay DLCI status. The Egress PE SHOULD generate the corresponding errors and alarms as defined in [ITUQ] on the egress Frame relay PVC. There are two frame relay flags to control word bit mappings described below. The legacy bit ordering scheme will be used for a PW of type 0x0001 "Frame Relay DLCI (Martini Mode)", while the new bit ordering scheme will be used for a PW of type 0x0019 "Frame Relay DLCI". The IANA allocation registry of "Pseudowire Type" is defined in [IANA] along with initial allocated values. 6.9.1. Frame-Relay Specific Interface Parameters A separate document [CONTROL], describes the PW control, and maintenance protocol in detail including generic interface parameters. The interface parameter information, when applicable, it MUST be used to validate that the PEs, and the ingress and egress ports at the edges of the circuit, have the necessary capabilities to interoperate with each other. The Interface parameter TLV is defined in [CONTROL], the IANA registry with initial values for interface parameter types is defined in [IANA], but the frame relay specific interface parameters are specified as follows: Martini, et al. [Page 13] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 - 0x08 Frame-Relay DLCI Length. An optional 16 bit value indicating the length of the frame relay DLCI field. This OPTIONAL interface parameter can have value of 2 , or 4, with the default being equal to 2. If this interface parameter is not present the default value of 2 is assumed. 7. Frame Relay Port Mode Frame relay port mode PW shares the same encapsulation as the HDLC PW, and is described in the respective document. [PPP] 8. IANA Considerations This document has no IANA Actions. 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 give in [RFC3985, CONTROL, PWE3REQ]. 10. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Martini, et al. [Page 14] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 11. Intellectual Property Statement The IETF 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 this 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. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR 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 this standard. Please address the information to the IETF at ietf- ipr@ietf.org. By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 12. Normative References [CONTROL] Luca Martini, et al., "Pseudowire Setup and Maintenance using LDP", draft-ietf-pwe3-control-protocol-16.txt, March 2005, work in progress. [ITUG] ITU Recommendation G.707, "Network Node Interface For The Synchronous Digital Hierarchy", 1996. [RFC3032] E. Rosen, et al., RFC 3032, MPLS Label Stack encoding, January 2001. [RFC3031] E. Rosen, et al., RFC 3031, MPLS Architecture, January 2001. [IANA] "IANA Allocations for pseudo Wire Edge to Edge Emulation Martini, et al. [Page 15] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 (PWE3)" Martini,Townsley, draft-ietf-pwe3-iana-allocation-09.txt (work in progress), April 2004 [PPP] "Encapsulation Methods for Transport of PPP/HDLC Over MPLS Networks", draft-ietf-pwe3-hdlc-ppp-encap-05.txt April 2005 13. Informative References [RFC3985] Stewart Bryant, et al.,Internet draft, PWE3 Architecture, RFC3985 [FRAG] Andrew G. Malis, et al., PWE3 Fragmentation and Reassembly, draft-ietf-pwe3-fragmentation-08.txt, February 2005, ( work in progress ). [ATM] "Encapsulation Methods for Transport of ATM Over MPLS Networks", draft-ietf-pwe3-atm-encap-05.txt April 2005 (work in progress) [ETH] "Encapsulation Methods for Transport of Ethernet Over MPLS Networks", draft-ietf-pwe3-ethernet-encap-06.txt. February 2005 (work in progress) [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, April 2002 [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement, Frame Relay Forum, January 2000. [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement, Frame Relay Forum, January 2000. [FRF13] FRF.13, Service Level Definition Implementation Agreement, Frame Relay Forum, August 1998. [FRF14] FRF.14, Physical layer Implementation Agreement, Frame Relay Forum, December 1998. [FRAG] Andrew G. Malis, et al., PWE3 Fragmentation and Reassembly, draft-ietf-pwe3-fragmentation-04.txt, October 2003, (work in progress) Martini, et al. [Page 16] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 [PWE3REQ] XiPeng Xiao, et al., RFC 3916. [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. [ITUQ] ITU-T Recommendation Q.933, and Q.922 Specification for Frame Mode Basic call control, ITU Geneva 1995 14. Author Information Luca Martini Cisco Systems, Inc. 9155 East Nichols Avenue, Suite 400 Englewood, CO, 80112 e-mail: lmartini@cisco.com Claude Kawa OZ Communications Windsor Station 1100, de la Gauchetie`re St West Montreal QC Canada H3B 2S2 e-mail: claude.kawa@oz.com Andrew G. Malis Tellabs 90 Rio Robles Dr. San Jose, CA 95134 e-mail: Andy.Malis@tellabs.com Martini, et al. [Page 17] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 15. Contributing Author Information Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 e-mail: kireeti@juniper.net Giles Heron Tellabs Abbey Place 24-28 Easton Street High Wycombe Bucks HP11 1NT UK e-mail: giles.heron@tellabs.com Rao Cherukuri Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 e-mail: d@mazunetworks.com Chris Liljenstolpe Cable & Wireless 11700 Plaza America Drive Reston, VA 20190 e-mail: chris@cw.net Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 e-mail: nna@level3.net Martini, et al. [Page 18] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 Eric C. Rosen Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 e-mail: erosen@cisco.com Dan Tappan Cisco Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 e-mail: tappan@cisco.com Prayson Pate Overture Networks, Inc. 507 Airport Boulevard Morrisville, NC, USA 27560 e-mail: prayson.pate@overturenetworks.com David Sinicrope Ericsson IPI e-mail: david.sinicrope@ericsson.com Ravi Bhat Nokia e-mail: ravi.bhat@nokia.com Nishit Vasavada Nokia e-mail: nishit.vasavada@nokia.com Steve Vogelsang Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 e-mail: sjv@laurelnetworks.com Martini, et al. [Page 19] Internet Draft draft-ietf-pwe3-frame-relay-05.txt April 2005 Vinai Sirkay Redback Networks 300 Holger Way, San Jose, CA 95134 e-mail: sirkay@technologist.com Martini, et al. [Page 20]