PWE3 Working Group Claude Kawa Internet Draft Nortel Networks Expires: March 2002 Andrew G. Malis Vivace Networks, Inc. Prayson Pate Overture Networks, Inc. Ravi Bhat Nishit Vasavada Amber Networks September 2001 Frame relay over Pseudo-Wire Emulation Edge-to-Edge draft-kamapabhava-fr-pwe3-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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice Copyright(C) The Internet Society (2001). All Rights Reserved. Abstract This document defines frame relay pseudo-wire (PW) specific aspects. A frame relay PW allows frame relay protocol control information and payload to be carried over Packet Switched Networks (PSNs) using IP, L2TP, GRE or MPLS for transport. Kawa/Malis/Pate/Bhat/Vasavada [Page 1] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Acronyms and Abbreviations . . . . . . . . . . . . . . . . . . 4 4. Requirements for Frame Relay Over PWE3 . . . . . . . . . . . . 4 5. Reference model . . . . . . . . . . . . . . . . . . . . . . . 5 6. General Encapsulation . . . . . . . . . . . . . . . . . . . . 5 7. PVC maintenance protocol. . . . . . . . . . . . . . . . . . . 10 8. Configuration prerequisites . . . . . . . . . . . . . . . . . 17 9. Frame Relay over MPLS. . . . . . . . . . . . . . . . . . . . . 18 10. Frame Relay over IP . . . . . . . . . . . . . . . . . . . . 19 11. Frame Relay over GRE. . . . . . . . . . . . . . . . . . . . 20 12. Frame Relay over L2TP. . . . . . . . . . . . . . . . . . . . 21 13. Security Considerations. . . . . . . . . . . . . . . . . . . 21 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 22 16.Author's Addresses . . . . . . . . . . . . . . . . . . . . . 22 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 1. Introduction This document defines frame relay pseudo-wire (PW) specific aspects. A frame relay PW allows frame relay protocol control information and payload to be carried over Packet Switched Networks (PSNs) using IP, L2TP, GRE or MPLS for transport. A frame relay-pseudo wire is a mechanism that emulates the essential attributes of frame relay service over a PSN. The required functions of frame relay PWs include - Encapsulating frame relay specific information receives at an ingress port of a Provider Edge (PE) device, - Carrying them across a PSN for delivery to another PE device, - Extracting or decapsulating frame relay specific information, - Generating of native frame relay frames for forwarding through an egress port and, - Performing any other operations required to support frame relay service. Kawa/Malis/Pate/Bhat/Vasavada [Page 2] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. Below are the definitions for the terms used throughout the document. Packet Switched Network: A Packet Switched Network (PSN) is a network using IP, MPLS or L2TP as the unit of switching. Pseudo Wire Emulation Edge to Edge: Pseudo Wire Emulation Edge to Edge (PWE3) is a mechanism that emulates the essential attributes of a service (such as a T1 leased line or Frame Relay) over a PSN. Customer Edge: A Customer Edge (CE) is a device where one end of an emulated service originates and terminates. The CE is not aware that it is using an emulated service rather than a "real" service. Provider Edge: A Provider Edge (PE) is a device that provides PWE3 to a CE. Pseudo Wire: A Pseudo Wire (PW) is a connection between two PEs carried over a PSN. The PE provides the adaptation between the CE and the PW. PW End Service: A Pseudo Wire End Service (PWES) is the interface between a PE and a CE. This can be a physical interface like a T1 or Ethernet, or a virtual interface like a VC or VLAN. Pseudo Wire PDU: A Pseudo Wire PDU is a PDU sent on the PW that contains all of the data and control information necessary to provide the desired service. PSN Tunnel: A PSN Tunnel is a tunnel inside which multiple PWs can be nested so that they are transparent to core network devices. Kawa/Malis/Pate/Bhat/Vasavada [Page 3] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 3. Acronyms and Abbreviations CE Customer Edge FR Frame relay FRoPW Frame Relay over Pseudo Wire LSP Label switched path LSR Label switching router MPLS Multi-protocol label switching MTU Maximum Transfer Unit NNI Network-Network Interface PE Provider Edge PSN Packet Switched Network PW Pseudo-wire POS Packet over Sonet/SDH PVC Permanent virtual circuit SPVC Switched/Soft permanent virtual circuit SVC Switched virtual circuit UNI User-Network Interface VC Virtual circuit 4. Requirements for Frame Relay Over Pseudo-Wire Emulation Edge to edge The section lists the main frame relay pseudo-wires requirements to be met between two PEs: 1. Frame Transport: It must be possible to carry between two PEs both user and maintenance PSN traffic on the same pseudo-wire. It should be possible also to distinguish between the two types of traffic. 2. Frame Length: Must transport variable length frame relay frames without being limited by the PSN MTU. 3. Bi-directional traffic: Must support bi-directional traffic. 4. Frame ordering: Must preserve frame relay frames order. 5. Control bits: Must support the transport of frame Discard Eligibility (DE), Forward Explicit Congestion Notification (FECN), Backward Explicit Congestion Notification (BECN) and Command/Response (C/R) bits [Q922] 6. PVC Status Maintenance: Must support the mapping and transport of frame relay PVC status indications defined in Q933 Annex A [Q933]. The support of PVC continuity check should be provided. 7. Traffic Management: Should be able to map the following frame relay traffic management parameters to PWs traffic parameters: a) CIR (Committed Information Rate) or throughput, b) Bc (Committed burst size), c) Be (Excess Burst Size), e) Maximum frame size. Kawa/Malis/Pate/Bhat/Vasavada [Page 4] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 8. Frame Priority and QoS: Should support the ability to map different frame relay priorities or QoS classes as defined in [X36, X76] [X36, X76] to appropriately engineered PWs and tunnel PSNs. 9. Frame relay VC type: Must support PVC, support of SVC and SPVC is optional. 5. Reference model Figure 1 shows PWE3 reference model with additional frame relay concepts. This section will be completed with additional details imported from [PWE3REQ and PWE3FW]. (To be completed) |<------- Pseudo Wire ------>| | | | |<-- PSN Tunnel -->| | PW V V V V PW End Service +----+ +----+ End Service (FR UNI or NNI)| | | | (FR UNI or NNI) +-----+ | | PE1|==================| PE2| | +-----+ | |----------|............PW1.............|----------| | | CE1 | | | | | | | | CE2 | | |----------|............PW2.............|----------| | +-----+ | | |==================| | | +-----+ ^ +----+ +----+ | ^ | Provider Edge 1 Provider Edge 2 | | | |<------------- Emulated Service ----------------->| (i.e. FR PVC, SVC or SPVC) Customer Customer Edge 1 Edge 2 Figure 1 - PWE3 Reference Model 6. General Encapsulation and FRoPW packet processing 6.1. General Encapsulation The general packet format to transmit frame relay information (user's payload and frame relay control information) from one PE to another is shown in Figure 2. Kawa/Malis/Pate/Bhat/Vasavada [Page 5] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 +-------------------------------+ | | | Delivery Header | | | +-------------------------------+ | | | FRoPW Header | | | +-------------------------------+ | | | Payload packet | | | +-------------------------------+ Figure 2 - General format of FRoPW packet The delivery header is a header specific to the PSN, it is discussed in the following sections addressing each type of PSN. FRoPW header contains protocol control information, its structure is shown in Figure 3. The packet payload field is the content of the information field of frame relay frame defined in ITU-T Recommendation Q.922 Annex A [Q922]. FRoPW header structure is shown in Figure 3. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Res |P|F|B|D|C|X|Y| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3 - FRoPW header structure The meaning of the fields is as follows: Res (bits 0 to 2): Reserved bits. They are set to zero on transmission and ignored on reception. P - Payload Type (bit 3): If set to zero then the payload field contains user's data else it contains network maintenance data. F - FECN (bit 4): FR FECN (Forward Explicit Congestion Notification) bit [Q922]. B - BECN (bit 5): FR BECN (Backward Explicit Congestion Notification) bit [Q.922]. D - DE (bit 6) FR DE bit indicates the discard eligibility [Q922]. Kawa/Malis/Pate/Bhat/Vasavada [Page 6] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 C/R (bit 7) FR frame C/R (command/response) bit [Q922]. X, Y (bits 8 and 9): 1 0: First segment of a segmented FRoPW packet 0 1: Last segment of a segmented FRoPW packet 0 0: Neither the first nor the last segment of a segmented FRoPW packet 1 1: Complete FRoPW packet X and Y bits are used for segmentation and re-assembly of FroPW packet fragments when these capabilities are enabled in the two PEs terminating a PW. Length (bits 10 to 15): The length field is used to pad short FRoPW packets over Ethernet PSN. The length field is used as follows: If the length of the layer 2 frame (consisting of layer two control information and layer 2 payload) is less than 64 bytes, the length field MUST be set to the FRoPW packet length. Otherwise the length field MUST be set to zero. The value of the length field, if non-zero, is used to remove any padding. Sequence number (Bit 16 to 31): If not used it is set to zero by the sender and ignored by the receiver. Otherwise it specifies the sequence number of a complete FRoPW packet or a fragment. A circular list of sequence numbers is used. A sequence number takes a value from 1 to 65535 (2**16-1). Arithmetic modulo 2**16 is used to generate a new sequence number. The sequence number must be used when segmentation and re-assembly are enabled between two peer PEs terminating a PSN tunnel. The sequence number may be used to detect out-of-order delivery of FRoPW packets when the PSN does not guarantee in-order delivery. 6.2. FRoPW packet processing (Section and subsections to be completed) 6.2.1. Generating FRoPW packets The generation process of a FRoPW packet is initiated when a PE receives a frame relay frame from one of its frame relay UNI or NNI. The PE takes the following actions (not necessarily in the order shown): - It generates the following fields of FRoPW header from the corresponding fields of the frame relay frame: C/R, DE, FECN and BECN, - The length field will be addressed in the next iteration of this draft. - The sequence field is set according to the configuration parameters. Details are provided below. Kawa/Malis/Pate/Bhat/Vasavada [Page 7] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 - The payload field is the contents of the frame relay information field stripped from any escape bit or character. Once the FRoPW packet has been generated, additional processing specific to the type of PW used and the underlying PSN is performed. 6.2.1.1. Setting the sequence number If the two PEs terminating a PSN tunnel support packet sequencing capability then the following procedure to number FRoPW packets is used: - The initial packet transmitted on the frame relay PW MUST use sequence number 1, - For a subsequent packet, the sequence number corresponds to the sequence number of the preceding packet incremented by 1 modulo 2**16, - when the sequence number reaches the maximum 16 bit value (65535) the next sequence number wrap to 1. If the PEs do not support sequence number processing, then the sequence number field MUST be set to 0. 6.2.1.2. Sequence number and segmentation of long FRoPW packets (To be completed) 6.2.2. Receiving FRoPW packets (Section and subsections to be completed) When a PE receives a FRoPW packet, it processes the different FRoPW header fields in order to synthesize a new frame relay frame for transmission through one of its frame relay UNI or NNI. The PE performs the following actions(not necessarily in the order shown): Note - PSN and PW specific processing are specified in the section on each type of PSN. - The PE checks the P bit to ensure that it is set to "user's data", - It generates the following frame relay frame fields from the FRoPW header: C/R, DE, FECN and BECN, - It processes the length and sequence field, - It generates the frame relay information field from the contents of the FRoPW packet payload. Once the frame relay frame has been generated, it is queued for transmission across the selected frame relay UNI or NNI. Kawa/Malis/Pate/Bhat/Vasavada [Page 8] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 6.2.2.1 Checking the sequence number If the receiving PE support packet sequencing, the processing is done as follows: The "expected sequence number" of the first FRoPW packet is 1. When a packet is received the sequence number is processed as follows: - If the sequence number of the packet is 0, then the packet passes the sequence number check - Otherwise if the packet sequence number >= the expected sequence number and the packet sequence number - the expected sequence number < 32768, then the packet is in order. - Otherwise if the packet sequence number < the expected sequence number and the expected sequence number - the packet sequence number >= 32768, then the packet is in order. - Otherwise the packet is out of order. If a packet passes the sequence number check, it is kept for further processing in order to be forwarded to its next destination. If the packet is in order, then the expected sequence number should be set using the following assignment: expected_sequence_number := packet_sequence_number + 1 mod 2**16 if (expected_sequence_number = 0) then expected_sequence_number := 1; Packets, which are received out of order, MAY be dropped or reordered at the discretion of the receiver. If the receiving PE does not support sequence number processing, then the sequence number field MAY be ignored. 6.2.2.2 Sequence number and segmentation of long FRoPW packets (To be completed) 6.3. Segmentation and Re-assembly procedures (Section and subsections to be completed) 6.3.1. Segmentation procedure Segmentation is performed when the information field of the frame relay frame received is too long for transmission across the PSN and when the configuration of the PSN tunnel and/or PW allows segmentation to be performed. X and Y bits are used to indicate the type of segment: First Kawa/Malis/Pate/Bhat/Vasavada [Page 9] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 segment (X bit set to 1), last segment (Y bit set to 1) neither the first not the last segment (X and Y bits set to 0). The sequence number is used to number the fragments. If packet sequencing is used for every packet, numbering FRoPW packet fragments follows the same procedure as numbering complete packets: For every packet fragment, the sequence number is the sequence number of the previous packet/fragment incremented by one modulo 2**16. When packet sequencing is not used for every packet but only with segmentation and re-assembly, the sequence number of is re-initialized for every long packet that requires segmentation. The first FRoPW packet fragment has sequence number and for each subsequent fragment, the sequence number is incremented by 1 modulo 2**16. If segmentation is not allowed and the frame relay frame is too long for transmission in a single FRoPW packet, it shall be discarded. (Detailed procedures will be provided in the next version of this draft} 6.3.2. Re-assembly procedure When a frame relay frame has been segmented by the sending PE and segmentation/re-assembly is allowed by the receiving PE, the receiving PE will re-assemble the frame relay segments received in FRoPW packets to regenerate the original frame relay information field. (Detailed procedures will be provided in the next version of this draft} 6.4. Handling of error conditions To be completed. 6.5. FR SVC and SPVC Signalling between PEs To be completed 6.6. FR PVC provisioning Provisioning of frame relay VCs requires the following actions: Frame relay VC segments (see Figure 1) are provisioned between each CE and the corresponding PE. A FR PW is established between the two PEs to complete the Frame Relay VC. The two PEs terminating a frame relay PW executed a PVC maintenance protocol to exchange PVC status information and for "keep-alive" purposes. The PVC maintenance protocol is defined in the following section. 7. PVC maintenance protocol This section specifies how the status of a PVC is reported between two PEs when a PVC is created, deleted or when it changes state and how and when the keep alive function is performed. Kawa/Malis/Pate/Bhat/Vasavada [Page 10] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 7.1. PVC maintenance message format PEs use a PVC maintenance protocol to exchange PVC status and keep-alive information. The message format of the PVC maintenance protocol is shown in Figure 4 and the explanation of the different fields follows. A PVC maintenance message is encapsulated in the payload field of FR-MPLS/PW packet with the P bit set to "network data". A PE sends a PVC maintenance protocol message in its transmitting PSN tunnel. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | V=0001| Message type |State | MSN | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4 - PVC maintenance message format Meaning of each field: Bits 0 to 3: Version number (V) The version number of the PVC maintenance protocol. This version is version 0001. Bits 4 to 11: Message type This field identifies a PVC maintenance protocol message. The following messages are defined: 0000 0000: PVC status indication 0000 0001: PVC status response 0000 0010: Keep alive indication 0000 0011: Keep alive response Other values are reserved for future use. Bits 12 to 15: PVC state This field indicates the operational state of a PVC as follows: A (active) bit This bit indicates whether the PVC is active (value 1) or inactive (value 0). N (new) bit This bit indicates whether the status reporting is for a new PVC (value 1) or an existing PVC (value 0). D (delete) bit This bit indicates that a PVC will be deleted when it is set to 1. D bit set to 0 is used with other PVC status announcement. Bits 16 to 23: Message correlation number (MSN) This field allows the correlation of a PVC status indication message with the corresponding PVC status response or a keep alive indication message with the corresponding keep-alive response message. Kawa/Malis/Pate/Bhat/Vasavada [Page 11] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 Note on the use of the Message correlation number field: The field value is an integer between 0 and 255. A simple way to generate Message correlation numbers is to use a counter modulo 256 per frame relay PW. Before transmitting a new PVC status /keep-alive indication message, a PE inserts a new value of the counter in the Message correlation number field. A receiving PE returns in a PVC status /keep-alive response message the value of the message correlation number received in the corresponding PVC status/keep-alive indication message. Bits 24 to 31: Reserved These bits are reserved for future use. 7.2. Execution of PVC maintenance protocol PVC maintenance functions may be executed to report a PVC state change or for keep-alive purposes in the absence of user's traffic. Each side of a related pair of PSN tunnel has a timer T1 to indicate when PVC maintenance protocol functions are executed. However, any time before T1 expires a PE may send a PVC status indication message to inform the other side of a PVC state change in a timely manner. But keep-alive functions are executed only when T1 expires. Note timer T1 applies to a pair of bi-directional PSN tunnel and not to individual nested frame relay PW. 7.3. Notification of a newly created PVC A PE shall send a PVC status indication message to notify its peer that a PVC has been created. The N bit is set to 1 (new PVC). If the PE is ready to send and receive user's frames it shall set the A bit to 1 (active) otherwise it shall set it to 0. The PE shall insert a Message correlation number as described in Section 7.1. The other fields are set as shown in Figure 1 and decribed in Section 7.1. If the PE does not receive a reply when timer T1 expires it shall retransmit the PVC status message with the N bit set to 0 (new) and the A bit set according to the availability of the PVC with a new Message correlation number. At any time there is only one outstanding PVC status indication message per frame relay PW. The PVC status message may be retransmitted up to N1 time (the default value of N1 is 255 retransmissions) but only after T1 expires. After N1 retransmissions the management system is notifies of the lack of reply and the PE may continue with the retransmission of the PVC status indication message until further notification by the management system. When a PVC status response message is received, the PE receiving the PVC status response message checks the various fields to ensure that they are correct. In particular, the Message correlation number must correspond to the Message correlation number of a the last transmitted PVC status indication message awaiting a reply, otherwise the PVC status reply message is silently discarded. The receiver checks also the N bit and A bit. The N bit must be set to 1 Kawa/Malis/Pate/Bhat/Vasavada [Page 12] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 (new PVC) otherwise the management system must be notified and the PVC must be unavailable for use until further notification by the management system. If the A bit is set to 0 (inactive) no user frames may be transmitted or received. If the A bit is set to 1 (active) transmission of user frame is allowed only if the PVC is active at this side too. Transmission in the two directions is allowed only when the PVC is active at the two ends of the VC LSPs. Any user's frame received when the PVC is not active at the two PEs shall be discarded. 7.4. Replying to the notification of a newly created PVC When a PE receives from its peer a PVC status indication message indicating that a PVC has been created, it shall reply by returning a PVC status response message as follows: 1. If the PVC has been created at this side, the N bit shall be set to 1 2. (new PVC). 3. If the A bit received in the PVC status indication message was set to 1 (active) and the PVC has been activated at this side, the A bit shall be set to 1 otherwise it shall be set to zero (inactive). 7.5. Notification of PVC activation A PE shall send a PVC status indication message to notify its peer that a PVC is active at its side and ready to send and receive user's data. The PE shall set the N bit to 0 (existing PVC) and the A bit to 1 (active). The other fields are set as explained in Section 7.1. If the PE does not receive a reply when timer T1 expires it shall retransmit the PVC status message with the N bit set to 0 and the A bit set to according to the activation state of the PVC at this side. The PVC status message may be retransmitted up to N1 time. After N1 retransmission the management system is notifies of the lack of a reply and the PE may continue to retransmit the PVC status message to notify the other side that the PVC is active until further notification by the management system. When a reply is received indicating that the PVC is active, user frames may be sent in both directions. Otherwise, any user's frame received it will be discarded. 7.6. Replying to the notification of PVC availability When a PE receives from its peer a PVC status indication message indicating that a PVC is available (active), it shall reply by returning a PVC status response message as follows: 1. If the PVC has been created at this side and is active, the N bit Kawa/Malis/Pate/Bhat/Vasavada [Page 13] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 shall be set to 0 and the A bit to 1 (active) 2. If the PVC has been created and is not active it shall set the N bit to 0 and the A bit to 0 (inactive). If the identification of the frame relay PW does not correspond to a configured PVC, the PVC status indication message received is discarded and no reply is returned. 7.7. Notification of PVC de-activation A PE shall send a PVC status indication message to notify its peer that a PVC is inactive at its side. The PE shall set the N bit to 0 (existing PVC) and the A bit to 0 (inactive). The other fields are described in Section 7.1. If the PE does not receive a reply when timer T1 expires it shall consider the PVC inactive and any user's frame received shall be discarded. The PVC status message is retransmitted up to N1 time. After N1 retransmissions the management system is notified of a lack of a reply. If a user frame is received when a PVC is inactive, it shall be discarded and the PE may retransmit the PVC status message to notify the other side that the PVC is inactive When a reply is received indicating that the PVC is inactive, user frames must not be sent in any direction until the PVC has been activated at the two sides. Any user's frame received when the PVC is received will be discarded and the receiving side may return a PVC status message indicating that the PVC is still inactive. 7.8. Replying to the notification of PVC de-activation When a PE receives from its peer a PVC status indication message indicating that a PVC is unavailable (inactive), if the PVC is configured, it shall reply by returning a PVC status message with the N bit set to 0 and the A bit to 0 (inactive). If the identification of the frame relay PW does not correspond to a configured PVC, the PVC status indication message received is discarded and no reply is returned. No user's frames may be sent when the PVC is inactive. Any user's frame received is discarded. 7.9. PVC status checking At the expiration of timer T1 a PE may send a PVC status indication message to the other PE with the PVC state bits (D, N and A) set to appropriate values to elicit a response from the other PE about the PVC Kawa/Malis/Pate/Bhat/Vasavada [Page 14] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 state. This procedure is useful, for example, when a PVC has been de activated for too long and one of the PE wants to check the PVC state at the other side. 7.10. Notification of the deletion of a PVC When a PVC is in the process of being deleted, a PE notifies the other side by sending a PVC status indication message with the D bit set to 1, the N bit must be set to 0 (existing PVC) and the A bit to 0 (inactive). One or both sides may initiate the PVC deletion notification procedure. When both sides initiate the procedure, each side must reply to the PVC status indication message sent by the other side. If no reply is received, the PVC status indication message may be retransmitted up to N3 times. After N3 retransmissions the management system is notified of a lack of a reply and the PVC is considered deleted. When the PE receives a PVC status response message replying to the notification of the deletion of a PVC, it shall ensure that the Message correlation number is valid and the D bit received is set to 1, otherwise it shall discard the PVC status response message. If the message received is correct and after performing any other book-keeping function at this side, the PVC is considered deleted at this side. 7.11. Reply to the notification of the deletion of a PVC When a PE receives from its peer a PVC status indication message indicating that a PVC is in the process of being deleted, it shall return a PVC status response message with the D bit set to 1, the N bit set to 0 and the A bit to 0. The other fields are set according to Figure 1 and Table 1. After sending the PVC status response message and after performing any other book-keeping function, the PVC shall be considered deleted at this side. 7.12. Keep-alive function The keep-alive procedure is optional to implement, it is performed for each frame relay PW in the absence of user's or PVC status reporting traffic in one or both directions and does not induce a PVC state change in a PE. It merely allows a PE to inform the other PE that it is functioning. The keep alive procedure is executed by the PEs when timer T1 expires. A PE does not have to execute the keep-alive procedure every time timer T1 expires, in particular under heavy load or for any other reason. 7.12.1. Sending a keep alive request message A PE may initiate the keep-alive procedure when one of the following conditions is met: 1. There has not been any user's traffic in one or both directions and the PVC is in the active state when timer T1 expires, Kawa/Malis/Pate/Bhat/Vasavada [Page 15] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 2. There is no PVC status reporting message to send to the other PE applicable to the corresponding VC LSP, 3. For other implementation-specific reasons. When one of the above conditions is met, a PE initiates the execution of the keep-alive procedure by sending a keep-alive indication message to the other PE indicating the PVC state at its side. The PVC state bits are set according to the PVC state at the PE side. When a keep-alive response message is received. The PVC state bits are checked to determine if there is a state mismatch. When a state mismatch exists, the PE receiving he keep-alive response message shall execute the PVC status reporting procedures to bring the PVC to the same state at the two PEs. The PVC state bits are set to the lowest common denominator (detailed will be provided in the next version). The PE shall take no special action if no reply to the keep-alive indication message is received at or before the next expiration of timer T1. However if there is no activity on the frame relay PWs in the transmitting and receiving directions after N2 retransmissions of the keep-alive indication message and no reply to the keep-alive indication message has been received, the network management system shall be informed. The PE may continue executing the PVC maintenance protocol until it receives a notification from the management system. 7.12.2. Replying to a keep alive indication message When a PE receives a keep-alive indication message it returns a keep- alive response indicating the state of the PVC at its side, if the PVC state at its side is consistent with the PVC state received in the keep- alive indication message. If the PVC state is inconsistent the PE shall execute the PVC status reporting procedure without returning the keep- alive response message in order to bring the PVC in the same state at the two sides. The PVC state bits are set to the lowest common denominator (details will be provided in the next version). 7.13. Resumption of PVC activities after a failure After a failure (link layer, transmission facility or internal failure) a PE shall execute the PVC status activation to return the PVC to the active state between the two PEs. 7.14. Handling of error conditions As a general rule, if a PVC receives a PVC maintenance message with erroneous information, it shall discard it. In particular: 1. If a PE receives an unexpected PVC maintenance message, 2. If a PE received a PVC maintenance message with a content not as specified in Section 7.1, Kawa/Malis/Pate/Bhat/Vasavada [Page 16] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 3. If a PE receives a PVC maintenance message with the N bit set to 0 (existing PVC) and a frame relay PW identification not recognized as belonging to a configured PVC, 4. If a PE receives a PVC maintenance status response message with an invalid Message correlation number. 7.15. PVC maintenance protocol Parameters Timers: Timer T1 - This timer exists at each peer PE for a pair of bi- directional. tunnel LSP. It controls the periodical execution of the PVC maintenance protocol. The default value of timer T1 is 1 second. Counter Thresholds: N1: This threshold is the maximum number of retransmissions of PVC status indication before informing the management system of any problem. The default value is 255 retransmissions. N2: This threshold is the maximum number of retransmissions of the PVC keep-alive indication message before informing the management system of any problem. The default value is 255 retransmissions. N3: This threshold is the maximum number of retransmissions of the PVC status indication message with the D bit set to 1 (PVC to be deleted) before considering the PVC to be deleted and before informing the management system The default value is 15 retransmissions. 8. Configuration prerequisites Since frame relay VCs are bi-directional and carry traffic in the two opposite directions, at least one pair of tunnel PSN must be available between two PEs with appropriate traffic and QoS capabilities before they can start sending FRoPW packets. Some PSN tunnels require to be created and maintained, other do not. Establishing, maintaining and releasing PSN tunnel are outside the scope of this document. Binding between a pair of frame relay interfaces/DLCI and a PW is done when the PW and FR VC segments are created. In addition a PE must be configured with the following parameters per tunnel PSN. These parameters will apply to all Frame Relay PWs nested inside the tunnel PSN: 1. Maximum transfer unit (MTU) of the PSN, 2. Whether segmentation and re-assembly will be supported or not, 3. Use of the sequence number: With segmentation only, always or never, 4. Additional configuration parameters specific to each PW and PSN are listed in the section covering each PSN. Kawa/Malis/Pate/Bhat/Vasavada [Page 17] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 9. Frame Relay over MPLS 9.1. MPLS tunnel and VC LSPs MPLS label switched paths (LSPs) called "Tunnel LSPs" establish an association between a pair of PEs. A tunnel LSP correspond to a "PSN tunnel" of Figure 1. Several "Virtual Circuit LSPs" (VC LSPs) may be nested inside one Tunnel LSP. Each VC LSP carries the traffic of a frame relay PVC or SVC in one direction. Since LSPs are uni-directional, a pair of VC LSPs (and corresponding tunnel LSPs) carrying traffic in opposite directions will be required usually for each frame relay PVC or SVC. 9.2. Relationship between FR VCs and MPLS VC LSPs Frame Relay VCs are considered to be bi-directional objects mainly because of the way they are created and identified. A single frame relay identifier (DLCI) refers to the two directions of a frame relay VC and frame relay signalling establishes the two directions simultaneously with the same message flows. In general each direction of a frame relay VC may have different traffic and QoS characteristics. The resource management of a frame relay implementation treats each direction separately and independently. MPLS LSPs, on the other hand are uni- directional and are established separately. In the case of frame relay over MPLS, during the creation of a frame relay VC, a pair of VC LSPs will have to be established between two PEs. For one end-to-end frame relay VC two VC LSPs exists: One VC LSP to transport the traffic from PE1 to PE2 and another one to transport the traffic in the opposite direction. The VC LSP in each direction must comply with the characteristics of the corresponding direction of the frame relay VC. The VC LSP from PE1 to PE2 is the transmit VC LSP for PE1 and the receive LSP for PE2. Likewise, the VC LSP from PE2 to PE1 is the transmit LSP for PE2 and the receive LSP for PE1. In the frame relay domain, a DLCI identifies a frame relay VC and in the MPLS domain, VC LSP labels with possibly different values identify the pair of VC LSPs, one label value for each LSP. In PE1 to PE2 direction a tunnel LSP gets MPLS packets from PE1 to PE2, the corresponding label is not related to any frame relay VC. When PE1 sends a FRoPW packet to PE2, it first pushes a VC label on its label stack, and then pushes on a tunnel LSP label. The VC label is not visible until the FRoPW packet reaches PE2. PE2 forwards FRoPW packet based on the LSP VC label. The VC label must be always at the bottom of the label stack. While the packet is transported across the MPLS network, additional labels may be pushed on (and then popped off) as needed. The processing is similar in the opposite direction from PE2 to PE1. Kawa/Malis/Pate/Bhat/Vasavada [Page 18] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 9.3. Frame relay over MPLS packet format In the case of frame relay over MPLS, the generic FroPW packet format of Figure 2 becomes as shown in Figure 5. +-------------------------------+ | Tunnel LSP label(s) | n words (4n bytes per label) +-------------------------------+ | VC LSP label | 1 word +-------------------------------+ | FRoPW Header | | (See Figure 3) | 1 word +-------------------------------+ | Payload packet | |(Q.922 frame information field)| Maximum N bytes | | (to be specified) +-------------------------------+ Figure 5 - Frame relay over MPLS packet format (Section to be completed} 10. Frame Relay over IP {Section and subsections to be completed) Note both IP v4 and IP v6 are supported. 10.1. General aspects of frame relay over IP 10.2 Frame relay over IP packet format For frame relay over IP v4 or v6, the packet format is shown in Figure 6. +-------------------------------+ | IP v4 or v6 header | n words +-------------------------------+ | Frame relay PW | | identifier (See Figure 7) | 1 word +-------------------------------+ | FRoPW Header | | (See Figure 3) | 1 word +-------------------------------+ | Payload packet | |(Q.922 frame information field)| Maximum N bytes | | (to be specified) +-------------------------------+ Figure 6 - Frame relay over IP packet format Kawa/Malis/Pate/Bhat/Vasavada [Page 19] Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 Frame relay PW identifier field shown in Figure 6 is used to identify a frame relay VC between two PEs in the case of frame relay over IP. The format of this field is shown in Figure 7. Actually the format is similar to MPLS LSP label format. This format allows to have one size for identifying a frame relay VC between two PEs, instead of having two formats as allowed in FRF.1.2 and FRF.2.2 (see [Q922, FRF1 and FRF2]). The use of the other fields will be described in a subsequent version of this draft. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FR PW Identifier | Exp |0| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Identifier: Frame relay PW identifier, 20 bits Exp: Experimental Use, 3 bits TTL: Time to Live, 8 bits Figure 7 - frame relay PW identifier for frame relay over IP 10.3. Frame relay over IP specific packet processing (To be completed). 10.4. Additional configuration objects for frame relay over IP (To be completed). 11. Frame Relay over GRE (Section and subsections to be completed). 11.1. General aspects of frame relay over GRE 11.2. Frame relay over GRE packet format For frame relay over GRE [RFC2784, RFC2890], the packet format is similar to frame relay over IP packet format shown in Figure 6, except that there is one or more additional GRE header(s) as shown in Figure 8. Kawa/Malis/Pate/Bhat/Vasavada [Page 20] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 +-------------------------------+ | IP v4 or v6 header | n words +-------------------------------+ | Frame relay PW | | identifier (See Figure 7) | 1 word +-------------------------------+ | GRE header(s) | m words (m >=1) | | +-------------------------------+ | FRoPW Header | | (See Figure 3) | 1 word +-------------------------------+ | Payload packet | |(Q.922 frame information field)| Maximum N bytes | | (to be specified) +-------------------------------+ Figure 8 - Frame relay over GRE packet format 11.3. Frame relay over GRE specific packet processing 11.4. Additional configuration objects for frame relay over GRE 12. Frame Relay over L2TP (To be completed). 13. Security Considerations (To be completed). 14. References [I233] ITU-T Recommendation I.233.1, ISDN frame relay bearer service, Geneva, October 1991 [FRF1] FRF.1.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, April 2000 [FRF2] FRF.2.2, Frame relay PVC UNI Implementation Agreement, Frame Relay Forum, 2001 [FRF4] FRF.4.1, Frame relay SVC UNI Implementation Agreement, Frame Relay Forum, January 2000 Kawa/Malis/Pate/Bhat/Vasavada [Page 21] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 [FRF10] FRF.10.1, Frame relay SVC NNI Implementation Agreement, Frame Relay Forum, January 2000 [PWE3REQ] XiPeng Xiao, et al., Internet draft, draft-ietf-pwe3- requirements-01.txt, July 2001 [PWE3FW] Prayson Pate, et al., Internet draft, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3) [Q922] ITU-T Recommendation Q.922, ISDN Data Link Layer Specification for Frame Mode Bearer Services, ITU, Geneva, 1992. [Q933] ITU-T Recommendation Q.933, ISDN Signaling Specification for Frame Mode Bearer Services, Geneva, October 1995. [RFC3032] E. Rosen, et al., RFC 3032 MPLS Label Stack encoding, January 2001. [RFC3031] E. Rosen, et al., RFC 3031 MPLS Architecture, January 2001. [RFC2615] A. G. Malis, RFC 2615 PPP over SONET/SDH, June 1999. [RFC2784] D. Farinacci, et. al, RFC 2784 Generic routing encapsulation, March 2000 [RFC2890] G. Dommety, RFC 2890 Key and sequence number extensions to GRE, September 2000 [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 15. Acknowledgements To be completed. 16. Author's Addresses Claude Kawa Nortel Networks 3500 Carling Ave. Ottawa, Ontario, Canada email: kawa@nortelnetworks.com Kawa/Malis/Pate/Bhat/Vasavada [Page 22] Internet Draft draft-kamapabhava-fr-pwe3-00.txt September 2001 Andrew G. Malis Vivace Networks, Inc. 2730 Orchard Parkway San Jose, CA 95134 e-mail: Andy.Malis@vivacenetworks.com Prayson Pate Overture Networks P. O. Box 14864 RTP, NC, USA 27709 email: prayson.pate@overturenetworks.com Ravi Bhat Amber Networks 50 Vanivalas Road Bangalore 560 004 India email: rbhat@ambernetworks.com Nishit Vasavada Amber Networks
email: nishit@ambernetworks.com Kawa/Malis/Pate/Bhat/Vasavada [Page 23]