RFC 4553

Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)

📅 published June 2006, from ietf

RFC 4553: Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP) 🎀

Okay bestie, here's the header rundown ✨

  • Network Working Group 🌸
  • Authors: A. Vainshtein, Ed. (Axerra Networks) and YJ. Stein, Ed. (RAD Data Communications) 💅
  • Category: Standards Track 👑
  • Date: June 2006 🦋
  • Obsoletes / Updates: none listed in this header 💀

Status of This Memo 📜

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright (C) The Internet Society (2006).

Abstract 💜

Okay so this doc describes a pseudowire encapsulation for Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that just doesn't care about any structure sitting on top of those streams, especially the structure that standard TDM framing adds. 🧚

Table of Contents 📖

1. Introduction ....................................................3
2. Terminology and Reference Models ................................3
   2.1. Terminology ................................................3
   2.2. Reference Models ...........................................4
3. Emulated Services ...............................................4
4. SAToP Encapsulation Layer .......................................5
   4.1. SAToP Packet Format ........................................5
   4.2. PSN and PW Demultiplexing Layer Headers ....................5
   4.3. SAToP Header ...............................................6
        4.3.1. Usage and Structure of the Control Word .............8
        4.3.2. Usage of RTP Header .................................9
5. SAToP Payload Layer ............................................10
   5.1. General Payloads ..........................................10
   5.2. Octet-Aligned T1 ..........................................11
6. SAToP Operation ................................................12
   6.1. Common Considerations .....................................12
   6.2. IWF Operation .............................................12
        6.2.1. PSN-Bound Direction ................................12
        6.2.2. CE-Bound Direction .................................13
   6.3. SAToP Defects .............................................14
   6.4. SAToP PW Performance Monitoring ...........................15
7. Quality of Service (QoS) Issues ................................16
8. Congestion Control .............................................16
9. Security Considerations ........................................18
10. Applicability Statement .......................................18
11. IANA Considerations ...........................................20
12. Acknowledgements ..............................................20
13. Co-Authors ....................................................20
14. Normative References ..........................................21
15. Informative References ........................................22
Appendix A: Old Mode of SAToP Encapsulation over L2TPv3 ...........24
Appendix B: Parameters That MUST Be Agreed upon during the PW
            Setup .................................................24

1. Introduction 🧚

This doc is all about wrapping up Time Division Multiplexing (TDM) bit-streams (T1, E1, T3, E3) as pseudowires so they can travel over packet-switching networks (PSN). ✨ It only covers structure-agnostic transport, which means the protocol totally ignores whatever structure might be sitting on these signals, especially the structure from standard TDM framing [G.704]. The original name for this is "emulation of unstructured TDM circuits" in [RFC4197], and it's perfect for setups where the PEs don't need to read the TDM data or join in on the TDM signaling. 💅

The SAToP solution in this doc follows the PWE3 architecture described in [RFC3985], and it's giving compliance with both the general requirements in [RFC3916] and the specific requirements for unstructured TDM signals in [RFC4197]. 👑

As with all PWs, SAToP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. The extensions to the PWE3 control protocol needed for setting up and maintaining SAToP pseudowires, plus the code point allocations for that, live in separate documents ([TDM-CONTROL] and [RFC4446], respectively). 🦋

2. Terminology and Reference Models 📚

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 [RFC2119].

2.1. Terminology 💖

The following acronyms used in this document are defined in [RFC3985] and [RFC4197]:

ATM          Asynchronous Transfer Mode
CE           Customer Edge
CES          Circuit Emulation Service
NSP          Native Service Processing
PE           Provider Edge
PDH          Plesiochronous Digital Hierarchy
PW           Pseudowire
SDH          Synchronous Digital Hierarchy
SONET        Synchronous Optical Network
TDM          Time Division Multiplexing

In addition, the following TDM-specific terms are needed:

  • Loss of Signal (LOS): a condition of the TDM attachment circuit where the incoming signal can't be detected. ✨ The criteria for entering and leaving the LOS condition can be found in [G.775].
  • Alarm Indication Signal (AIS): a special bit pattern in the TDM bit stream (e.g., as described in [G.775]) that indicates 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), so it can be detected and generated by structure-agnostic means. 💜 The T3 AIS pattern requires T3 framing (see [G.704], Section 2.5.3.6.1), so it can only be handled by a structure-aware NSP. 💀

