Network Working Group A. Vainshtein (Axerra Networks) Y. Stein (RAD Data Communications) Internet Draft Expiration Date: Editors March 2004 September 2003 Structure-Agnostic TDM over Packet (SAToP) draft-ietf-pwe3-satop-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of RFC 2026. 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. Abstract This document describes a pseudowire encapsulation for TDM (T1, E1, T3, E3) bit-streams that disregards any structure that may be imposed on these streams, in particular the structure imposed by the standard TDM framing [G.704]. Co-Authors The following are co-authors of this document: Motty Anavi RAD Data Communications Tim Frost Zarlink Semiconductors Eduard Metz TNO Telecom Prayson Pate Overture Networks Akiva Sadovski Axerra Networks Israel Sasson Axerra Networks Ronen Shashoua RAD Data Communications Vainshtein & Stein Standards Track [Page 1] Structure-Agnostic TDM over Packet August 2003 TABLE OF CONTENTS 1. Introduction......................................................2 2. Terminology and Reference Models..................................3 2.1. Terminology...................................................3 2.2. Reference Models..............................................3 3. Emulated Services.................................................3 4. SAToP Encapsulation Layer.........................................4 4.1. SAToP Packet Format...........................................4 4.2. PSN and Multiplexing Layer Headers............................4 4.3. SAToP Header..................................................4 4.3.1. Usage and Structure of the Control Word...................5 4.3.2. Usage of RTP Header.......................................6 5. SAToP Payload Layer...............................................7 6. SAToP Operation...................................................8 6.1. Common Considerations.........................................8 6.2. IWF operation.................................................8 6.2.1. PSN-bound Direction.......................................8 6.2.2. CE-bound Direction........................................8 6.3. SAToP Defects.................................................9 6.4. SAToP PW Performance Monitoring..............................10 7. QoS Issues.......................................................11 8. Congestion Control...............................................11 9. Security Considerations..........................................11 10. Issues for Further Study........................................12 10.1. Use of SAToP for transport of "Octet-Aligned T1"............12 10.2. Limitation of SAToP for T3..................................12 11. Applicability Statement.........................................12 12. IANA Considerations.............................................13 13. Intellectual Property Disclaimer................................13 1. Introduction This document describes a method for encapsulating TDM bit-streams (T1, E1, T3, E3) as pseudo-wires over packet-switching networks (PSN). It addresses only structure-agnostic transport, i.e., the protocol completely disregards any structure that may possibly be imposed on these signals, in particular the structure imposed by standard TDM framing [G.704]. This emulation is referred to as "emulation of unstructured TDM circuits" in [PWE3-TDM-REQ] and suits applications where the PEs have no need to interpret TDM data or to participate in the TDM signaling. The SAToP solution presented in this document conforms to the PWE3 architecture described in [PWE3-ARCH] and satisfies both the relevant general requirements put forward in [PWE3-REQ] and specific requirements for unstructured TDM signals presented in [PWE3-TDM-REQ]. Vainshtein & Stein Expires March 2004 [Page 2] Structure-Agnostic TDM over Packet August 2003 2. Terminology and Reference Models 2.1. Terminology "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. In addition to terms defined in [PWE3-ARCH], the following TDM specific terms are needed: o Loss of Signal (LOS) - a condition of the TDM attachment circuit wherein the incoming signal cannot be detected. Criteria for entering and leaving the LOS condition can be found in [G.775] o Alarm Indication Signal (AIS) - a special bit pattern (e.g. as described in [G.775]) in the TDM bit stream that indicates presence of an upstream circuit outage. For E1, T1 and E3 circuits the AIS pattern is a sequence of binary "1" values of appropriate duration (the "all ones" pattern). 2.2. Reference Models The generic models defined in Sections 4.1, 4.2 and 4.4 of [PWE3-ARCH] fully apply to SAToP. The native service addressed in this document is a special case of the bit stream payload type defined in Section 3.3.3 of [PWE3-ARCH]. The Network Synchronization reference model and deployment scenarios for emulation of TDM services are described in [PWE3-TDM-REQ], Section 4.2. 3. Emulated Services This specification describes edge-to-edge emulation of the following TDM services described in [G.702]: 1. E1 (2048 kbit/s) 2. T1 (1544 kbit/s) This service is also known as DS1 3. E3 (34368 kbit/s) 4. T3 (44736 kbit/s) This service is also known as DS3. The protocol used for emulation of these services does not depend on the method in which attachment circuits are delivered to the PEs. For example, a T1 attachment circuit is treated in the same way regardless of whether it is delivered to the PE on copper [G.703], multiplexed in a T3 circuit [T.107], mapped into a virtual tributary of a SONET/SDH circuit [G.707] or carried over an ATM network using unstructured ATM- CES [ATM-CES]. Termination of any specific "carrier layers" used between the PE and CE is performed by an appropriate NSP. Vainshtein & Stein Expires March 2004 [Page 3] Structure-Agnostic TDM over Packet August 2003 4. SAToP Encapsulation Layer 4.1. SAToP Packet Format The basic format of SAToP packets is shown in Fig. 1 below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | PSN and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | ... | +-- --+ | SAToP Encapsulation Header | +-- --+ | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1. Basic SAToP Packet Format 4.2. PSN and Multiplexing Layer Headers The total size of a SAToP packet for a specific PW MUST NOT exceed path MTU between the pair of PEs terminating this PW. SAToP implementations using IPv4 PSN MUST mark the IPv4 datagrams they generate as "Don't Fragment" [RFC791]. 4.3. SAToP Header The SAToP header MUST contain the SAToP Control Word (4 bytes) and MAY also contain a fixed RTP header [RFC3550]. If the RTP header is included in the SAToP header, it MUST immediately precede the SAToP control word in case of an IPv4 or IPv6 PSN, and MUST immediately follow it in the case of an MPLS PSN (see Fig. 2a and Fig. 2b below). Note: Such an arrangement complies with the traditional usage of RTP for the IPv4/IPv6 PSN while making SAToP PWs ECMP-safe for the MPLS PSN (see [PWE3-ARCH], Section 5.4.4). Both UDP and L2TPv3 can provide the multiplexing mechanisms for SAToP PWs over an IPv4/IPv6 PSN. The PW label provides the multiplexing mechanism over an MPLS PSN as described in Section 5.4.2 of [PWE3- ARCH]. Vainshtein & Stein Expires March 2004 [Page 4] Structure-Agnostic TDM over Packet August 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | IPv4/IPv6 and multiplexing layer headers | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | OPTIONAL | +-- --+ | | +-- --+ | Fixed RTP Header (see [RFC3550]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SAToP Control Word | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... | | MPLS Label Stack | | ... | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | SAToP Control Word | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | OPTIONAL | +-- --+ | | +-- --+ | Fixed RTP Header (see [RFC3550]) | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ | Packetized TDM data (Payload) | | ... | | ... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2b. SAToP Packet Format for an MPLS PSN 4.3.1. Usage and Structure of the Control Word Usage of the SAToP control word allows: 1. Detection of packet loss or mis-ordering 2. Differentiation between the PSN and attachment circuit problems as causes for the outage of the emulated service Vainshtein & Stein Expires March 2004 [Page 5] Structure-Agnostic TDM over Packet August 2003 3. PSN bandwidth conservation by not transferring invalid data (AIS) 4. Signaling of faults detected at the PW egress to the PW ingress. The structure of the SAToP Control Word is shown in Fig. 2 below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0|L|R|RSV|FRG| LEN | Sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2. Structure of the SAToP Control Word Bits 0 to 3 MUST be set to 0 as described in [PWE3-ARCH], Section 5.4.4 L - if set, indicates that the PSN-bound IWF has detected or has been informed of a TDM fault condition invalidating the data to be transmitted. This bit MAY be used to indicate LOS and MAY be used in conjunction with other faults. When the L bit is set the contents of the packet payload may be meaningless, and the payload MAY be omitted in order to conserve bandwidth. Once set, if the TDM fault is rectified the L bit MUST be cleared. R - if set by the PSN-bound IWF, indicates that its local CE-bound IWF is in the packet loss state, i.e. has lost a preconfigured number of consecutive packets. The R bit MUST be cleared by the PSN-bound IWF once its local CE-bound IWF has exited the packet loss state, i.e. has received a preconfigured number of consecutive packets. RSV (reserved) and FRG (fragmentation) bits (6 to 10) - MUST be set to 0 by the PSN-bound IWF and MUST be ignored by the CE-bound IWF. LEN (bits (10 to 15) MAY be used to carry the length of the SAToP packet (defined as the size of the SAToP header + the payload size) if it is less than 64 bytes, and MUST be set to zero otherwise. Sequence number provides the common PW sequencing function and allows detection of lost packets. It MUST be generated in accordance with the rules defined in [RFC3550], Section 5 for the RTP sequence number. 4.3.2. Usage of RTP Header When RTP is used, SAToP requires the fields of the fixed RTP header (see [RFC3550], Section 5.1) with P (padding), X (header extension), CC (CSRC count), and M fields (marker) to be set to zero. The PT (payload type) field is used as following: 1. One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for each direction of the PW. The same PT value MAY be reused for both directions of the PW and also reused between different PWs Vainshtein & Stein Expires March 2004 [Page 6] Structure-Agnostic TDM over Packet August 2003 2. The PSN-bound IWF MUST set the PT field in the RTP header to the allocated value 3. The CE-bound IWF MAY use the received value to detect malformed packets The sequence number field MAY be used to provide the common PW sequencing function as well as detection of lost packets. It MUST be generated in accordance with the rules established in [RFC3550] and MUST be the same as the sequence number in the SAToP control word. Timestamps are used for carrying timing information over the network. Their values are generated in accordance with the rules established in [RFC3550]. The frequency of the clock used for generating timestamps MUST be an integer multiple of 8 kHz. All implementations of SAToP MUST support the 8 kHz clock. Other multiples of 8 kHz MAY be used. The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections. Timestamp generation MAY be used in the following modes: 1. Absolute mode: the PSN-bound IWF sets timestamps using the clock recovered from the incoming TDM attachment circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. All SAToP implementations that support usage of the RTP header MUST support this mode. 2. Differential mode: Both IWFs have access to a common high- quality timing source, and this source is used for timestamp generation. Support of this mode is OPTIONAL. Usage of the fixed RTP header in a SAToP PW and all the options associated with its usage (the time-stamping clock frequency, the time- stamping mode, selected PT and SSRC values) MUST be agreed upon between the two SAToP IWFs at the PW setup. 5. SAToP Payload Layer In order to facilitate handling of packet loss in the PSN, SAToP REQUIRES all packets belonging to a given SAToP PW to carry a fixed number of bytes filled with TDM data received from the attachment circuit. The packet payload size MUST be defined during the PW setup, MUST be the same for both directions of the PW and MUST remain unchanged for the lifetime of the PW. The CE-bound and PSN-bound IWFs MUST agree on SAToP packet payload size at the PW setup (default payload size values defined below guarantee that such an agreement is always possible). The SAToP packet payload size can be exchanged over the PWE3 control protocol ([PWE3-CONTROL]) by using the CEP Payload Bytes interface parameter ([PWE3-IANA]). SAToP uses the following ordering for packetization of the TDM data: Vainshtein & Stein Expires March 2004 [Page 7] Structure-Agnostic TDM over Packet August 2003 o The order of the payload bytes corresponds to their order on the attachment circuit o Consecutive bits coming from the attachment circuit fill each payload byte starting from most significant bit to least significant. All SAToP implementations MUST be capable of supporting the following payload sizes: o E1 - 256 bytes o T1 - 192 bytes o E3 and T3 - 1024 bytes. Notes: 1. Whatever the selected payload size, SAToP does not assume alignment to any underlying structure imposed by TDM framing (byte, frame or multiframe alignment). 2. When the L bit in the SAToP control word is set, SAToP packets MAY omit invalid TDM data in order to conserve PSN bandwidth. 3. Payload sizes that are multiples of 47 bytes MAY be used in conjunction with unstructured ATM-CES [ATM-CES]. 6. SAToP Operation 6.1. Common Considerations Edge-to-edge emulation of a TDM service using SAToP is only possible when the two PW attachment circuits are of the same type (T1, E1, T3, E3). The service type is exchanged at PW setup as described in [PWE3- CONTROL]. 6.2. IWF operation 6.2.1. PSN-bound Direction Once the PW is set up, the PSN-bound SAToP IWF operates as follows: TDM data is packetized using the configured number of payload bytes per packet. Sequence numbers, flags, and timestamps (if the RTP header is used) are inserted in the SAToP headers. SAToP, multiplexing layer and PSN headers are prepended to the packetized service data. The resulting packets are transmitted over the PSN. 6.2.2. CE-bound Direction The CE-bound SAToP IWF SHOULD include a jitter buffer where payload of the received SAToP packets is stored prior to play-out to the local TDM Vainshtein & Stein Expires March 2004 [Page 8] Structure-Agnostic TDM over Packet August 2003 attachment circuit. The size of this buffer SHOULD be locally configurable to allow accommodation to the PSN-specific packet delay variation. The CE-bound SAToP IWF SHOULD use the sequence number in the control word for detection of lost and mis-ordered packets. If the RTP header is used, the RTP sequence numbers MAY be used for the same purposes. The CE-bound SAToP IWF MAY re-order mis-ordered packets. Mis-ordered packets that cannot be reordered MUST be discarded and treated as lost. The payload of the received SAToP packets marked with the L bit set SHOULD be replaced by the equivalent amount of the "all ones" pattern even if it has not been omitted. The payload of each lost SAToP packet MUST be replaced with the equivalent amount of the replacement data. The contents of the replacement data are implementation-specific and MAY be locally configurable. By default, all SAToP implementations MUST support generation of the "all ones" pattern as the replacement data. Before a PW has been set up and after a PW has been torn down, the IWF MUST play out the "all ones" pattern to its TDM attachment circuit. Once the PW has been set up, the CE-bound IWF begins to receive SAToP packets and to store their payload in the jitter buffer but continues to play out the "all ones" pattern to its TDM attachment circuit. This intermediate state persists until a preconfigured amount of TDM data (usually half of the jitter buffer) has been received in consecutive SAToP packets or until a preconfigured intermediate state timer expires. Once the preconfigured amount of the TDM data has been received, the CE-bound SAToP IWF enters its normal operation state where it continues to receive SAToP packets and to store their payload in the jitter buffer while playing out the contents of the jitter buffer in accordance with the required clock. In this state the CE-bound IWF performs clock recovery, MAY monitor PW defects, and MAY collect PW performance monitoring data. If the CE-bound SAToP IWF detects loss of a preconfigured number of consecutive packets or if the intermediate state timer expires before the required amount of TDM data has been received, it enters its packet loss state. While in this state, the local PSN-bound SAToP IWF SHOULD mark every packet it transmits with the R bit set. The CE-bound SAToP IWF leaves this state and transits to the normal one once a preconfigured number of consecutive SAToP packets have been received. 6.3. SAToP Defects In addition to the packet loss state of the CE-bound SAToP IWF defined above, it MAY detect the following defects: Vainshtein & Stein Expires March 2004 [Page 9] Structure-Agnostic TDM over Packet August 2003 o Stray packets o Malformed packets o Excessive packet loss rate o Buffer overrun o Remote packet loss. Corresponding to each defect is a defect state of the IWF, a detection criterion that triggers transition from the normal operation state to the appropriate defect state, and an alarm that MAY be reported to the management system and thereafter cleared. Alarms are only reported when the defect state persists for a preconfigured amount of time (typically 2.5 seconds) and MUST be cleared after the corresponding defect is undetected for a second preconfigured amount of time (typically 10 seconds). The trigger and release times for the various alarms may be independent. Stray packets MAY be detected by the PSN and multiplexing layers. When RTP is used, the SSRC field in the RTP header MAY be used for this purpose as well. Stray packets MUST be discarded by the CE-bound IWF and their detection MUST NOT affect mechanisms for detection of packet loss. Malformed packets are detected by mismatch between the expected packet size (taking the value of the L bit into account) and the actual packet size inferred from the PSN and multiplexing layers. When RTP is used, lack of correspondence between the PT value and that allocated for this direction of the PW MAT also be used for this purpose. Malformed in- order packets MUST be discarded by the CE-bound IWF and replacement data generated as for lost packets. Excessive packet loss rate is detected by computing the average packet loss rate over a configurable amount of times and comparing it with a preconfigured threshold. Buffer overrun is detected in the normal operation state when the CE bound IWF's jitter buffer cannot accommodate newly arrived SAToP packets. Remote packet loss is indicated by reception of packets with their R bit set. 6.4. SAToP PW Performance Monitoring Performance monitoring (PM) parameters are routinely collected for TDM services and provide an important maintenance mechanism in TDM networks. Ability to collect compatible PM parameters for SAToP PWs enhances their maintenance capabilities. Collection of the SAToP PW performance monitoring parameters is OPTIONAL, and if implemented, is only performed after the CE-bound IWF has exited its intermediate state. SAToP defines error events, errored blocks and defects as follows: Vainshtein & Stein Expires March 2004 [Page 10] Structure-Agnostic TDM over Packet August 2003 o A SAToP error event is defined as insertion of a single replacement packet into the jitter buffer (replacement of payload of SAToP packets with the L bit set is not considered as insertion of a replacement packet) o A SAToP errored data block is defined as a block of data played out to the TDM attachment circuit and of size defined in accordance with the [G.826] rules for the corresponding TDM service that has experienced at least one SAToP error event o A SAToP defect is defined as the packet loss state of the CE- bound SAToP IWF. The SAToP PW PM parameters (Errored, Severely Errored and Unavailable Seconds) are derived from these definitions in accordance with [G.826]. 7. QoS Issues SAToP can benefit from QoS capabilities of the underlying PSN. If the PSN providing connectivity between PE devices is Diffserv- enabled and provides a PDB [RFC3086] that guarantees low-jitter and low-loss, the SAToP PW SHOULD use this PDB in compliance with the admission and allocation rules the PSN has put in place for that PDB (e.g., marking packets as directed by the PSN). If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC 2212] with the appropriate bandwidth reservation shall be used in order to provide a bandwidth guarantee equal or greater than that of the aggregate TDM traffic. The delay introduced by the PSN should be measured prior to traffic flow, to ensure its compliance with the latency requirement. 8. Congestion Control SAToP PWs represent a special case of PWs carrying constant bit rate (CBR) services across the PSN. These services cannot behave in a TCP- friendly manner prescribed by [RFC2914] under congestion. SAToP will use the generic PWE3 approach for handling congestion in PWs carrying CBR services when such an approach has been specified. 9. Security Considerations SAToP does not enhance or detract from the security performance of the underlying PSN, rather it relies upon the PSN mechanisms for encryption, integrity, and authentication whenever required. Misconnection detection capabilities of SAToP increase its resilience to misconfiguration and some types of DoS attacks. Vainshtein & Stein Expires March 2004 [Page 11] Structure-Agnostic TDM over Packet August 2003 Random initialization of sequence numbers defined in [RFC3550] makes known-plaintext attacks on encryption more difficult. 10. Issues for Further Study This section lists issues raised by the WG during discussion of the previous (non-WG) release of the draft. The editors solicit additional WG input for prompt resolution of these issues. 10.1. Use of SAToP for transport of "Octet-Aligned T1" Some commonly used NSP blocks provide access to T1 circuits mapped into (structured) E1 circuits in accordance with [G.802], Annex B. Important examples of such blocks are: o Integrated E1/T1 framers used in transparent mode (e.g., for enhanced fault isolation purposes) o SONET/SDH mappers that extract T1 circuits from SONET Virtual Tributaries or SDH Virtual Circuits. Special treatment of "octet-aligned T1" could simplify implementation in these applications, while treatment of the T1 as a raw 1.544 Mbps bit-stream is more appropriate for others. 10.2. Limitation of SAToP for T3 SAToP CE-bound IWF behavior has been designed to guarantee that the CE TDM interface experiences AIS condition while the IWF is in its idle or loss of packet states. This objective is readily achievable in emulation of E1, T1 and E3 circuits, which always use an AIS pattern that can be identified and generated in a structure agnostic manner. For T3 circuits identification and generation of the valid AIS pattern in a structure-agnostic manner is impossible without an appropriate NSP block (e.g., T3 framer). Integration of SAToP with T3 framers would also enable improved fault isolation and BW conservation during T3 circuit outages, but renounces the structure agnosticity. 11. Applicability Statement SAToP is an encapsulation layer intended for carrying TDM circuits (E1/T1/E3/T3) over PSN in a structure-agnostic fashion. SAToP fully complies with the principle of minimal intervention, thus minimizing overhead and computational power required for encapsulation. SAToP provides sequencing and synchronization functions needed for emulation of TDM bit-streams, including detection of lost or mis- ordered packets and appropriate compensation. SAToP carries TDM streams over PSN in their entirety including any TDM signaling contained within the data. Consequently the emulated TDM Vainshtein & Stein Expires March 2004 [Page 12] Structure-Agnostic TDM over Packet August 2003 services are sensitive to the PSN packet loss. Appropriate generation of "replacement packets" can be used to prevent shutting down the CE TDM interface due to occasional packet loss. Other effects of packet loss on this interface (e.g., errored blocks) cannot be prevented. Note: "Structured" TDM emulation (see [CESoPSN] or [TDMoIP]) completely hides effects of the PSN packet loss on the CE TDM interface (because framing and CRCs are generated locally) and allows usage of application-specific packet loss concealment methods [PACKETLOSS] to minimize effects on the applications using the emulated TDM service. SAToP can be used in conjunction with various clock recovery techniques and does not presume availability of a global synchronous clock at the ends of a PW. However, if the global synchronous clock is available at both ends of a SAToP PW, using RTP and differential timestamp generation may improve the quality of the recovered clock. SAToP provides for effective fault isolation by carrying the local attachment circuit failure indications. The option not to carry invalid TDM data facilitates PSN bandwidth conservation. SAToP allows collection of TDM-like faults and performance monitoring parameters hence emulating 'classic' carrier services of TDM. SAToP provides for a carrier-independent ability to detect misconnections and malformed packets. This feature increases resilience of the emulated service to misconfiguration and DoS attacks. Being a constant bit rate (CBR) service, SAToP cannot provide TCP- friendly behavior under network congestion. Faithfulness of a SAToP PW may be increased by exploiting QoS features of the underlying PSN. SAToP does not provide any mechanisms for protection against PSN outages, and hence its resilience to such outages is limited. However, lost-packet replacement and packet reordering mechanisms increase resilience of the emulated service to fast PSN rerouting events. 12. IANA Considerations This specification requires assignment of new PW Types services listed in Section 3. 13. Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. Axerra Networks, Inc. has filed one or more patent applications relating to the SAToP technology outlined in this document. Axerra Networks, Inc. will grant free unlimited licenses for use of this Vainshtein & Stein Expires March 2004 [Page 13] Structure-Agnostic TDM over Packet August 2003 technology to the users who will register and sign up at the Axerra web site. RAD Data Communications, Ltd. has filed one or more patent applications that may relate to the technology outlined in this document. RAD hereby grants free unlimited license for use of its intellectual property to the extent required for compliance with this document. ACKNOWLEDGEMENTS We acknowledge the work of Gil Biran and Hugo Silberman who implemented TDM transport over IP in 1998. We would like to thank Alik Shimelmits for many productive discussions and Ron Insler for his assistance in deploying TDM over PSN. We express deep gratitude to Stephen Casner who has reviewed in detail one of the predecessors of this document and provided valuable feedback regarding various aspects of RTP usage, and to Kathleen Nichols who has provided the current text of the QoS section considering Diffserv- enabled PSN. We thank Robert Biksner, Stewart Bryant, Rao Cherukuri, Ron Cohen, Alex Conta, Shahram Davari, Tom Johnson, Sim Narasimha, Yaron Raz, and Maximilian Riegel for their valuable feedback. NORMATIVE REFERENCES [RFC791] J. Postel (ed), Internet Protocol, RFC 791, IETF, 1981 [RFC1122] R. Braden (ed.), Requirements for Internet Hosts -- Communication Layers, RFC 1122, IETF, 1989 [RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels, RFC 2119, IETF, 1997 [RFC2112] S. Shenker et al, Specification of Guaranteed Quality of Service, IETF, RFC 2212, 1997 [RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000 [RFC3086] K. Nichols, B. Carpenter, Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification, RFC 3086, IETF, 2001 [RFC3550] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time Applications, RFC 3550, IETF, 2003 Vainshtein & Stein Expires March 2004 [Page 14] Structure-Agnostic TDM over Packet August 2003 [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- parameters [G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy Bit Rates [G.703] ITU-T Recommendation G.703 (10/98) - Physical/Electrical Characteristics of Hierarchical Digital Interfaces [G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44 736 Kbit/s hierarchical levels [G.707] ITU-T Recommendation G.707 (03/96) - Network Node Interface for the Synchronous Digital Hierarchy (SDH) [G.751] ITU-T Recommendation G.751 (11/88) - Digital Multiplex Equipments Operating at the Third Order Bit Rate of 34368 kbit/s and the Fourth Order Bit Rate of 139264 kbit/s and Using Positive Justification [G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), Alarm Indication Signal (AIS) and Remote Defect Indication (RDI) Defect Detection and Clearance Criteria for PDH Signals [G.802] ITU-T Recommendation G.802 (11/88) - Interworking between Networks Based on Different Digital Hierarchies and Speech Encoding Laws [G.826] ITU-T Recommendation G.826 (02/99) - Error performance parameters and objectives for international, constant bit rate digital paths at or above the primary rate [T1.107] American National Standard for Telecommunications - Digital Hierarchy - Format Specifications, ANSI T1.107-1988 INFORMATIONAL REFERENCES [PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in Progress, June 2003, draft-ietf-pwe3- requirements-06.txt [PWE3-TDM-REQ] Maximilian Riegel et al, Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN), Work in Progress, June 2003, draft-ietf-pwe3-tdm-requirements-01.txt [PWE3-ARCH] S. Bryant, P. Pate et al, Framework for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work in progress, August 2003, draft- ietf-pwe3-framework-05.txt [PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using LDP, Work in progress, June 2003, draft-ietf-pwe3-control-protocol- 03.txt Vainshtein & Stein Expires March 2004 [Page 15] Structure-Agnostic TDM over Packet August 2003 [PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire Edge to Edge Emulation (PWE3), Work in progress, February 2003, draft- ietf-pwe3-iana-allocation-01.txt [ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0 [CESoPSN] A.Vainshtein et al, TDM Circuit Emulation Service over Packet Switched Network (CESoPSN), Work in Progress, March 2003, draft- vainshtein-cesopsn-06.txt [TDMoIP] Y. Stein, TDMoIP, Work in Progress, March 2003, draft-anavi- tdmoip-05.txt [PACKETLOSS] Y. Stein, I Druker, The Effect of Packet Loss on Voice Quality for TDM over Pseudowires, Work in Progress, September 2002, draft-stein-pwe3-tdm-packetloss-00.txt Editors' Addresses Alexander ("Sasha") Vainshtein Axerra Networks 24 Raoul Wallenberg St., Tel Aviv 69719, Israel email: sasha@axerra.com Yaakov (Jonathan) Stein RAD Data Communications 24 Raoul Wallenberg St., Bldg C Tel Aviv 69719, Israel Email: yaakov_s@rad.com Vainshtein & Stein Expires March 2004 [Page 16]