PWE3 Working Group Claude Kawa Internet Draft Ðcole Polytechnique Expires: January 2005 Rao Cherukuri Cisco Systems, Inc. (Editors) Andrew G. Malis Tellabs Luca Martini Cisco Systems, Inc. David Sinicrope Ericsson August 2004 Frame Relay over Pseudo-Wires draft-ietf-pwe3-frame-relay-03.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright(C) The Internet Society (2004). All Rights Reserved. Kawa, et al. [Page 1] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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. The first, one-to-one mapping mode, is characterized by a one to one relationship between a frame relay VC and a pair of MPLS LSPs, and is defined for MPLS PSN only. The second mode is known as port mode or many-to-one mapping mode and is defined for both MPLS PSNs and IP PSNs with L2TPv3. Co-authors The following are co-authors of this document: 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 Nasser El-Aawar Level 3 Communications, LLC Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 4 4. Requirements for Frame Relay Over Pseudo-wires. . . . . . . . 5 5. Reference model and PWE3 protocol layering . . . . . . . . . . 5 6. General encapsulation for the two mapping modes . . . . . . 7 7. Frame Relay over MPLS PSN for the one-to-one mapping mode. . . 8 8. FR PVC provisioning. . . . . . . . . . . . . . . . . . . . . . 16 9. Traffic management aspects 16 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. . . . . . . . . . . .24 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 16. Author's Addresses . . . . . . . . . . . . . . . . . . . . . 27 Kawa, et al. [Page 2] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1. Introduction This document defines frame relay pseudo-wire 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. 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 is an overview of PWE3 reference model and PWE3 protocol layers described in [PWE3ARC]. 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 addresses FR PVC provisioning. Section 9 covers the traffic management aspects. Section 10 describes FR port mode for MPLS PSN and IP PSN with L2TPv3. 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. Kawa, et al. [Page 3] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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. PWE3 definitions can be found in [PWE3REQ, PWE3ARC]. 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 Kawa, et al. [Page 4] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 4. Requirements for Frame Relay Over Pseudo-Wires The section lists the main frame relay pseudo-wire requirements to be met by a PE: 1. Frame Length: MUST be able to transport variable length FR frames and SHOULD be able to transport FR frames without being limited by the PSN MTU through the use of PW fragmentation [FRAG]. 2. Bidirectional traffic: MUST support bidirectional traffic. 3. Frame ordering: MUST deliver frame relay frames in the order. as they were transmitted. 4. 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 [X36, X76]. 5. PVC Status Maintenance: MUST support the mapping and transport of frame relay PVC status indications defined in ITU-T Recommendation X.36 [X36]. Note PVC status signaling will be addressed in another IETF draft. 6. Traffic Management: SHOULD be able to map the following FR traffic management parameters to PWs and tunnel traffic parameters: a) Committed Information Rate (CIR) or throughput, b) Committed burst size (Bc), c) Excess Burst Size (Be), d) Maximum frame size. 7. 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. 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, PWE3ARC]. Kawa, et al. [Page 5] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 |<-------------- Emulated Service ---------------->| | | | |<------- Pseudo Wire ------>| | | | | | | | |<-- PSN Tunnel -->| | | | V V V V | V AC +----+ +----+ AC V +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ ^ | | |==================| | | ^ +-----+ ^ | +----+ +----+ | | ^ | | Provider Edge 1 Provider Edge 2 | | | | | | Customer | | Customer Edge 1 | | Edge 2 | | | | native service native service 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, because there is a one-to-one correspondence between a FR VC and one Pseudo Wire. The second mapping is called "many-to-one" mapping or "port mode" Because multiple FR VCs assigned to a port are mapped to one Pseudo Wire. One-to-one mapping mode is defined for MPLS PSNs only and port mode is defined for both MPLS PSN and IP PSN with L2TPv3. 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 PSNs and IP PSNs. With IP PSNs, 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 PSNs and IP PSNs with L2TPv3. In terms of PWE3 protocol layering defined in [PWE3ARC], this specification utilizes the protocol stack shown in Figure 2. Kawa, et al. [Page 6] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 +-------------+ +-------------+ | Emulated | | Emulated | | Frame Relay | Emulated Service | Frame Relay | | Services |<==============================>| Services | | | | | +-------------+ Pseudo Wire +-------------+ |Demultiplexer|<==============================>|Demultiplexer| +-------------+ +-------------+ | PSN | PSN Tunnel | PSN | | MPLS or IP |<==============================>| MPLS or IP | +-------------+ +-------------+ | Physical | | Physical | +-----+-------+ +-----+-------+ PE1 PE2 Figure 2: Frame Relay PWE3 Protocol Stack Reference Model For the purpose of this document, PE1 is defined as the ingress router, and PE2 as the egress router. A layer 2 PDU received at PE1, will be encapsulated at PE1, transported, decapsulated at PE2, and transmitted out of PE2. 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 3. +-------------------------------+ | | | PSN Transport header | | (As required) | +-------------------------------+ | Pseudo Wire (PW) Header | +-------------------------------+ | Control Word | +-------------------------------+ | FR Service | | Payload | +-------------------------------+ | Pad (if required) | +-------------------------------+ Figure 3 - General format of FR encapsulation over PSN Kawa, et al. [Page 7] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 The FRoPW packet consists of the following fields: Control word, Payload and Pad (if required) preceded by PSN Transport and pseudo-wire header. The meaning of the different fields is as follows: 1. PSN Transport header is specific to the PSN and the tunneling technology used (L2TP or MPLS) This header is used to switch the FRoPW packet through the packet switched core. It is described in the following sub-sections addressing each type of PSN and tunneling technology. 2. PW header contains an identifier for multiplexing PWs within a PSN tunnel. 3. Control Word 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 FR service 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 octets are added at the end of the FRoPW packet (i.e. after the payload field) to produce 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 the MPLS PSN core network for forwarding purposes of FRoPW packets. A tunnel LSP corresponds to "PSN transport" 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, and frame relay VCs are bidirectional, a pair of VC LSPs and corresponding tunnel LSPs carrying traffic in opposite directions will be required. Kawa, et al. [Page 8] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 In the PE1 to PE2 direction a tunnel LSP is used for forwarding FRoPW packets from PE1 to PE2, and the tunnel LSP label is not related to any particular 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 is at the bottom of the label stack. As with the other PWE3 encapsulations, 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 signaling establishes the two directions simultaneously with a single set of control messages flows. In general each direction of a frame relay VC may have different traffic and QoS characteristics. The resource management of a frame relay implementation treats each direction separately and independently. MPLS LSPs, on the other hand are 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 single direction. 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 4. Kawa, et al. [Page 9] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 +-------------------------------+ | Tunnel LSP label(s) | n*4 octets (four octets per label) +-------------------------------+ | VC LSP label | 4 octets +-------------------------------+ | Control Word | | (See Figure 5) | 4 octets +-------------------------------+ | Payload | | (Frame relay frame | | information field) | n octets | | +-------------------------------+ | Pad (if required) | +-------------------------------+ Figure 4 - FR Over MPLS Packet Format for the One-to-One Mapping The encapsulation consists of the following fields: Control Word, Payload and Pad (if required), preceded by the Tunnel LSP label(s) and VC LSP label. The meaning of the different fields is as follows: Tunnel LSP label(s): The Tunnel LSP label(s) corresponds to the PSN transport header of Figure 3. 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 header of Figure 3. Together the Tunnel LSP label(s) and VC LSP label form an MPLS label stack [RFC3032]. Control Word: Control Word contains protocol control information. Its structure is shown in Figure 5. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ |F|B|D|C|I|L| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 - Control Word structure for the one-to-one mapping mode Kawa, et al. [Page 10] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 The meaning of the Control Word fields (Figure 5) is as follows (see also [X36 and X76] for frame relay bits): MBZ (bits 0 to 3): Reserved bits. They are set to zero on transmission and ignored on reception. 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. I, L (bits 8 and 9): I and L are the Initial and Last fragmentation bits and their functionality is specified in [FRAG]. 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 required to reach its minimum frame size. If the total length of FRoPW payload, which is the sum of the lengths of the control word and Payload fields is less than 64 octets, then padding has to be performed. In this case length field MUST be set to the FRoPW 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 ingress PE. Sequence number (Bit 16 to 31): Sequence numbers provide one possible mechanism to ensure the ordered delivery of FRoPW packets. A circular list of sequence numbers is used, skipping the value zero. The value of zero indicates that the sequence number field is not used. See section 7.4 for the sequence number generation and checking algorithms. Kawa, et al. [Page 11] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 Note: The use of sequence numbers may not be required if the network itself ensures ordered delivery of FRoPW packets. Payload: The payload field corresponds to X.36/X.76 frame relay frame information field with bit/byte stuffing and frame relay header (DLCI)removed. It is RECOMMENDED to support a frame size of at least 1600 bytes. The maximum length of the payload field MUST be agreed by the two PEs when the VC LSP is established. Pad: The Pad consists of a number of octets (including zero octet) required to guarantee that the FRoPW packet size is not less than 64 packets. Any octet with a decimal value from 0 to 255 may be used as a padding character. Note: The limit of 64 octets for the packet length below which padding is required, aligns with the minimum Ethernet frame size. 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 interfaces. The PE takes the following actions (not necessarily in the order shown): - It 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 FRoPW Control Word. - Discard eligibility indicator (DE or D): The D bit is set as follows in the Control Word: 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. This bit is often set as a result of ingress frame policing. Setting of this bit by a PE is OPTIONAL. However, no PE SHALL ever 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. - 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 Control Word carrying the FECN. Kawa, et al. [Page 12] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 While setting this bit by a PE is OPTIONAL, PE MUST not 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. - Backward explicit congestion notification (BECN or B bit): BECN follows the same processing rules as FECN, except that it applies to the backward direction. - Length: If the FRoPW 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 and padding has to be performed. Otherwise the length field MUST be set to zero. - Sequence number: The sequence number field is set if the FR PW uses sequence numbers. If the ingress PE supports the sequence number capability then the following procedure to number FRoPW packets is used: - The initial FRoPW packet transmitted MUST use sequence number 1, - For a subsequent frame, the sequence number corresponds to the sequence number of the preceding frame incremented by 1 up to the maximum value of 65535, - When the sequence number reaches the maximum 16 bit value (65535) the next sequence number wraps to 1 (the value of 0 is skipped). If the FR PW uses sequence numbers do not support sequence number processing, then the sequence number field must be set to 0. - Payload and Pad: The payload of the FRoPW 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. Padding characters may follow the payload field. Additional processing is performed by the lower protocol layers in order to transmit the FRoPW packet to its next destination. Kawa, et al. [Page 13] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 7.4.2. Reception of FRoPW packets When a PE receives a FRoPW packet, it processes the different fields of the control word 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. - D bit is copied unchanged into the frame relay header DE bit. - The F bit is processed as follows: If it was set to one in the incoming FRoPW packet, it must be copied unchanged into the FECN bit in the frame relay header. Otherwise if it was set to zero, the FECN bit may be set to one, depending on the congestion state of the PE device in the forward direction. Setting this bit by a PE is OPTIONAL. - BECN follows the same processing rules as FECN, except that it applies to the backward direction. - 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 FRoPW 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. 7.4.2.1. Checking the Sequence Number by the Receiving PE When an emulated VC is initially set up, the "expected sequence number" associated with it MUST be initialized to 1. When a FRoPW packet is received the sequence number is processed as follows: Kawa, et al. [Page 14] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 - 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 sequence numbers are not used. Through management or signaling, the two PEs determine whether sequence numbers are used or not. - 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, up to a maximum of 65535 after which it skips zero and wraps from 6553 to 1. If (expected_sequence_number = 0) then expected_sequence_number := 1. FRoPW packets that are received out of order should be dropped unless they can be re-ordered without introducing significant delays. If an egress PE receives an excessive number of out-of-sequence FroPW packets, it SHOULD inform the management plane responsible for FRoPW in the PE and take the appropriate actions. The threshold for declaring that out-of-sequence FRoPW packets are excessive is not defined in this document. Note: Excessive out-of-sequence FRoPW packets has an effect similar to excessive packet loss on a frame relay VC. 7.4.2.2. Processing of the Length Field by the Receiver Any padding octet, if present, in the payload field of a FroPW packet received MUST be removed before forwarding the data. Kawa, et al. [Page 15] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 The procedure described here is used to remove padding characters. If the Length field is set to zero then there are no padding Characters following the payload field. Else padding characters are removed based on the Length field. 7.5. Handling of error conditions If a PE receives a FRoPW packet with a header containing invalid contents, it shall be discarded. For example: - An invalid or unassigned tunnel or VC label, - A value different than zero for the first four bits of the Control Word, - A length field with a content greater or equal to 64, - Inconsistencies between the content of the length field and the actual size of the FRoPW packet. - If fragmentation is not used a value different than zero for the two fragmentation bits(bits 8 and 9 of the FRoPW header). 8. 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 [X36, 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 the FR PW is addressed in [CONTROL]. 9. Traffic management aspects In ITU-T Recommendations X.36 and X.146, a number of different traffic parameters and Quality of Service (QoS) classes are defined. When a tunnel LSP is used to carry either a single frame relay VC or multiple frame relay VCs with different combinations of traffic parameters and QoS classes, the tunnel LSP shall be capable of providing the required QoS for the encapsulated frame relay VCs. In an MPLS network that does only support QoS differentiation on a per LSP basis, the tunnel LSP shall meet the most stringent QoS requirements of the frame relay VCs carried by that tunnel LSP. Kawa, et al. [Page 16] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 9.1. Use of Differentiated Services for Frame relay over MPLS: If the MPLS network supports Differentiated Services (DiffServ) Behavior Aggregates defined in informational RFCs 2475 and 3260, MPLS packets can be treated with different priorities on a Per Hop Behavior (PHB). In this case, two different types of LSPs are defined in RFC 3270 which can both be used for the tunnel LSP: - Label-Only-Inferred-PSC LSPs (L-LSP); - EXP-Inferred-PSC LSPs (E-LSP). If a L-LSP is used as a tunnel LSP, the PHB scheduling class of each packet is inferred from the label without any other information (e.g., regardless of the EXP field value). In that case, the LSP shall meet the most stringent QoS requirements of the frame relay VCs tunneled by the LSP. If an E-LSP is used as a tunnel LSP, the EXP field of the tunnel label is used to determine the PHB to be applied to each packet, i.e., different packets in one LSP may receive a different QoS. The 3-bit EXP field of the tunnel label can represent eight different combinations of Per Hop Behaviour (PHB) and drop precedence levels. The mapping of the PHB to EXP fields is either explicitly signaled at label set-up or relies on a pre-configured mapping. 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 6 illustrates the concept of frame relay port mode. Figure 6 (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 6 (b) shows the replacement of the physical frame relay interface with a pair of PEs and a PW between them. 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 which are controlled by the same signaling channel using DLCI=0 (cf. Figure 7 (a)), are mapped into one PW. Hence with port mode we have many-to-one mapping between FR VCs and a PW. Kawa, et al. [Page 17] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 +------+ +-------+ | FR | | FR | |device| FR UNI/NNI | device| | [P1]------------------------[P2] | | | carrying n FR VCs | | +------+ | +-------+ | [Pn]: A port | | (a) FR interface between two | FR devices | V |<---------------------------->| | | +----+ +----+ +------+ | | One PW pair | | +------+ | | | |==================| | | | | FR | FR | PE1| carrying n FR VCs| PE2| FR | FR | |device|----------| | | |---------|device| | CE1 | UNI/NNI | | | | UNI/NNI | CE2 | +------+ +----+ +----+ +------+ | | |<----------------------------------------------->| n FR VCs (b) Pseudo-wires replacing the FR interface Figure 6 - Concept of frame relay port-to-port mode 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 8 may be assigned to the aggregate traffic flowing on an interface between a CE and a PE and not to individual FR VCs 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 Sequence (FCS) and with bit/byte stuffing undone. For more information on FR frame formats the reader should consult Section 14 and [X36, X76]. Kawa, et al. [Page 18] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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 7. +-------------------------------+ | Tunnel LSP label(s) | n*4 octets (four octets per label) +-------------------------------+ | VC LSP label | 4 octets +-------------------------------+ | Control Word | | (see Figure 8) | 4 octets +-------------------------------+ | Payload | | (FR Address plus | | information field) | N octets | and a Pad (if needed) | +-------------------------------+ Figure 7- 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 the PW assigned to the port for a set of FR VCs using that port. There is a pair of VC LSPs for the two traffic directions. Control Word: The Control Word contains protocol control information. Its structure is shown in Figure 8. Frame relay control bits 4 to 7 (F, B, D and C) are not used and are set to zero. The use of the fragmentation bits (I and L) is the same as for the one-to-one mapping. 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 8 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|I|L| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8 - Control Word structure for the port mode mapping Kawa, et al. [Page 19] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 The payload field contains a FR frame received from a CE consists of the address field (including the DLCI and the control bits) and information field, with the opening and closing flags, bit/byte stuffing and FCS removed. The two peer PEs must agree on the length of the DLCI field (2 or 4 octets) and the maximum length of FR frame information field. These are signaled during Pseudo-Wire setup using two interface parameters [CONTROL, PWE3IANA]: 10.3. FRoPW packet format for L2TPv3 port mode When an L2TPv3 PW is used with port mode, the FRoPW packet format is shown in Figure 9. This format is imported from [L2TPv3 Figure 3.2.2] and is very similar to the packet format of Figure 3. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PSN transport Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Tunnel Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2-Specific Sublayer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunneled L2 Frame | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9 - FR over L2TPv3 packet format for the port mode mapping PSN transport header: The PSN transport header is the PSN transport header of Figure 3. When the PSN is an IP network, this header is an IP v4 or v6 datagram header. L2TP Tunnel header: L2TP Tunnel header corresponds to the PW header of Figure 3. 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 9 (a) and (b). The description of the various fields can be found in [L2TPv3]. Kawa, et al. [Page 20] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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 10 - L2TPv3 over IP and UDP Tunnel Header L2-Specific Sublayer: L2-Specific Sublayer header shown in Figure 9 is analogous to the Control Word of Figure 3. With L2TPv3 the same Control Word defined in Figure 8 for MPLS port mode is used also with L2TPv3. Tunneled L2 Frame: The Tunneled L2 Frame of Figure 9 corresponds to the payload of the general FRoPW format shown in Figure 3. 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. Kawa, et al. [Page 21] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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 frame (excluding the flags and the FCS) is encapsulated in a FRoPW packet payload to be forwarded to the remote PE. The processing of the length and sequence number fields is the same as for the one-to-one mapping, with the following exceptions mentioned earlier: There is one sequence number counter for the set of FR VCs and not one for each individual FR VC. Upon receiving a FRoPW packet, the remote PE shall extract the FRoPW 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 ITU-T Recommendation [X36]. 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. Besides the above two service attributes, FRS is defined by a number of traffic and QoS attributes in ITU-T Recommendations [X36 and X76] 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. Kawa, et al. [Page 22] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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 relay service. The other FRS attributes related to QoS and traffic are a matter of business decisions 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. 2-Alternatively a service provider MAY elect to drop the requirement to deliver in-sequence FRoPW packets. In general, this practice is NOT RECOMMENDED, since it may adversely affect the applications in the CEs - Detection of transmission errors: This requirement MUST be supported. The PW layer does not have the capability to detect transmission errors but relies on the underlying link layer protocol for transmission error detection. Regarding 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 objectives. 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. Kawa, et al. [Page 23] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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 No IANA actions are required in 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 [PWE3ARC, PWE3REQ]. 14. Supplement on frame relay frame formats FR frame formats are defined in ITU-T Recommendation X.36 [X36]. Two formats are used in this document. The first one uses 10 bits for the DLCI (Figure 11-a) and the second one uses 23 bits for the DLCI (Figure 11-b). 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 11. 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 [X36] and the other a 32-bit sequence [FRF14]. Kawa, et al. [Page 24] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 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 11 - Frame relay frame formats 15. References [CONTROL] Luca Martini, et al., Pseudowire Setup and Maintenance using LDP, ddraft-ietf-pwe3-control-protocol-05.txt, June 2004, work in progress. [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. Kawa, et al. [Page 25] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 [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. [L2TPV3] M. Townsley, et al., Layer Two Tunneling Protocol (Version 3) "L2TPv3", draft-ietf-l2tpext-l2tp-base-11.txt, October 2003, 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. [PWE3IANA] Luca Martini, et al., IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3), draft-ietf-pwe3-iana-allocation-02.txt, October 2003, work in progress. [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3- requirements-08.txt, work in progress. [PWE3ARC] Stewart Bryant, et al.,Internet draft, PWE3 Architecture, draft-ietf-pwe3-arch-07.txt, work in progress. [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. Kawa, et al. [Page 26] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 16. Author's Addresses Claude Kawa Ecole Polytechnique Montreal claude.kawa@sympatico.ca Andrew G. Malis Tellabs andy.malis@tellabs.com Rao Cherukuri Cisco Systems rcheruku@cisco.com David Sinicrope Ericsson IPI david.sinicrope@ericsson.com Prayson Pate Overture Networks prayson.pate@overturenetworks.com Ravi Bhat Nokia ravi.bhat@nokia.com Nishit Vasavada Nokia nishit.vasavada@nokia.com Luca Martini Cisco Systems Inc. lmartini@cisco.com Nasser El-Aawar Level 3 Communications, LLC. nna@level3.net Giles Heron Tellabs giles.heron@tellabs.com Dimitri Stratton Vlachos Mazu Networks, Inc. d@mazunetworks.com Dan Tappan Cisco Systems, Inc. tappan@cisco.com Kawa, et al. [Page 27] Internet Draft draft-ietf-pwe3-frame-relay-03.txt August 2004 Eric Rosen Cisco Systems, Inc. erosen@cisco.com Steve Vogelsang Laurel Networks, Inc. sjv@laurelnetworks.com Vinai Sirkay Reliance Infocomm vinai@sirkay.com Chris Liljenstolpe Cable & Wireless chris@cw.net Kireeti Kompella Juniper Networks kireeti@juniper.net Kawa, et al. [Page 28]