We also use the term Interworking Function (IWF) to describe the functional block that segments and encapsulates TDM into SAToP packets, and in the reverse direction, decapsulates SAToP packets and reconstitutes TDM. 🌸

2.2. Reference Models 🦋

The generic models defined in Sections 4.1, 4.2, and 4.4 of [RFC3985] 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 [RFC3985]. 🌈

The Network Synchronization reference model and deployment scenarios for emulation of TDM services are described in [RFC4197], Section 4.3. 🧚

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 emulating these services doesn't depend on how the attachment circuits get delivered to the PEs. ✨ For example, a T1 attachment circuit is treated the same way whether it arrives on copper [G.703], is multiplexed into a T3 circuit [T1.107], is mapped into a virtual tributary of a SONET/SDH circuit [G.707], or is carried over an ATM network using unstructured ATM Circuit Emulation Service (CES) [ATM-CES]. 💅 Terminating any specific "carrier layers" used between the PE and CE is handled by an appropriate NSP. 👑

4. SAToP Encapsulation Layer 🎀

4.1. SAToP Packet Format ✨

The basic format of SAToP packets is shown in Figure 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 PW demultiplexing layer headers          |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   +--                                                           --+
   |                   SAToP Encapsulation Header                  |
   +--                                                           --+
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                        TDM data (Payload)                     |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 1. Basic SAToP Packet Format 🧚

4.2. PSN and PW Demultiplexing Layer Headers 💅

Both UDP and L2TPv3 [RFC3931] can provide the PW demultiplexing mechanisms for SAToP PWs over an IPv4/IPv6 PSN. ✨ The PW label handles the demultiplexing function for an MPLS PSN, as described in Section 5.4.2 of [RFC3985]. 💜

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] (see also [PWE3-FRAG]). 🫶

Part 1 of 5 is done, bestie 💖 Part 2 is coming up next, so stay tuned! 🦋

4.3. SAToP Header ✨

okay so the SAToP header MUST contain the SAToP Control Word (4 bytes) 💖 and it MAY also carry a fixed RTP header [RFC3550]. if the RTP header is included, it MUST sit right after the SAToP control word in every case except UDP multiplexing, where it MUST come before the control word instead (see Figures 2a, 2b, and 2c below) 🎀

Note: this layout is totally in line with the traditional way RTP gets used over IPv4/IPv6 with UDP multiplexing 🦋 It also keeps SAToP PWs Equal Cost Multi-Path (ECMP)-safe on the MPLS PSN, because it provides PW-IP packet discrimination (see [RFC3985], Section 5.4.3). On top of that, it helps with seamless stitching of L2TPv3-based and MPLS-based segments of SAToP PWs (see [PWE3-MS]) 💅

    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 UDP (PW demultiplexing layer) headers     |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                            ...                                |
   |                      TDM data (Payload)                       |
   |                            ...                                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with UDP PW Demultiplexing

    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 L2TPv3 (PW demultiplexing layer) headers    |
   |                             ...                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                  SAToP Control Word                           |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                                                               |
   +--                     OPTIONAL                              --+
   |                                                               |
   +--               Fixed RTP Header (see [RFC3550])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                       TDM data (Payload)                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with L2TPv3 PW Demultiplexing

    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])            --+
   |                                                               |
   +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
   |                             ...                               |
   |                       TDM data (Payload)                      |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2c. SAToP Packet Format for an MPLS PSN

4.3.1. Usage and Structure of the Control Word

the SAToP control word is basically the multitool of this whole thing 🧰 it lets you do the following:

  1. Detection of packet loss or misordering
  2. Differentiation between the PSN and attachment circuit problems as causes for the outage of the emulated service
  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 Figure 3 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 3. Structure of the SAToP Control Word

okay so the use of Bits 0 to 3 is described in [RFC4385]. these bits MUST be set to zero unless they're being used to indicate the start of an Associated Channel Header (ACH) 🌸 an ACH is needed if the state of the SAToP PW is being monitored using Virtual Circuit Connectivity Verification [PWE3-VCCV].

