PWE3 Working Group Yaakov (Jonathan) Stein Internet Draft RAD Data Communications draft-stein-pwe3-stpp-00.txt Expires: December 2003 Amnon Ilan MRV Communications June 2003 Simple TDM Pseudowire Protocol draft-stein-pwe3-stpp-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. [PAGE 1] Simple TDM Pseudowire Protocol June 2003 Abstract This document describe a simple method for transporting time division multiplexed (TDM) digital voice and data signals over Pseudowires. 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. Table of Contents 1. Introduction .................................................2 2. STPP Encapsulation ...........................................3 3. Encapsulation Details for Specific PSNs ......................4 4. STPP Payload .................................................7 5. Implementation Issues ........................................8 6. Security Considerations ......................................9 7. IANA Considerations .........................................10 8. References ..................................................10 9. Acknowledgments .............................................10 10. Contact Information ........................................11 1. Introduction In this document we describe a simple protocol for tunneling synchronous data through packet switched networks (PSNs) using pseudowires (PWs) [PWE3-ARCH]. In particular, the protocol herein described may be used to transport T1, E1, T3, and E3 TDM traffic, but completely disregards any structure that may exist in these signals. Due to its simplicity, this protocol can be seen as the common denominator of all low-rate TDM PW techniques proposed to date. Its basic unit is the TDM bit, rather than frames or AAL1 cells. Because of its simplicity, STPP is not universally applicable, and more sophisticated transport methods will be required especially under conditions of nontrivial network impairments. In particular, STPP is most suitable for networks where packet loss and packet delay variation are expected to be very low. The protocol as herein described is agnostic to the underlying PSN, which may be UDP over IPv4 or IPv6, MPLS, or L2TPv3. Implementation specifics for particular PSNs are discussed in section 3. Stein et al. [PAGE 2] Simple TDM Pseudowire Protocol June 2003 2. STPP Encapsulation 2.1 Layering Model The protocol-layering model used by STPP is shown in the figure, where the order is that of the physical packet, so that higher layers appear lower in the diagram. +---------------------------+ | PSN-specific headers | +---------------------------+ | control word | +---------------------------+ | payload | +---------------------------+ 2.2 PSN-specific header The PSN-specific layers contain all necessary infrastructure, and may consist of UDP/IP, MPLS, L2TPv3 over IP, or layer 2 Ethernet. The PSN is assumed to be reliable enough and of sufficient bandwidth to enable transport of the required TDM data. STPP edge devices may handle more than one circuit bundle at a time. A circuit bundle is defined as a stream of bits that have originated from a single physical interface or from interfaces that share a common clock, which are transmitted from a single source to a single destination. Circuit bundles are uni-direction streams, but are universally coupled with bundles in the opposite direction to form a bi-directional connection. If a STPP edge device is required to handle multiple circuit bundles, then it is the responsibility of the PSN-specific layers to provide a circuit bundle identifier (CBID) in order to enable differentiation between these circuits. These layers will be more fully discussed in section 3. 2.3 STPP Control Word The 32-bit control word MUST appear in every STPP packet. Its format is given in the following figure. 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 |L|R| RES | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Stein et al. [PAGE 3] Simple TDM Pseudowire Protocol June 2003 RES (4 bits) Reserved and MUST be set to zero L Local Loss of Sync failure (1 bit) The L bit being set indicates that the source has detected or has been informed of a TDM physical layer fault impacting the data to be transmitted. This bit can be used to indicate Physical layer LOS that should trigger AIS generation at the far end. When the L bit is set the contents of the packet may not be meaningful, and the payload size MAY be reduced in order to conserve bandwidth. Once set, if the TDM fault is rectified the L bit MUST be cleared. R Remote Receive failure (1 bit) The R bit being set indicates that the source is not receiving packets at its STPP receive port, indicating failure of that direction of the bi-directional connection. This indication can be used to signal congestion or other network related faults. Receiving remote failure indication MAY trigger fall-back mechanisms for congestion avoidance. The R bit MUST be set after a preconfigured number of consecutive packets are not received, and MUST be cleared once packets are once again received. Z (2 bits) These bits indicate an extended header format and MUST be set to zero. Length (6 bits) is used to indicate the length of the STPP packet (control word and payload), in case padding is employed to meet minimum transmission unit requirements of the PSN. It MUST be used if the total packet length (including PSN, control word, and payload) is less than 64 bytes, and SHOULD be set to zero otherwise. Sequence number (16 bits) The STPP sequence number is always present and enables detection of packet loss and misordering. In addition, since the basic clock rate for each circuit bundle is constant, the sequence number may be used as an approximate timestamp. The initial value of the sequence number SHOULD be random (unpredictable) for security purposes, and the value is incremented modulo 2^16 separately for each circuit bundle. 3. Encapsulation Details for Specific PSNs 3.1 UDP/IP For IPv4 the UDP/IP header as described in [UDP] and [IPv4] are prefixed to the STPP data. The STPP packet structure will then be as follows: Stein et al. [PAGE 4] Simple TDM Pseudowire Protocol June 2003 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPVER | IHL | IP TOS | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | IP Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Circuit Bundle ID | Destination UDP Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UDP Length | UDP Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| RES | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | STPP Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first five rows are the IP header, the sixth and seventh rows are the UDP header. Row 8 is the STPP control word. IPVER (4 bits) is the IP version number, for IPv4 IPVER=4. IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5. IP TOS (8 bits) is the IP type of service. Total Length (16 bits) is the length in octets of header and data. Identification (16 bits) is the IP fragmentation identification field. Flags (3 bits) are the IP control flags and MUST be set to Flags=010 to avoid fragmentation. Fragment Offset (13 bits) indicates where in the datagram the fragment belongs and is not used for STPP. Time to Live (8 bits) is the IP time to live field. Datagrams with zero in this field are to be discarded. Protocol (8 bits) MUST be set to 0x11 to signify UDP. IP Header Checksum (16 bits) is a checksum for the IP header. Stein et al. [PAGE 5] Simple TDM Pseudowire Protocol June 2003 Source IP Address (32 bits) is the IP address of the source. Destination IP Address (32 bits) is the IP address of the destination. Circuit Bundle ID (16 bits) distinguishes between multiple bundles arriving at the same destination. Bundle numbers in the range from 1 to 8063 are available for general use; 0 is invalid; port numbers above 8064 are reserved. Destination UDP Port (16 bits) will mark a packet as conforming to STPP. UDP Length (16 bits) is the length in octets of UDP header and data. UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If not computed it must be set to zero. 3.2 MPLS The MPLS header as described in [MPLS] is prefixed to the STPP data. The packet structure (as seen at the edges) is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Outer Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Inner Label = CBID | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| RES | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PAYLOAD | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The first two rows depicted above are the MPLS header; the third is the STPP control word. Outer Label (20 bits) is the MPLS label which identifies the MPLS LSP used to tunnel the TDM packets through the MPLS network. It is also known as the tunnel label or the transport label. The label number can be assigned either by manual provisioning or via the MPLS control protocol. While transiting the MPLS network there can be zero, one or more outer label rows. For label stack usage see [MPLS]. EXP (3 bits) experimental field S (1 bit) stacking bit where 1 indicates stack bottom S=0 for all outer labels TTL (8 bits) MPLS time to live Stein et al. [PAGE 6] Simple TDM Pseudowire Protocol June 2003 Inner Label (20 bits) the MPLS inner label (also known as the PW label or the interworking label), contains the circuit bundle identifier used to multiplex multiple circuit bundles within the same tunnel. Valid values are as in subsection 3.1 supra. Note that the inner label is always be at the bottom of the MPLS label stack, and hence its stacking bit is set. 3.3 L2TPv3 If L2TP is used over IPv4 without UDP the L2TPv3 header defined in [L2TPv3] is prefixed to the STPP data. 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 = CBID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie 1 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie 2 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| RES | Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | PAYLOAD | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Session ID (32 bits) is the locally significant L2TP session identifier, and contains the circuit bundle identifier used to multiplex multiple circuit bundles within the same tunnel. Valid values are as in subsection 3.1 supra. Cookie (32 or 64 bits) is an optional field that contains a randomly selected value that can be used to validate association of the received frame with the expected circuit bundle. 4. STPP Payload STPP payloads are simply contiguous segments of the TDM data. All packets in an STPP flow MUST contain the same number of payload bytes. By constraining the payload size to be a constant for a given flow, a certain resilience to packet loss is attained. When a packet is determined to have been lost, the egress edge device MUST send the proper amount of TDM data to the TDM interface. This ensures that the TDM timing will be maintained, although the TDM data will be corrupted. Stein et al. [PAGE 7] Simple TDM Pseudowire Protocol June 2003 Arbitrary constant length payloads MAY be placed as-is in the payload field, with no bit or byte alignment implied. Hence no TDM framer is required for use of STPP. Specific implementations MAY use TDM framers, and in particular perform bit alignment in order to ensure that the transmitted bytes are TDM bytes. Furthermore, implementations using framers MAY start packets on TDM frame boundaries, and even force packet payloads to contain a TDM frame or multiples thereof. In general the size of the STPP payload SHOULD be chosen in order taking delay and efficiency considerations into account. The larger the packet the lower the overhead and hence the higher the efficiency, although the delay will be increased. Hence in situations where delay is required to be minimized (e.g. when echo cancellation can not be employed) short payloads SHOULD be employed. In networks where bandwidth considerations are paramount, or large packets are advisable (e.g. multiuser wireless networks), large payloads SHOULD be chosen. However, payload lengths MUST NOT be chosen so large as to cause packet fragmentation to take place. Although STPP packets MAY contain any length payload agreed upon by the sides, every STPP implementation MUST be able to support the following payload sizes for the TDM signals of [G.702]. T1 193 bytes (8 consecutive TDM frame times) E1 128 bytes (4 consecutive TDM frame times) E3 537 bytes (1/8000 of the E3 rate) T3 699 bytes (1/8000 of the T3 rate) These bizarre default lengths were chosen to facilitate interoperability with implementations that are constrained to transport whole TDM frames. In cases where STPP may be required to interwork with AAL1 circuit emulation systems, multiples of 47 bytes SHOULD be used to facilitate this interworking. 5. Implementation Issues General requirements for transport of TDM over pseudo-wires are detailed in [TDM-REQ]. In the following subsections we review additional aspects essential to successful STPP implementation. 5.1 Quality of Service STPP does not provide mechanisms to ensure timely delivery or provide other quality-of-service guarantees; hence it is required that the lower-layer services do so. Layer 2 priority can be bestowed upon a STPP stream by using the VLAN priority field, MPLS priority can be provided by using EXP bits, and layer 3 priority Stein et al. [PAGE 8] Simple TDM Pseudowire Protocol June 2003 is controllable by using TOS. Switches and routers which the STPP stream must traverse should be configured to respect these priorities. 5.2 Timing Time synchronization is essential for the proper functioning of TDM networks. STPP makes no assurances of conformance to conventional TDM timing standards. It is expected that STPP implementations will use externally derived timing sources. Due to the "serial-bit-stream" nature of STPP payloads, STPP pseudowires are highly sensitive to TDM loss of synchronization conditions. 5.3 Packet Delay Variation, Packet Loss, and Packet Misordering In order to compensate for packet delay variation that exists in any IP network a jitter buffer MUST be provided. The length of this buffer SHOULD be configurable and MAY be dynamic (i.e. grow and shrink in length according to the statistics of the delay variation). In order to handle infrequent packet loss and misordering a packet order integrity mechanism MUST be provided. This mechanism MUST track the serial numbers of packets in the jitter buffer and MUST take appropriate action when faults are detected. When missing packet(s) are detected the mechanism MUST output interpolation packet(s) in order to retain TDM timing. Packets with incorrect serial numbers or other detectable header errors MAY be discarded. Packets arriving in incorrect order MAY be reordered. 6. Security Considerations STPP does not enhance or detract from the security performance of the underlying PSN, rather it relies upon the PSN's mechanisms for encryption, integrity, and authentication whenever required. STPP does not provide protection against malicious users utilizing snooping or packet injection during setup or operation. Circuit bundle identifiers SHOULD be selected in an unpredictable manner rather than sequentially or otherwise in order to deter session hijacking. When using L2TP randomly selected cookies MAY be used to validate circuit bundle origin. Sequence numbers SHOULD be randomly initialized in order to increase the difficulty of decrypting based on packet headers. Stein et al. [PAGE 9] Simple TDM Pseudowire Protocol June 2003 7. IANA Considerations A UDP protocol identifier will be required for the UDP destination port. Per [PWE3-IANA] a 15-bit PW type will be required for use with MPLS. 8. References Normative References [G702] ITU-T Recommendation G.702 (11/98) Digital Hierarchy bit rates [IPv4] RFC 791 (STD0005) Internet Protocol (IP) [L2TPv3] draft-ietf-l2tpext-l2tp-base-06.txt (01/03) Layer Two Tunneling Protocol (L2TPv3), J. Lau et al., work in progress [MPLS] RFC 3032 MPLS Label Stack encoding [PWE3-IANA] draft-ietf-pwe3-iana-allocation-01.txt (06/03), IANA Allocations for Pseudo Wire Edge to Edge Emulation, L. Martini and W.M. Townsley, work in progress [UDP] RFC 768 (STD0006) User Datagram Protocol (UDP) Informative References [PWE3-ARCH] draft-ietf-pwe3-arch-04.txt Stewart Bryant et al (06/06), PWE3 Architecture, work in progress [TDM-REQ] draft-riegel-pwe3-tdm-requirements-01.txt (02/03), Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks, M. Riegel et al., work in progress 9. Acknowledgments Y(J)S would like to thank Ronen Shashoua and Orly Nicklass of RAD Data Communications for valuable discussions. The authors would like to thank Alex Conta of TranSwitch for his contributions. Stein et al. [PAGE 10] Simple TDM Pseudowire Protocol June 2003 10. Contact Information Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel-Aviv 69719 ISRAEL Phone: +972 3 645-5389 Email: yaakov_s@rad.com Amnon Ilan MRV Communications PO BOX 614, Industrial Park, Yokneam 20692 ISRAEL Phone: +972 4 993-6210 Email: ailan@mrv.com Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." Stein et al. [PAGE 11]