PWE3 Working Group Claude Kawa (Editor) Internet Draft Expires: April 2003 Luca Martini Nasser El-Aawar Level 3 Communications, LLC. Andrew G. Malis Vivace Networks, Inc. Prayson Pate Overture Networks, Inc. Eric C. Rosen Daniel Tappan Prayson Pate Overture Networks, Inc. Cisco Systems, Inc. Chris Liljenstolpe Cable & Wireless Steve Vogelsang Laurel Networks, Inc Kireeti Kompella Dimitri Stratton Vlachos Juniper Networks Mazu Networks,Inc. Giles Heron PacketExchange Ltd. Vinai Sirkay Steve Vogelsang Vivace Networks, Inc. Laurel Networks, Inc. Ravi Bhat Nishit Vasavada Nokia October 2002 Frame Relay over Pseudo-Wires draft-ietf-pwe3-frame-relay-00.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." Kawa, et al. [Page 1] Internet Draft draft-ietf-pwe3-frame-relay-00.txt October 2002 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 (2002). All Rights Reserved. Abstract This document defines frame relay pseudo-wire emulation edge-to-edge. 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 IP and MPLS packet switched network (PSN). Two mapping modes are defined: One-to-one mapping mode characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs is defined for MPLS PSN. The other mode is known as port mode or many-to-one mapping mode and is defined for MPLS PSN and IP PSN with L2TPv3. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 4 4. Requirements for Frame Relay Over Pseudo-wires. . . . . . . . 4 5. Reference model and PWE3 protocol layering . . . . . . . . . . 5 6. General encapsulation for the two mapping modes . . . . . . 8 7. Frame Relay over MPLS PSN for the one-to-one mapping mode. . . 9 8. FR SVC and SPVC Signalling between PEs. . . . . . . . . . . . 17 9. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 17 10. Frame relay port mode . . . . . . . .. . . . . . . . . . . . 17 11. Frame relay service over pseudo-wires. . . . . . . . . . . . .22 12. IANA considerations. . . . . . . . . . . . . . . . . . . . . .24 13. Security Considerations. . . . . . . . . . . . . . . . . . . 24 14. Supplement on frame relay frame formats. . . . . . . . . . . .25 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 26 16. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 27 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 draft combines draft-martini-frame-encap-mpls-00.txt and draft- kamapabhava-fr-pwe3-01.txt previously submitted to the PWE3 working group and replaces both of these drafts. Kawa, et al. [Page 2] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 This document defines frame relay pseudo-wire emulation edge-to-edge. A frame relay pseudo-wire (PW) is a mechanism that exists between provider's edge network nodes (PEs) and supports as faithfully as possible frame relay services over IP and MPLS packet switched network (PSN) using MPLS LSP [RFC3031, RFC3032] and L2TPv3 [L2TPv3] tunnels for multiplexing purposes. L2TPv3 is used only with IP PSN in this document. The main functions required to support frame relay PW by a PE include: - Encapsulation of frame relay specific information in a suitable frame relay over pseudo wire (FRoPW) packet, - Transfer of a FRoPW packet across a PSN for delivery to a peer PE, - Extraction of frame relay specific information from a FRoPW packet by the remote edge node, - Generation of native frame relay frames for forwarding across an egress port of the remote edge node, - Execution of any other operations required to support frame relay service. Two mapping modes are defined between FR VCs and FR PWs: The first one is called "one-to-one" mapping. because there is a one-to-one correspondence between a FR VC and a pair of unidirectional PWs. The second mapping is called "many-to-one" mapping or "port mode" because multiple FR VCs assigned to a port are mapped to one pair of PWs. One-to-one mapping mode is defined for MPLS PSN only and port mode is defined for MPLS LSP and IP PSN with L2TPv3. The main structure of this document is as follows: Section 4 lists some important frame relay requirements to be met in a PWE3 environment. Section 5 described PWE3 reference model and PWE3 protocol layers described in [LYR]. Section 6 describes the generic frame relay over pseudo-wire (FRoPW) packet format. Section 7 specifies frame relay over MPLS PSN for the one-to-one mapping Section 8 just indicates that FR SVC and SPVC are not supported in this document. Section 9 is about FR PVC provisioning. Section 10 describes FR port mode for MPLS PSN and IP PSN with L2TPv3. Finally, Section 11 discusses the meaning of providing frame relay services in the native and PWE3 environments and how faithfully/perfectly FR service should be provided. A supplement on frame relay frame formats appears in Section 14. 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. Kawa, et al. [Page 3] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 PWE3 definitions can be found in [PWE3REQ, PWE3FW]. This section defines terms specific to frame relay. 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: In frame relay the reference used to determine whether the direction of the traffic is the forward or backward direction is the frame being forwarded. The forward direction is the direction taken by the frame being forwarded. 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 FRoPW Frame Relay over Pseudo Wire L2TP Layer 2 Tunneling Protocol FRS Frame Relay Service 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 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. Requirements for Frame Relay Over Pseudo-Wires The section lists the main frame relay pseudo-wire requirements to be met by a PE: Kawa, et al. [Page 4] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 1. Frame Length: Should transport variable length FR frames without being limited by the PSN MTU. 2. Bidirectional traffic: Must support bidirectional traffic. 3. Frame ordering: Must preserve FR frames order. 4. Transmission errors: Must detect (detectable) transmission errors, 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 Q.933 Annex A [Q933]. The support of PVC link integrity 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 and tunnel 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 FR transfer and discard priorities or QoS service classes defined in [X36, X76] to appropriately engineered PWs and PSN tunnels. 9. Frame relay VC type: Must support PVC, support of SVC and SPVC is optional. 5. Reference model and PWE3 protocol layering 5.1. Reference model Figure 1 shows PWE3 reference model with additional frame relay concepts. More details on the reference model can be found in [PWE3REQ, PWE3FW]. Kawa, et al. [Page 5] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 |<------ Pseudo-wires ------>| | | | |<-- PSN Tunnel -->| | V V V V FR +----+ +----+ FR UNI or NNI | | PW1 | | UNI or NNI +-----+ | | |==================| | | +-----+ | |----------| PE1| | PE2|----------| | | CE1 | | | | | | | | CE2 | | |----------| | PW2 | |----------| | +-----+ | | |==================| | | +-----+ ^ +----+ +----+ ^ | | |<------------- Emulated Service ----------------->| (i.e. FR PVC, SVC or SPVC) Figure 1 - PWE3 Reference Model Two mapping modes are defined between FR VCs and pseudo-wires: - The first one is called "one-to-one" mapping. With one-to-one mapping, for each frame relay VC, a pair of pseudo-wires (one for each direction of the traffic) is established between a pair of PEs. - The second mapping is called "many-to-one" mapping or "port mode": With this mapping multiple frame relay VCs related to a port are assigned to one pair of pseudo-wires. As specified later in this document, the encapsulation of frame relay information is slightly different between the two mapping modes. 5.2. Frame relay over PW and PWE3 protocol layering This document supports MPLS PSN and IP PSN. With IP PSN, L2TPV3 [L2TPv3] is used for multiplexing purposes of a number of FR VCs into one L2TPv3 tunnel. In addition, the one- to-one mapping mode applies to frame relay over MPLS PSN only and the many-to-one mapping mode applies to both frame relay over MPLS PSN and IP PSN with L2TPv3. In terms of PWE3 protocol layering defined in [LYR], we have the following two protocol stacks: The first protocol stack is for the one-to-one mapping mode. It is adapted from [LYR Figure 11]: Kawa, et al. [Page 6] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 +---------------------+ | Payload | /=====================\ H Payload Convergence H-----------------+ H---------------------H | H Timing (NIL) H | H---------------------H | H Sequencing H------------------------------------+ \=====================/ | | | PW Demultiplexer |---+ | | +---------------------+ | | | | PSN Convergence |-----------------------+----+----+ | +---------------------+ | | | | | | | MPLS PSN |-+ | v v v v v +---------------------+ | | +--------------------------------+ | MAC/Data-link | | | | Flags |Frag| Len |Seq # | +---------------------+ | | +--------------------------------+ | Physical | | +->| Inner MPLS LSP/PW Label | +---------------------+ | +--------------------------------+ +--->| Outer MPLS LSP Label | +--------------------------------+ Control words Figure 2- FR PWE3 over MPLS PSN for the one-to-one mapping mode Notes: 1-For the one-to-one mapping mode only MPLS PSN is used in this document and MPLS LSP labels are used for PW demultiplexer. 2-The payload is a FR frame information field only with bit/byte stuffing undone (byte stuffing is used only over Sonet/SDH transmission facilities [FRF14]).Section 14 contains aa supplement on frame relay frame formats and the description of the various fields. 3-Control words carrying different protocol control information are used. They are described in subsequent sections. The second protocol stack is for the many-to-one mapping or port mode. It is adapted from [LYR Figure 10]: Kawa, et al. [Page 7] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 +---------------------+ +-------------------------+ | Payload |------------>|FR frame less flags & FCS| /=====================\ +-------------------------+ H Payload Convergence H------------>| Nil | H---------------------H +-------------------------+ H Timing H------------>| Nil | H---------------------H +------------+------------+ H Sequencing H------------>| Pseudo-wire protocol | \=====================/ +------------+------------+ | PW Demultiplexer |------------>| L2TPv3 | MPLS | +---------------------+ +------------+------------+ | PSN Convergence |------------>| Nil | Nil | +---------------------+ +------------+------------+ | PSN |------------>| IP | MPLS | +---------------------+ +------------+------------+ | MAC/Data-link |------------>| MAC/Data-link | +---------------------+ +-------------------------+ | Physical |------------>| Physical | +---------------------+ +-------------------------+ Figure 3 - FR PWE3 protocol layers for port mode with IP and MPLS PSNS Notes: 1-There are actually two instances of the protocol stack: One for IP PSN and the other for MPLS PSN. 2-With IP PSN, L2TPv3 is used as PW demultiplexer. 3-With MPLS PSN, MPLS is used as PW demultiplexer. 4-The others PW demultiplexers listed in [LYR]: GRE, IPsec and MPLS are not supported. It has to be decided whether we need to support them or not. 5-The payload is a complete FR frame (see Section 14) with the exception of HDLC opening and closing flags and the Frame check sequence (FCS) and with bit/byte stuffing undone. 6-Sequencing is provided by the PW protocol defined in this document. 6. General encapsulation for the two mapping modes The general frame relay over pseudo-wires (FRoPW) packet format for carrying frame relay information (user's payload and frame relay control information) between two PEs is shown in Figure 4. Kawa, et al. [Page 8] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 +-------------------------------+ | | | PSN Delivery Header | +-------------------------------+ | | | PW Identifier header | +-------------------------------+ | FRoPW Header | | | +-------------------------------+ | | | Payload | +-------------------------------+ | Pad (if requided) | +-------------------------------+ Figure 4 - General format of FRoPW packet 1. PSN delivery header is a header specific to the PSN and the tunneling technology in use (L2TP or MPLS) This header is used to switch the FroPW packet through the packet swtiched core. It is discussed in the following sub-sections addressing each type of PSN and tunneling technology. 2. PW identifier header contains an identifier for multiplexing PWs within a PSN tunnel. 3. FRoPW header contains protocol control information for providing a frame relay service. Its structure is provided in the following sections addressing each mapping mode. 4. The contents of the payload field depends on the mapping mode. The details are provided in the following sections addressing each mapping mode. The Pad is used for the following reason: When a pseudo-wire traverses a link that requires a minimum layer 2 frame length (for example, Ethernet), padding characters are added at the end of the FRoPW packet (i.e. after the payload field) to produce, if necessary, the required minimum length. 7. Frame Relay over MPLS PSN for the one-to-one mapping mode 7.1. MPLS tunnel and VC LSPs MPLS label switched paths (LSPs) called "Tunnel LSPs" are used between PEs and within MPLS PSN core for forwarding purposes of FRoPW packets. A tunnel LSP corresponds 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 VC in one direction. Since LSPs are unidirectional, a pair of VC LSPs and corresponding tunnel LSPs carrying traffic in opposite directions will be required. Kawa, et al. [Page 9] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 In PE1 to PE2 direction a tunnel LSP is used for forwarding FRoPW packets from PE1 to PE2,the corresponding LSP label is not related to any frame relay VC. When PE1 has to forward 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 must be always at the bottom of the label stack. The VC label is not visible in the core PSN, only the tunnel LSP label and possibly other labels used in the core PSN for forwarding purposes until the FRoPW packet reaches PE2. While the FRoPW packet travels across the MPLS network, additional labels may be pushed on (and then popped off) as needed. When PE2 receives a FRoPW packet, it forwards the packet to the local CE based on the LSP VC label. The processing is similar in the opposite direction from PE2 to PE1 with the corresponding LSP used in the PE2 to PE1 forwarding direction. 7.2. Relationship between FR VCs and MPLS VC LSPs Frame Relay VCs are considered to be bidirectional 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 LSPs are unidirectional and are established separately. Therefore for each FR VC there will be, in general, two VC LSPs such that each one will be assigned to carry the traffic in a different direction from the other. 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 exist: One VC LSP to transport the traffic from PE1 to PE2 and the other to transport the traffic in the opposite direction. 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 each VC LSP. This mapping between a FR VC and a pair of MPLS LSPs corresponds to the one-to-one mapping described in Section 5. 7.3. One-to-one mapping and FRoPW packet format over MPLS PSN For the one-to-one mapping mode for frame relay over MPLS PSN, the FRoPW packet format is shown in Figure 5. Kawa, et al. [Page 10] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 +-------------------------------+ | Tunnel LSP label(s) | n words (1 word per label) +-------------------------------+ | VC LSP label | 1 word +-------------------------------+ | FRoPW Header | | (See Figure 6) | 1 word +-------------------------------+ | Payload | |(from a frame relay frame | | information field) | N bytes | | +-------------------------------+ | Pad (if required) | +-------------------------------+ Figure 5 - FR over MPLS packet format for the One-to-one mapping Tunnel LSP label(s): The Tunnel LSP label(s) corresponds to the PSN delivery header of Figure 4. The label(s) is/are used by MPLS PSN nodes to forward a FRoPW packet from one PE to the other. VC LSP Label: The VC LSP label identifies one PW (i.e. one LSP) assigned to a FR VC in one direction. It corresponds to the PW identifier header of Figure 4. Together the Tunnel LSP label(s) and VC LSP label form an MPLS label stack [RFC3032]. FRoPW header: FRoPW header contains protocol control information. Its structure is shown in Figure 6. The above three headers were referred as "control words" in Figure 2. 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 |F|B|D|C|Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 - FRoPW header structure for one-to-one mapping mode The meaning of the fields of FRoPW packet header (Figure 6) is as follows: Res (bits 0 to 3): Reserved bits. They are set to zero on transmission and ignored on reception. Kawa, et al. [Page 11] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 F (bit 4): FR FECN (Forward Explicit Congestion Notification) bit [Q922]. B (bit 5): FR BECN (Backward Explicit Congestion Notification) bit [Q.922]. D (bit 6): FR DE bit indicates the discard eligibility [Q922]. C (bit 7) FR frame C/R (command/response) bit [Q922]. Res (bits 8 and 9): Reserved bits. They are set to zero on transmission and ignored on reception. Length (bits 10 to 15): The length field is used in conjunction with the padding of short FRoPW packets when the link layer protocol (a notable example is Ethernet) requires a minimum frame length. If the total length of a FRoPW packet (Figure 5) is less than 64 bytes, padding has to be performed. When padding of a short FRoPW packet is performed the length field is the sum of the lengths of the following fields of the FRoPW packet (Figure 5) specified in bytes: Tunnel LSP label(s), VC LSP label, FRoPW Header, Payload. 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 receiving PE. 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 FRoPW packet. 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 performed to generate a new sequence number. The value of zero indicates that the sequence number field is not used. Payload: The payload field corresponds to Q.922 frame relay frame information field with bit/byte stuffing removed. The default for the number of bytes in a Q.922 information field is 262 bytes. Recommendation Q.922 recommends to support a size of a least 1600 bytes [Q922 clause A.5.1]. The maximum length of the payload field should be agreed by the two PEs when the VC LSP is established. Kawa, et al. [Page 12] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 Pad: The Pad consists of a number of characters (including zero character) to bring the FRoPW packet size to the minimum size required by the link layer protocol, in particular IEEE 802.3/Ethernet.Any 8-bit character with a decimal value from 0 to 255 may be used as a padding character. 7.4. FRoPW packet processing 7.4.1. Generation of 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: - Command/Response (C/R or C) bit: The C bit is copied unchanged in the FRoPW header. - Discard eligibility indicator (DE or D): The D bit is set as follows in the FRoPW header: This bit, if used, is set to 1 to indicate a request that a frame should be discarded in preference to other frames in a congestion situation. Setting of this bit by a PE is optional. However, no PE shall clear this bit (set it to 0 if it was received with the value of 1). A PE that does not provide discard eligibility notification shall pass this bit unchanged. Networks are not constrained to discard only frames with D = 1 in the presence of congestion [Q922 Annex A]. - Forward explicit congestion notification (FECN or F bit): FECN may be set by a congested PE to notify the user that congestion avoidance procedures should be initiated where applicable for traffic in the direction of the FRoPW packet carrying the FECN [Q922]. This bit is set to 1 to indicate to the destination that the frames it receives have encountered congested resources. This bit may be used by a destination to adjust its transmission rate. While setting this bit by a PE is optional, no PE shall clear this bit (set it to 0 if it was received with the value of 1). PEs that do not provide FECN shall pass this bit unchanged. Kawa, et al. [Page 12] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 - Backward explicit congestion notification (BECN or B bit): BECN follows the same processing rules as FECN, except that it applies to the opposite direction [Q922]. - Length: See the following sub-section "Processing of the Length field by the sender". - Sequence number: See the sub-section "Processing of the Sequence number field by the sende - Payload and Pad: The payload of the FRoPW packet is the contents of ITU- T Recommendation Q.922 [Q922] frame relay frame information field (see Section 14) stripped from any bit or byte stuffing. Padding characters may follow the payload field; see the following sub-section on "Processing of the length field by the sender". Additional processing is performed by the lower protocol layers in order to transmit the FroPW packet to its next destination. 7.4.1.1. Processing of the length field by the sender The procedure described here is used to determine whether padding is required or not. Let: - Length_FRoPW_packet be the length in bytes of the first four fields (Tunnel LSP label(s), VC LSP label, FRoPW header and Payload) of a FRoPW packet shown in Figure 5, Length_field be the contents of the length field of the FRoPW header, - Min_length = 64 bytes - Padding_length be the number (in bytes) of the padding characters to be added. The padding procedure is as follows: If the link layer protocol does not have a minimum length requirement then Length_field is set to zero and no padding is required. Else if Length_FRoPW_packet >= Min_lengththen padding is not required; set Length_field to zero. Kawa, et al. [Page 13] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 Else padding is required and the following performed: Padding_length = Min_length - Length_FRoPW_packet; Append Padding-length characters at the end of the FRoPW packet (after the payload field). Length_field = length_FRoPW_packet. End of the padding procedure. 7.4.1.2. Processing of the sequence number field by the sender The sequence number field is set according to whether the sequence number is used or not. If the PE supports 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 value (65535) the next sequence number wrap to 1 (the value of 0 is skipped). If the PE does not support sequence number processing, then the sequence number field must be set to 0. 7.4.2. Reception of FRoPW packets When a PE receives a FRoPW packet, it processes the different fields of the FRoPW header in order to synthesize a new frame relay frame for transmission to a CE on a FR UNI or NNI. The PE performs the following actions (not necessarily in the order shown): - It generates the following FR frame header fields from the corresponding fields of the FRoPW packet as follows: - C/R bit is copied unchanged in the frame relay header. Kawa, et al. [Page 14] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 - D bit is copied as follows into the frame relay header DE bit: If it was set to one in the incoming FRoPW packet, it must be copied unchanged in the FR frame header or, depending on the traffic policing performed by the PE and it state of congestion, the FRoPW packet may be dropped. Otherwise if the D bit was set to zero, it may be set to zero or one, depending on the traffic policing performed by the PE device. Setting of this bit by a PE is optional. - The F bit is copied as follows in the frame relay header FECN bit: 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. Setting this bit by a PE is optional, if the PE does not support FECN, it shall pass this bit unchanged. - BECN follows the same processing rules as FECN, except that it applies to the opposite direction. - 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 after removing any padding character and retrieves the appropriate DLCI. 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. The FR frame is queued for transmission on the selected frame relay UNI or NNI. 7.4.2.1. Checking the sequence number by the receiving PE If the receiving PE does not support sequence number processing, then it will skip the processing of the sequence number field. If the receiving PE supports packet sequencing capability, 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. Note a sequence number equal to 0 means that the sender does not support the use of sequence number. Kawa, et al. [Page 15] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 - 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 the packet is in order, then it passes the sequence number check and 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 silently discarded. As an option, a PE may buffer out of order FRoPW packets to re-order and deliver them in order. Re-ordering FRoPW packets is an implementation option but requires that the sender numbers FRoPW packets. 7.4.2.2. Processing of the length field by the receiver Any padding character, if present, in the payload field of a FRoPW packet received must be removed before forwarding the data to the next destination. The procedure described here is used to remove padding characters. Let: - Length_FRoPW_packet be the length of a FRoPW packet received as shown in Figure 5, Length_field be the contents of the length field of the FRoPW header of the packet received, - Padding_length be the length of the pad to be removed from the end of the payload field. Padding removal procedure: If Length_field is set to zero then there is no padding characters following the payload field Else padding characters are included and their length is computed as follows: Kawa, et al. [Page 16] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 Padding_length = Length_FRoPW_packet - Length_field; Remove Padding-length characters from the end of the FRoPW payload field. End of the padding removal procedure. 7.5. Handling of error conditions If a PE receives a FRoPW packet with errors, it shall discard it silently. 8. FR SVC and SPVC Signalling between PEs Not supported in this document. 9. FR PVC provisioning Provisioning of FR PVCs requires the following actions: The PEs and CEs are configured independently for each FR UNI or NNI PVC segments. Some of the configuration parameters may include: - Outgoing and incoming throughputs (CIR), - Outgoing and incoming committed burst sizes (Bc), ¸ - Outgoing and incoming excess burst sizes (Be), - Outgoing and incoming maximum frame lengths, - The DLCI assigned to the FR PVC locally, - If used, FR transfer and discard priority class or FR service class [X.36, X76] assigned to the FR VC. To complete the FR VC, a PW (i.e. a pair VC LSP) is established between the two PEs. Establishment of FR PW will be addressed in the future. To check the status of the FR PW at the remote PE, a PE execute a PVC maintenance protocol (analogous to Q.933 Annex A PVC management procedure [Q933, FRF2] to exchange PVC status information and for "keep-alive" purposes. The PVC maintenance protocol will be addressed in the future. 10. Frame relay port mode 10.1. General Frame relay port mode or many-to-one mapping is an optional capability. It applies to both MPLS and L2TPv3 pseudo-wires. Figure 8 illustrates the concept of frame relay port mode. Kawa, et al. [Page 17] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 +------+ +-------+ | FR | | FR | |device| FR UNI/NNI | device| | [P1]------------------------[P2] | | | carrying n FR VC | | +------+ | +-------+ | [Pn]: A port | | (a) FR interface between two | FR devices | | V |<---------------------------->| | | +----+ +----+ +------+ | | One PW pair | | +------+ | | | |==================| | | | | FR | FR | PE1| carrying n FR VC | PE2| FR | FR | |device|----------| | | |---------|device| | CE1 | UNI/NNI | | | | UNI/NNI | CE2 | +------+ +----+ +----+ +------+ | | |<----------------------------------------------->| n FR VC (b) Pseudo-wires replacing the FR interface Figure 7 - Concept of frame relay port-to-port mode Figure 7 (a) shows two frame relay devices physically connected with a frame relay UNI or NNI. Between their two ports P1 and P2, n frame relay VCs are configured. Figure 7 (b) shows the replacement of the physical frame relay interface with a pair of PEs and a pair of PWs (one PW for each traffic direction between PE1 and PE2). A PW may be an MPLS VC LSP or a L2TPv3 tunnel. The interface between a FR device and a PE is either a FR UNI or NNI. The set of n FR VCs between the two FR ports P1 and P2 (cf. Figure 7 (a)) are mapped now to one pair of PWs, hence with port mode we have many-to-one mapping between FR VCs and a PW. FR VCs are not visible individually to a PE, there is no configuration of individual FR VC in a PE. A PE processes the set of FR VCs assigned to a port as an aggregate. FR traffic and QoS parameters listed in Section 9 may be assigned to the aggregate traffic flowing on an interface between a CE and a PE and not to individual FR VC and policing may be performed on the aggregate. FR port mode provides transport between two PEs of a complete FR frame excluding the opening and closing flags and the Frame check Kawa, et al. [Page 18] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 sequence (FCS) and with bit/byte stuffing undone (see Figure 8) For more information, on FR frame format the reader should consult [Q922, Q921]. bit 8 7 6 5 4 3 2 1 bit 8 7 6 5 4 3 2 1 +-------------------------------+ +-------------------------------+ | Upper DLCI |C/R| 0 | | Upper DLCI |C/R| 0 | +------------------------------- +-------------------------------+ | Lower DLCI | F | B | DE| 1 | | DLCI | F | B | DE| 0 | +-------------------------------+ +-------------------------------+ | | | DLCI | 0 | : Q.922 Information field : +-------------------------------+ : (i.e. FR payload) : | Lower DLCI | 0 | 1 | | | +-------------------------------+ +-------------------------------+ | | : Q.922 Information field : : (i.e. FR payload) : | | +-------------------------------+ (a) With 10 bits for the DLCI (b) With 23 bits for the DLCI Figure 8 - Fields of the frame relay frame used with port mode 10.2. FRoPW packet format for MPLS port mode When MPLS PW is used with port mode, the FRoPW packet format is shown in Figure 9. +-------------------------------+ | Tunnel LSP label(s) | n words (1 word per label) +-------------------------------+ | VC LSP label | 1 word +-------------------------------+ | FRoPW Header | | | 1 word +-------------------------------+ | Payload | | (See Figure 8) | N bytes | and a Pad (if needed) | +-------------------------------+ Figure 9 - FR over MPLS packet format for the port mode mapping Tunnel LSP label(s) role is as specified for the one-to-one mapping. The VC LSP label identifies one PW (i.e. one LSP) assigned to one port for a set of FR VCs using that port. There is a pair of VC LSPs for the two traffic directions. Kawa, et al. [Page 19] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 FRoPW header: FRoPW header contains protocol control information. Its structure is shown in Figure 10. Frame relay control bits (F, B, D and C) are not used and are set to zero. Note it is possible to apply FECN, BECN and DE bits (bits 4, 5 and 6) to the aggregate traffic but this use of the indicators requires further study. The use of the length and sequence number fields is the same as for the one-to-one mapping, with the following exceptions: There is one sequence number counter for the set of FR VCs and not one for each individual FR VC. To compute the FRoPW packet size to determine whether padding is needed or not, the format of Figure 9 is used. 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 |0|0|0|0|Res| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10 - FRoPW header structure for the port mode mapping The payload field contains a FR frame as shown in Figure 8 extracted from an incoming FR frame received from a CE and padding characters if needed (see section 6 for the need to pad). The two peer PEs must agree on the length of the DLCI field (2 or 4 bytes) and the maximum length of FR frame information field. The default for the number of bytes in a Q.922 information field is 262 bytes. Recommendation Q.922 recommends to support a size of a least 1600 bytes [Q922 clause A.5.1]. 10.3. FRoPW packet format for L2TPv3 port mode When L2TPv3 PW is used with port mode, the FRoPW packet format is shown in Figure 11. This format is imported from [L2TPv3 Figure 3.2.2] and is very similar to FRoPW general packet format of Figure 4. Kawa, et al. [Page 20] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN Delivery Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Tunnel Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-Specific Sublayer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunneled L2 Frame (See Figure 9) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11 - FR over L2TPv3 packet format for the port mode mapping PSN delivery header: The PSN delivery header serves the same role as the PSN delivery header of Figure 4. When the PSN is an IP network, the PSN delivery header is an IP v4 or v6 datagram header. L2TP Tunnel header: L2TP Tunnel header corresponds to the PW identifier header of Figure 4. There are two formats for L2TP Tunnel header defined in [L2TPv3]: One when L2TPv3 runs over IP directly and another one for L2TPv3 over UDP. The two formats are shown in Figure 12 (a) and (b). The description of the various fields can be found in [L2TPv3] 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | : Cookie (optional, maximum 64 bits) : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) L2TPv3 over IP Tunnel Header 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|x|x|x|x|x|x|x|x|x|x|x| Ver | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Cookie (optional, maximum 64 bits)... : : : | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (b) L2TPv3 over UDP Tunnel Header Figure 12 - L2TPv3 over IP and UDP Tunnel Header Kawa, et al. [Page 21] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 L2-Specific Sublayer: L2-Specific Sublayer header shown in Figure 11 is analogous to FRoPW header of Figure 4. With L2TPv3 the same FRoPW header defined in Figure 10 for MPLS port mode is used also with L2TPv3. Although L2TPv3 draft defines a default L2- Specific Sublayer header, it is advantageous to use the same FRoPW header structure with the different types of pseudo- wires and the two mapping modes. It should be possible to add to the FRoPW header of Figure 10 in the next version of this draft the other fields (P, S and Offsz) defined in for L2-Specific Sublayer default header [L2TPv3]. Tunneled L2 Frame: The Tunneled L2 Frame of Figure 11 corresponds to the payload of the general FRoPW format shown in Figure 4. This field is used to carry a FR frame as shown in Figure 8. Therefore for both MPLS and L2TPv3 used with FR port mode, the payload of the FRoPW packet is the same and consists of a frame relay frame, excluding the flags and the FCS, with bit/byte stuffing undone. 10.4. FRoPW processing for port mode When a PE receives a FR frame from a FR device (a CE), it shall remove the flags, undo bit/byte stuffing and check the FCS field to determine whether transmission errors occurred or not. If transmission errors occurred, the frame is discarded. Otherwise, the FR fields shown in Figure 8 are encapsulated in a FRoPW packet payload to be forwarded to the remote PE. A PE shall not modify any of the fields shown in Figure 8, they shall be forwarded to the remote PE as received from the FR device. The processing of the length and sequence number fields is the same as for the one-to-one mapping, with the following exceptions mentionned earlier: There is one sequence number counter for the set of FR VCs and not one for each individual FR VC. To compute the FRoPW packet size to determine whether padding is needed or not, the format of Figure 9 is used. Upon receiving a FRoPW packet, the remote PE shall extract the payload field, encapsulate the result in a FR frame for transmission to the local FR device. 11. Frame relay service over pseudo-wires Frame relay service (FRS) is defined in terms of a number of attributes in the basic ITU-T Recommendation on frame relay service [I233]. The most two fundamental aspects of FRS are: 1-The requirement to deliver in order the user's data between two frame relay service access point, 2-The detection of transmission errors if they are detectable. Kawa, et al. [Page 22] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 Besides the above two service attributes, FRS is defined by a number of traffic and QoS attributes in a number of ITU-T Recommendations [I.233, X.36 and X.76] and in the Frame Relay Forum Implementation Agreement FRF.13 [FRF13]. The following is a partial list illustrating some of frame relay service attributes: - Committed information rate - Excess information rate - Committed burst size - Excess burst size - transit delay - Frame delivery ratio - Service availability FR service providers use FRS attributes to define Service Level Agreements (SLA). A frame relay SLA are contractual and binding agreement describing the FRS service providers offer to their customers. An important question to ask is: What does it mean to offer a frame relay service? It means that the two fundamental attributes of FRS about in-sequence delivery and error detection must be satisfied by a network providing a frame relsy service. The other FRS attributes related to QoS and traffic are a matter of business decision because a multitude of possibilities are available to service providers. In one extreme, a service provider may offer a FRS with very stringent characteristics and in the opposite case, it will not provide any guarantee and provides just a best effort service. If we ask the previous question in the context of PWE3, we must first observe that PWE3 does not require that pseudo-wires emulate perfectly or faithfully the characteristics of the native service. In the case of FRS this means that the requirements to deliver in sequence the user's data and to detect transmission errors may be relaxed. For both the one-to-one mapping mode and many-to-one mapping/port mode, we have the following emulation possibilities with regard to the two main attributes of FRS: - In-sequence delivery of user's data: 1-It is possible to emulate perfectly/faithfully this requirement. If the PSN does not guarantee in sequence delivery, the PEs should use the sequence number capability included in FRoPW packets to number the packets and check whether they are received in sequence or not. Kawa, et al. [Page 23] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 2-Alternatively a service provider may elect to drop the requirement to deliver in-sequence FRoPW packets. This document does not recommend this practice unless for a good reason. - Detection of transmission errors: This requirement must be supported. PW layer does not have the capability to detect transmission errors but rely on the underlying link layer protocol for transmission error detection. About FRS traffic and QoS parameters, there is no strict requirements to meet. Frame relay traffic and QoS attributes defined in the relevant FR documents allow service providers to offer various combinations of traffic and QoS parameters without imposing any strict performance objective. The same thing should be possible in a PWE3 network environment and it is not relevant to refer to how faithful/perfect FRS traffic and QoS attributes are provided because of the wide spectrum of possibilities. There is one additional note to add about FR port mode. Since the individual FR VCs are not visible to the PEs individually but only as an aggregate, the frame relay service, and in particular, the traffic and QoS parameters, provided to the CEs does not apply to the individual FR VCs assigned to a port but to their aggregate. 12. IANA considerations Not applicable to this document. 13. Security considerations PWE3 provides no means of protecting the contents or delivery of the FRoPW packets on behalf of the native service. PWE3 may, however, leverage security mechanisms provided by the PSN Tunnel Layer. A more detailed discussion of PW security is give in [LYR]. Kawa, et al. [Page 24] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 14. Supplement on frame relay frame formats FR frame formats are defined in ITU-T Recommendation Q.922 [Q922]. Two formats are used in this document. The first one uses 10 bits for the DLCI (Figure 13-a) and the second one uses 23 bits for the DLCI (Figure 13-b); see also Figure A-1/Q922. The first and last octets are HDLC opening and closing flags. The DLCI occupies the second and third octets or the second, third, fourth and fifth octets as shown in Figure XX. There are various control fields: C/R is HDLC command and response bit. F and B are respectively the forward and backward congestion notification bits. DE is the discard eligibility bit. FCS is the frame check sequence. Two generator polynomials are used. One produces a 16-bit sequence [Q921] and the other a 32-bit sequence [FRF14]. bit 8 7 6 5 4 3 2 1 bit 8 7 6 5 4 3 2 1 +-------------------------------+ +-------------------------------+ | Flag | | Flag | | 0 1 1 1 1 1 1 0 | | 0 1 1 1 1 1 1 0 | +-------------------------------+ +-------------------------------+ | Upper DLCI |C/R| 0 | | Upper DLCI |C/R| 0 | +------------------------------- +-------------------------------+ | Lower DLCI | F | B | DE| 1 | | DLCI | F | B | DE| 0 | +-------------------------------+ +-------------------------------+ | | | DLCI | 0 | :Frame relay information field : +-------------------------------+ : (i.e.payload) : | Lower DLCI | 0 | 1 | | | +-------------------------------+ +-------------------------------+ | Frame relay information field | | FCS (2 or 4 octets) | : (i.e. payload) : | | : : +-------------------------------+ | | | Flag | +-------------------------------+ | 0 1 1 1 1 1 1 0 | | FCS (2 or 4 octets) | +-------------------------------+ : : +-------------------------------+ | Flag | | 0 1 1 1 1 1 1 0 | +-------------------------------+ a-With 10 bits for the DLCI b-With 23 bits for the DLCI Figure 13 - Frame relay frame formats Kawa, et al. [Page 25] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 15. References [DIX] Digital, Intel and Xerox, The Ethernet, a local Area Network Data Link and Physical layer Specifications versions 1 and 2. [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. [I233] ITU-T Recommendation I.233, Frame Mode Bearer Services, ITU, Geneva, 1992. [LYR] Stewart Bryant, et al.,Protocol Layering in PWE3,draft- ietf-pwe3-protocol-layer-00.txt, May 2002, work in progress. [L2TPV3] M. Townsley, et al., Layer Two Tunneling Protocol (Version 3) "L2TPv3", draft-ietf-l2tpext-l2tp- base-02.txt, March 2002, work in progress.. [P8021Q] IEEE Std 802.1Q, Virtual bridged local area networks. [P8023] IEEE Std 802.3, Part 3 Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications. [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3- requirements-03.txt, work in progress. [PWE3FW] Prayson Pate, et al., Internet draft, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), draft-ietf- pwe3-framework-01.txt, work in progress. [Q921] ITU-T Recommendation Q.921, ISDN Data Link Layer Specification, ITU,Geneva, 1997. [Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer Specification for Frame Mode Bearer Services, ITU, Geneva, 1992. Kawa, et al. [Page 26] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 [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. [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. 16. Author's Addresses Claude Kawa email: claude.kawa@sympatico.ca 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 Nokia email: ravi.bhat@nokia.com Nishit Vasavada Nokia email: nishit.vasavada@nokia.com Luca Martini Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 e-mail: luca@level3.net Kawa, et al. [Page 27] Internet Draft draft-ietf-pwe3-frame-relay-00.txt June 2002 Nasser El-Aawar Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO, 80021 e-mail: nna@level3.net Giles Heron PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom e-mail: giles@packetexchange.net Dimitri Stratton Vlachos Mazu Networks, Inc. 125 Cambridgepark Drive Cambridge, MA 02140 e-mail: d@mazunetworks.com Dan Tappan Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 e-mail: tappan@cisco.com Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 e-mail: erosen@cisco.com Steve Vogelsang Laurel Networks, Inc. Omega Corporate Center 1300 Omega Drive Pittsburgh, PA 15205 e-mail: sjv@laurelnetworks.com Vinai Sirkay Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 e-mail: sirkay@technologist.com Chris Liljenstolpe Cable & Wireless 11700 Plaza America Drive Reston, VA 20190 e-mail: chris@cw.net Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 e-mail: kireeti@juniper.net Kawa, et al. [Page 28]