here's the breakdown of the fields, bestie:

  • L - if set, it means the TDM data in the payload is invalid because of an attachment circuit fault. when the L bit is set, the payload MAY be omitted to conserve bandwidth 🧚 the CE-bound IWF MUST play out an appropriate amount of filler data regardless of the payload size. once it's set, if the fault gets fixed, the L bit MUST be cleared.
  • R - if set by the PSN-bound IWF, it means its local CE-bound IWF is in the packet loss state, i.e., it 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 and FRG (bits 6 to 9) - MUST be set to 0 by the PSN-bound IWF and MUST be ignored by the CE-bound IWF. RSV is reserved. FRG is fragmentation; see [PWE3-FRAG].
  • 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's less than 64 bytes, and MUST be set to zero otherwise. when the LEN field is set to 0, the preconfigured size of the SAToP packet payload MUST be assumed to be as described in Section 5.1, and if the actual packet size is inconsistent with this length, the packet MUST be considered malformed. 💀
  • Sequence number - used to provide the common PW sequencing function as well as detection of lost packets 🍓 It MUST be generated in accordance with the rules defined in Section 5.1 of [RFC3550] for the RTP sequence number:
    • Its space is a 16-bit unsigned circular space
    • Its initial value SHOULD be random (unpredictable).

It MUST be incremented with each SAToP data packet sent in the specific PW.

Note: This document does not specify which TDM fault conditions are treated as invalidating the data carried in the SAToP packets. Possible examples include, but are not limited to LOS and AIS.

4.3.2. Usage of RTP Header

when RTP is used, the following fields of the fixed RTP header (see [RFC3550], Section 5.1) MUST be set to zero: P (padding), X (header extension), CC (CSRC count), and M (marker) 🙈

the PT (payload type) field is used like this:

  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.
  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 MUST be the same as the sequence number in the SAToP control word. 🫶

The RTP 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, i.e., incorrect interconnection of attachment circuits.

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 tied to it (the timestamping clock frequency, the timestamping mode, and the selected PT and SSRC values), MUST be agreed upon between the two SAToP IWFs during PW setup as described in [TDM-CONTROL]. Other, RTP-specific methods (e.g., see [RFC3551]) MUST NOT be used. 🦋

5. SAToP Payload Layer ✨

5.1. General Payloads ✨

okay so, to make packet loss on the PSN easier to handle, every packet belonging to a SAToP PW is REQUIRED to carry a fixed number of bytes filled with TDM data straight from the attachment circuit 💖 The packet payload size MUST be defined during PW setup, MUST be the same in both directions of the PW, and MUST remain unchanged for the entire lifetime of the PW. no cap, consistency is everything 🎀

The CE-bound and PSN-bound IWFs MUST agree on the SAToP packet payload size during PW setup. (The default payload sizes listed below guarantee that such an agreement is always possible 🧚) The payload size can be exchanged over the PWE3 control protocol ([TDM-CONTROL]) using the Circuit Emulation over Packet (CEP)/TDM Payload Bytes sub-TLV of the Interface Parameters TLV ([RFC4446]).

SAToP packs the TDM data in a specific order 🍓

  • The order of the payload bytes matches their order on the attachment circuit.
  • Consecutive bits coming off the attachment circuit fill each payload byte, starting from the most significant bit and going down to the least significant.

All SAToP implementations MUST be capable of supporting these payload sizes:

  • E1 - 256 bytes
  • T1 - 192 bytes
  • E3 and T3 - 1024 bytes

Notes:

  1. No matter what payload size you pick, SAToP does not assume alignment to any structure imposed by TDM framing (byte, frame, or multiframe alignment). Iconic independence 💅
  2. When the L bit in the SAToP control word is set, SAToP packets MAY omit invalid TDM data to save PSN bandwidth 🌸
  3. Payload sizes that are multiples of 47 bytes MAY be used together with unstructured ATM-CES [ATM-CES] 🦋

5.2. Octet-Aligned T1 🎀

okay this one is lowkey so cute. An unstructured T1 attachment circuit sometimes shows up already padded to an integer number of bytes, as described in Annex B of [G.802]. That happens when the T1 gets de-mapped from a SONET/SDH virtual tributary/container, or when a dual-mode E1/T1 framer de-frames it 👑

So SAToP defines a special "octet-aligned T1" transport mode to make that work. In this mode, the SAToP payload is a bunch of 25-byte subframes, and each subframe carries 193 bits of TDM data plus 7 bits of padding. Here's the picture (Figure 4) 🦋

  |     1         |        2      | ...   |      25       |
  |0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ...   |0 1 2 3 4 5 6 7|
  |=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
  |           TDM Data                      |  padding    |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |            .................................          |
  +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  |           TDM Data                      |  padding    |
  +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

Figure 4. SAToP Payload Format for Octet-Aligned T1 Transport

Notes:

  1. No alignment with any framing structure that might be imposed on the T1 bit-stream is implied.
  2. An extra perk of the octet-aligned T1 transport mode is that you can pick the SAToP packetization latency as any arbitrary integer multiple of 125 microseconds ✨

Supporting the octet-aligned T1 transport mode is OPTIONAL. An octet-aligned T1 SAToP PW is not interoperable with a T1 SAToP PW that carries a non-aligned bit-stream, as described in the previous section 🙈

Implementations that support octet-aligned T1 transport mode MUST be capable of supporting a payload size of 200 bytes (i.e., a payload of eight 25-byte subframes), which is exactly 1 millisecond of TDM data 🫶

6. SAToP Operation 👑

6.1. Common Considerations 💖

Edge-to-edge emulation of a TDM service using SAToP only works when both PW attachment circuits are the same type (T1, E1, T3, E3). The service type gets exchanged at PW setup, as described in [RFC4447] 🧚

6.2. IWF Operation 🌈

6.2.1. PSN-Bound Direction

Once the PW is set up, the PSN-bound SAToP IWF does the following, in order. The TDM data gets packetized using the configured number of payload bytes per packet 📦

Sequence numbers, flags, and timestamps (if the RTP header is used) get inserted into the SAToP headers 🎀

SAToP, PW demultiplexing layer, and PSN headers get prepended to the packetized service data ✨

Then the resulting packets are transmitted over the PSN. slay 💅

6.2.2. CE-Bound Direction

The CE-bound SAToP IWF SHOULD include a jitter buffer, where the payload of received SAToP packets gets stored before it's played out to the local TDM attachment circuit. The size of this buffer SHOULD be locally configurable, so it can handle the PSN-specific packet delay variation 🌸

The CE-bound SAToP IWF SHOULD use the sequence number in the control word to detect lost and misordered packets. If the RTP header is used, the RTP sequence numbers MAY be used for the same purposes 🔥

Note: With SAToP, a valid sequence number can always be found in bits 16 - 31 of the first 32-bit word right after the PW demultiplexing header, no matter the PSN type, the multiplexing method, or whether the RTP header is used. This makes life easier for implementations that support multiple encapsulation types, and for multi-segment (MS) PWs that use different encapsulation types in different segments 🧚

The CE-bound SAToP IWF MAY reorder misordered packets. Misordered packets that can't be reordered MUST be discarded and treated as lost 🙈

The payload of received SAToP packets with the L bit set SHOULD be replaced by the equivalent amount of the "all ones" pattern, even if it hasn't been omitted 💀

The payload of each lost SAToP packet MUST be replaced with the equivalent amount of replacement data. The contents of the replacement data are implementation-specific and MAY be locally configurable. By default, every SAToP implementation MUST support generating 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 starts receiving SAToP packets and storing their payload in the jitter buffer, but it keeps playing out the "all ones" pattern to its TDM attachment circuit. This intermediate state lasts until a preconfigured amount of TDM data (usually half of the jitter buffer) has arrived in consecutive SAToP packets, or until a preconfigured intermediate state timer (started when PW setup completes) expires 🌈

Once the preconfigured amount of TDM data has arrived, the CE-bound SAToP IWF enters its normal operation state. It keeps receiving SAToP packets and storing their payload in the jitter buffer, while playing out the contents of the jitter buffer according to 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 arrived, 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 goes back to the normal one once a preconfigured number of consecutive valid SAToP packets have arrived. (Successfully reordered packets count toward the consecutive packet total 💖)

The CE-bound SAToP IWF MUST provide an indication of TDM data validity to the CE. This can be done by transporting the native AIS indication or by generating it. As mentioned above, T3 AIS cannot be detected or generated by structure-agnostic means, so a structure-aware NSP MUST be used when generating a valid AIS pattern 🔥

6.3. SAToP Defects 🚨

Besides the packet loss state of the CE-bound SAToP IWF defined above, the IWF MAY detect the following defects:

  • Stray packets
  • Malformed packets
  • Excessive packet loss rate
  • Buffer overrun
  • Remote packet loss

Each defect has a matching defect state of the IWF, a detection criterion that triggers the move from the normal operation state into that defect state, and an alarm that MAY be reported to the management system and then cleared. Alarms only get reported when the defect state persists for a preconfigured amount of time (typically 2.5 seconds), and they MUST be cleared after the corresponding defect goes 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 PW demultiplexing 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 detecting them MUST NOT affect the mechanisms used to detect packet loss 🙈

Malformed packets are detected by a mismatch between the expected packet size (taking the L bit into account) and the actual packet size inferred from the PSN and PW demultiplexing layers. When RTP is used, a mismatch between the PT value and the one allocated for this direction of the PW MAY also be used for this purpose. Malformed in-order packets MUST be discarded by the CE-bound IWF, and replacement data gets generated the same way as for lost packets 💀

Excessive packet loss rate is detected by computing the average packet loss rate over a configurable amount of time and comparing it with a preconfigured threshold 📉

Buffer overrun is detected in the normal operation state when the jitter buffer of the CE-bound IWF cannot accommodate newly arrived SAToP packets 🫠

Remote packet loss is indicated by the 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 they're an important maintenance mechanism in TDM networks. Being able to collect compatible PM parameters for SAToP PWs makes their maintenance capabilities even better 💅

Collecting the SAToP PW performance monitoring parameters is OPTIONAL. If it's implemented, it only happens after the CE-bound IWF has exited its intermediate state 🧚

SAToP defines error events, errored blocks, and defects like this:

  • A SAToP error event is the insertion of a single replacement packet into the jitter buffer. (Replacing the payload of SAToP packets with the L bit set does not count as inserting a replacement packet 🙈)
  • A SAToP errored data block is a block of data played out to the TDM attachment circuit, sized according to the [G.826] rules for the corresponding TDM service, that has experienced at least one SAToP error event 🔥
  • A SAToP defect is 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. Quality of Service (QoS) Issues 💅

okay so first things first, SAToP SHOULD employ existing QoS capabilities of the underlying PSN 🎀. use what the network already has, bestie!

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) [RFC2212] with the appropriate bandwidth reservation SHOULD be used in order to provide a bandwidth guarantee equal or greater than that of the aggregate TDM traffic 💜

8. Congestion Control 🌊

okay this section is giving storm warning but make it cute 🦋. As explained in [RFC3985], the PSN carrying the PW may be subject to congestion. SAToP PWs represent inelastic constant bit-rate (CBR) flows and cannot respond to congestion in a TCP-friendly manner prescribed by [RFC2914], although the percentage of total bandwidth they consume remains constant 😭

Unless appropriate precautions are taken, undiminished demand of bandwidth by SAToP PWs can contribute to network congestion that may impact network control protocols 💀

Whenever possible, SAToP PWs SHOULD be carried across traffic-engineered PSNs that provide either bandwidth reservation and admission control or forwarding prioritization and boundary traffic conditioning mechanisms. IntServ-enabled domains supporting Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains [RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide examples of such PSNs. Such mechanisms will negate, to some degree, the effect of the SAToP PWs on the neighboring streams. In order to facilitate boundary traffic conditioning of SAToP traffic over IP PSNs, the SAToP IP packets SHOULD NOT use the DiffServ Code Point (DSCP) value reserved for the Default Per-Hop Behavior (PHB) [RFC2474] 🍓

If SAToP PWs run over a PSN providing best-effort service, they SHOULD monitor packet loss in order to detect "severe congestion". If such a condition is detected, a SAToP PW SHOULD shut down bi-directionally for some period of time as described in Section 6.5 of [RFC3985] 🚨

Note that:

  1. The SAToP IWF can inherently provide packet loss measurement since the expected rate of arrival of SAToP packets is fixed and known.
  2. The results of the SAToP packet loss measurement may not be a reliable indication of presence or absence of severe congestion if the PSN provides enhanced delivery. For example:

a) If SAToP traffic takes precedence over non-SAToP traffic, severe congestion can develop without significant SAToP packet loss.

b) If non-SAToP traffic takes precedence over SAToP traffic, SAToP may experience substantial packet loss due to a short-term burst of high-priority traffic.

  1. The TDM services emulated by the SAToP PWs have high availability objectives (see [G.826]) that MUST be taken into account when deciding on temporary shutdown of SAToP PWs 🫶

This specification does not define the exact criteria for detecting "severe congestion" using the SAToP packet loss rate or the specific methods for bi-directional shutdown the SAToP PWs (when such severe congestion has been detected) and their subsequent re-start after a suitable delay. This is left for further study. However, the following considerations may be used as guidelines for implementing the SAToP severe congestion shutdown mechanism:

  1. SAToP Performance Monitoring techniques (see Section 6.4) provide entry and exit criteria for the SAToP PW "Unavailable" state that make it closely correlated with the "Unavailable" state of the emulated TDM circuit as specified in [G.826]. Using the same criteria for "severe congestion" detection may decrease the risk of shutting down the SAToP PW while the emulated TDM circuit is still considered available by the CE ✨
  2. If the SAToP PW has been set up using either PWE3 control protocol [RFC4447] or L2TPv3 [RFC3931], the regular PW teardown procedures of these protocols SHOULD be used.
  3. If one of the SAToP PW end points stops transmission of packets for a sufficiently long period, its peer (observing 100% packet loss) will necessarily detect "severe congestion" and also stop transmission, thus achieving bi-directional PW shutdown 🌸

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 🛡️

SAToP PWs share susceptibility to a number of pseudowire-layer attacks and will use whatever mechanisms for confidentiality, integrity, and authentication are developed for general PWs. These methods are beyond the scope of this document 👀

Although SAToP PWs MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are NOT RECOMMENDED as a substitute for PW layer security. ⚠️ this one is important, don't swap SRTP in as your PW security, bestie 🙅‍♀️

Misconnection detection capabilities of SAToP increase its resilience to misconfiguration and some types of denial-of-service (DoS) attacks 💖

Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted SAToP PWs more difficult. Encryption of PWs is beyond the scope of this document 🔒

10. 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 misordered packets and appropriate compensation 🔥

TDM bit-streams carried over SAToP PWs may experience delays exceeding those typical of native TDM networks. These delays include the SAToP packetization delay, edge-to-edge delay of the underlying PSN, and the delay added by the jitter buffer. It is recommended to estimate both delay and delay variation prior to setup of a SAToP PW ⏳

SAToP carries TDM streams over PSN in their entirety, including any TDM signaling contained within the data. Consequently, the emulated TDM services are sensitive to the PSN packet loss. Appropriate generation of replacement data 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: Structure-aware TDM emulation (see [CESoPSN] or [TDMoIP]) completely hides effects of the PSN packet loss on the CE TDM interface (because framing and Cyclic Redundancy Checks (CRCs) are generated locally) and allows usage of application-specific packet loss concealment methods to minimize effects on the applications using the emulated TDM service 🧠

SAToP can be used in conjunction with various network synchronization scenarios (see [RFC4197]) and clock recovery techniques. The quality of the TDM clock recovered by the SAToP IWF may be implementation-specific. The quality may be improved by using RTP if a common clock is available at both ends of the SAToP PW ⏰

SAToP provides for effective fault isolation by carrying the local attachment circuit failure indications 🔍

The option not to carry invalid TDM data enables PSN bandwidth conservation 🌿

SAToP allows collection of TDM-like faults and performance monitoring parameters and hence emulates '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 🦋

11. IANA Considerations 📋

Allocation of PW Types for the corresponding SAToP PWs is defined in [RFC4446].

12. 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 William Bartholomay, 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 💖

13. 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
Israel Sasson               Axerra Networks
Ronen Shashoua              RAD Data Communications

14. Normative References ✨

Okay bestie, here are the normative refs, the ones you need to read before you can implement anything. 📚🎀

[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.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.

[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.

[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.

[RFC3086] Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.

[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.

[RFC3931] Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

[RFC4385] Bryant, S., Swallow, G., Martini, L., and D. McPherson, "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word for Use over an MPLS PSN", RFC 4385, February 2006.

[RFC4446] Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

[RFC4447] Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G. Heron, "Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP)", RFC 4447, April 2006.

[RTP-TYPES] RTP PARAMETERS, <http://www.iana.org/assignments/rtp-parameters>.

[T1.107] American National Standard for Telecommunications - Digital Hierarchy - Format Specifications, ANSI T1.107-1988.

15. Informative References 🧚

These are the vibes-and-background reads. Not strictly required, but iykyk. 🌸

[ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0.

[CESoPSN] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "TDM Circuit Emulation Service over Packet Switched Network (CESoPSN)", Work in Progress, November 2005.

[PWE3-MS] Martini, L., Metz, C., Nadeau, T., Duckett, M., and F. Balus, "Segmented Pseudo Wire", Work in Progress, March 2006.

[PWE3-FRAG] Malis, A. and M. Townsley, "PWE3 Fragmentation and Reassembly", Work in Progress, November 2005.

[PWE3-VCCV] Nadeau, T. and R. Aggarwal, "Pseudo Wire Virtual Circuit Connectivity", Work in Progress, August 2005.

[RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.

[RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002.

[RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, July 2003.

[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004.

[RFC3916] Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.

[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.

[RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005.

[TDM-CONTROL] Vainshtein, A. and Y. Stein, "Control Protocol Extensions for Setup of TDM Pseudowires", Work in Progress, July 2005.

[TDMoIP] Stein, Y., "TDMoIP", Work in Progress, February 2005.

Appendix A: Old Mode of SAToP Encapsulation over L2TPv3 🎀

Okay so this one is a little bit of throwback drama. 🕰️ Earlier versions of this spec had a SAToP PW encapsulation over L2TPv3 that is not the same as the one in Section 4.3 and Figure 2b. 💅 In those older versions, the RTP header (if used) comes before the SAToP control word. Very different outfit, bestie. 👗

Existing implementations of the old encapsulation mode MUST be distinguished from the encapsulations conforming to this specification via the SAToP PW setup. 🚨 Don't mix them up!!

Appendix B: Parameters That MUST Be Agreed upon during the PW Setup 🫶

Here's the checklist of everything the two IWFs have to agree on before the PW goes live. ✅ The following parameters of the SAToP IWF MUST be agreed upon between the peer IWFs during the PW setup. The agreement can happen through manual configuration or through one of the PW setup protocols. Easy peasy. 🍓

  1. Type of the Attachment Circuit (AC) 🔌

As mentioned in Section 3, SAToP supports these AC types:

  • i) E1 (2048 kbit/s)
  • ii) T1 (1544 kbit/s); this service is also known as DS1
  • iii) E3 (34368 kbit/s)
  • iv) T3 (44736 kbit/s); this service is also known as DS3

SAToP PWs cannot be established between ACs of different types. 🙅‍♀️

  1. Usage of octet-aligned mode for T1 🧩

a) This OPTIONAL mode of emulating T1 bit-streams with SAToP PWs is described in Section 5.2. It's totally optional, so no pressure. 🌈

b) Both sides MUST agree on using this mode for a SAToP PW to be operational.

  1. Payload size, i.e., the amount of valid TDM data in a SAToP packet 📦

a) As mentioned in Section 5.1:

  • i) The same payload size MUST be used in both directions of the SAToP PW.
  • ii) The payload size cannot be changed once the PW has been set up. Locked in, no take-backs. 🔒

b) In most cases, any mutually agreed upon value can be used. However, if octet-aligned T1 encapsulation mode is used, the payload size MUST be an integral multiple of 25, and it expresses the amount of valid TDM data including padding. 🤓

  1. Usage of the RTP header in the encapsulation 🎶

a) Both sides MUST agree on using the RTP header in the SAToP PW.

b) In the case of a SAToP PW over L2TPv3 using the RTP header, both sides MUST agree on usage of the "old mode" described in Appendix A.

  1. RTP-dependent parameters. The following parameters MUST be agreed upon if usage of the RTP header for the SAToP PW has been agreed upon. 💜

a) Timestamping mode (absolute or differential). This mode MAY be different for the two directions of the PW, but the receiver and transmitter MUST agree on the timestamping mode for each direction of the PW. ⏱️

b) Timestamping clock frequency:

  • i) The timestamping frequency MUST be an integral multiple of 8 kHz.
  • ii) The timestamping frequency MAY be different for the two directions of the PW, but the receiver and transmitter MUST agree on the timestamping mode for each direction of the PW.

c) RTP Payload Type (PT) value. Any dynamically assigned value can be used with SAToP PWs. 🎁

d) Synchronization Source (SSRC) value. The transmitter MUST agree to send the SSRC value requested by the receiver. 📻

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

Copyright (C) The Internet Society (2006).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property 🧾

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

Acknowledgement 🌷

Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Big thanks to them for keeping the lights on. 💖

📦 where this page comes from