RFC 5087
Time Division Multiplexing over IP (TDMoIP)
Part 1 of 11 🎀
Time Division Multiplexing over IP (TDMoIP) 💖
- RFC number and series: RFC 5087, from the Network Working Group 🌸
- Authors: Y(J). Stein, R. Shashoua, R. Insler, and M. Anavi
- Organisation: RAD Data Communications
- Category: Informational (so this is a "here's some info" doc, not a standard) 📚
- Date: December 2007
- Obsoletes and updates: the title block doesn't list any RFCs that this one obsoletes or updates. Nothing to chase there 🦋
Status of This Memo 📜
Okay, the official vibe: this memo gives info to the Internet community. It does not specify an Internet standard of any kind, and distribution of it is unlimited 🌈
Abstract ✨
TDMoIP is a structure-aware way to carry TDM signals over pseudowires (PWs). Because it's structure-aware, it keeps the TDM structure intact, so it handles network messiness way better than structure-agnostic transport does 💅 It can tell individual channels apart, which means it can do packet loss concealment and save bandwidth. And since the TDM signaling is accessible, you can build stuff that exploits or messes with that signaling 🔥
Table of Contents 🧚
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TDM Structure and Structure-aware Transport . . . . . . . . . 4
3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6
4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9
4.1. UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 9
4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14
4.4. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15
5. TDMoIP Payload Types . . . . . . . . . . . . . . . . . . . . . 17
5.1. AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18
5.2. AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19
5.3. HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20
6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21
7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24
7.1. Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24
7.2. Timing Recovery . . . . . . . . . . . . . . . . . . . . . 25
7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 26
8. Security Considerations . . . . . . . . . . . . . . . . . . . 27
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
10. Applicability Statement . . . . . . . . . . . . . . . . . . . 28
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
Appendix A. Sequence Number Processing (Informative) . . . . . . 30
Appendix B. AAL1 Review (Informative) . . . . . . . . . . . . . . 32
Appendix C. AAL2 Review (Informative) . . . . . . . . . . . . . . 36
Appendix D. Performance Monitoring Mechanisms (Informative) . . . 38
D.1. TDMoIP Connectivity Verification . . . . . . . . . . . . . 38
D.2. OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39
Appendix E. Capabilities, Configuration and Statistics
(Informative) . . . . . . . . . . . . . . . . . . . . 42
References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
Normative References . . . . . . . . . . . . . . . . . . . . . . 45
Informative References . . . . . . . . . . . . . . . . . . . . . 471. Introduction 🦋
Okay so, telephony traffic is traditionally carried over connection-oriented synchronous or plesiochronous links. In this doc we loosely call those TDM circuits 📞 Now that Packet Switched Networks (PSNs) are everywhere, carrying TDM services over PSN infrastructure has become really desirable 😭 You can emulate TDM circuits over the PSN using pseudowires (PWs), as described in the PWE3 architecture [RFC3985]. The emulation has to keep the service quality of native TDM. Voice quality, latency, timing, and signaling features must be similar to what existing TDM networks give you, as described in the TDM PW requirements document [RFC4197]. Basically it has to feel exactly like the real thing 💖
Structure-Agnostic TDM over Packet (SAToP) [RFC4553] is a structure-agnostic protocol for carrying TDM over PSNs 🌸 This document is all about TDMoIP, which is a structure-aware method for TDM transport. Compared to SAToP, structure-aware methods like TDMoIP keep the integrity of the TDM structure, so the PW can handle network degradations better. The individual multiplexed channels become visible, which means you can use per-channel mechanisms for packet loss concealment and bandwidth conservation 🔥 TDM signaling also becomes accessible, which opens the door to mechanisms that exploit or manipulate that signaling. Very powerful, very iconic ✨
Despite its name, the TDMoIP(R) protocol described here may operate over several types of PSN. That includes UDP over IPv4 or IPv6, MPLS, Layer 2 Tunneling Protocol version 3 (L2TPv3) over IP, and pure Ethernet 🧚 The specifics for each PSN are covered in Section 4. Technically, the protocol should be more generally called TDMoPW, and its specific implementations would be TDMoIP, TDMoMPLS, and so on. But the authors kept the name TDMoIP to stay consistent with earlier usage 🫶
The interworking function that connects the TDM and PSN worlds is called a TDMoIP interworking function (IWF), and it may sit at the provider edge (PE) or the customer edge (CE) 👑 The IWF that encapsulates TDM and injects packets into the PSN is the PSN-bound interworking function. The IWF that extracts TDM data from packets and generates traffic on a TDM network is the TDM-bound interworking function. Emulated TDM circuits are always point-to-point and bidirectional, and they carry TDM at the same rate in both directions 💜
As with all PWs, TDMoIP PWs may be configured manually or set up using the PWE3 control protocol [RFC4447]. The extensions to the PWE3 control protocol that are required specifically for setting up and maintaining TDMoIP pseudowires are described in [TDM-CONTROL] 🍓
Okay, 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] 🎀
Part 2 is coming up next, bestie 🌈✨
2. TDM Structure and Structure-aware Transport ✨
okay so TDM circuits can technically carry arbitrary bit-streams, but there are standardized ways to carry constant-length blocks of data called "structures" 🧱 The familiar ones are the T1 or E1 frames [G704], which are 193 and 256 bits long respectively. If you stitch consecutive T1 or E1 frames together, you get higher-level structures called superframes or multiframes 🎀 T3 and E3 frames [G704][G751] are way bigger than T1 and E1, and the GSM Abis channel described in [TRAU] uses even larger structures 😭 TDM structures contain TDM data plus structure overhead. For example, the 193-bit T1 frame has a single bit of structure overhead and 24 bytes of data, while the 32-byte E1 frame has a byte of overhead and 31 data bytes 💖
Structured TDM circuits are super popular for carrying multiplexed channels 🦋 Each channel gets allocated a single byte in the TDM frame, which is called a timeslot. A frame of a channelized T1 carries 24 byte-sized channels, and an E1 frame has 31 channels. TDM frames are sent 8000 times per second, so a single byte-sized channel carries 64 kbps 🔥
TDM structures are universally delimited by a Frame Alignment Signal (FAS), which is an easily detectable periodic bit pattern placed in the structure overhead 🌸 The structure overhead may also hold error monitoring and defect indications. In this doc, "structured TDM" means TDM with any level of structure imposed by an FAS. "Unstructured TDM" is a bit stream with no structure imposed on it, which means all the bits are available for user data 🧚
SAToP [RFC4553] is a structure-agnostic protocol for transporting TDM over PWs 💅 It treats the TDM input as an arbitrary bit-stream and completely ignores any structure that might be in there. So SAToP is ideal for truly unstructured TDM, and it also works for structured TDM when there's no need to protect the structure integrity or to interpret or manipulate individual channels during transport 🍓 SAToP is the go-to technique for PSNs with negligible packet loss, and for apps that don't need to tell channels apart or step in on TDM signaling 🙈
As described in [RFC4553], when a single SAToP packet is lost, an "all ones" pattern gets played out to the TDM interface 💀 The TDM end equipment reads that pattern as an Alarm Indication Signal (AIS), and according to TDM standards [G826], that immediately triggers a "severely errored second" event. Those events are considered highly undesirable, so SAToP is only really suitable for extremely reliable and underutilized PSNs 😭
When you use structure-aware TDM transport, you can explicitly safeguard the TDM structure while it crosses the PSN, which makes it possible to effectively hide packet loss events 🫶 Structure-aware transport uses at least some level of the TDM structure to be more robust against packet loss or other PSN shortcomings ✨ Structure-aware TDM PWs are not required to transport structure overhead across the PSN. In particular, the FAS MAY be stripped by the PSN-bound IWF and MUST be regenerated by the TDM-bound IWF. However, structure overhead MAY be transported over the PSN, since it may carry info other than the FAS 👑
On top of keeping TDM synchronization locked in, structure-aware transport can tell individual timeslots of channelized TDM apart, which unlocks sophisticated packet loss concealment at the channel level 🌈 TDM signaling also becomes visible, so mechanisms can maintain or exploit that info. And by taking advantage of TDM signaling and/or voice activity detection, structure-aware transport makes bandwidth conservation possible 🔥
There are three conceptually distinct methods for ensuring TDM structure integrity: structure-locking, structure-indication, and structure-reassembly 🎀 Structure-locking requires each packet to start at the beginning of a TDM structure and to contain an entire structure or whole multiples of one. Structure-indication lets packets hold arbitrary fragments of basic structures, but uses pointers to show where each structure starts. Structure-reassembly is only defined for channelized TDM: the PSN-bound IWF extracts and buffers individual channels, and the TDM-bound IWF rebuilds the original structure from the received pieces 🧩
All three methods of TDM structure preservation have their perks 🦋 Structure-locking is described in [RFC5086], while this document specifies both structure-indication (see Section 5.1) and structure-reassembly (see Section 5.2). Structure-indication is used when channels may be allocated statically, and/or when you need to interwork with existing circuit emulation systems (CES) based on AAL1. Structure-reassembly is used when dynamic allocation of channels is desirable, and/or when you need to interwork with existing loop emulation systems (LES) based on AAL2 💖
Operation, administration, and maintenance (OAM) mechanisms are vital for proper TDM deployments 🙈 As mentioned earlier, structure-aware mechanisms may hold back from transporting structure overhead across the PSN, which can disrupt OAM functionality 😭 So it's useful to tell apart two OAM cases: "trail terminated" and "trail extended." A trail is the combo of data and its associated OAM information transfer. In the trail terminated case, OAM info like error monitoring and defect indications doesn't get transported over the PSN, and the TDM networks work as separate OAM domains 🧚 In the trail extended case, the OAM info does go over the PSN, though not necessarily in its native format 💅 We'll talk more about OAM in Section 6 🫶
3. TDMoIP Encapsulation ✨
okay so here's the overall shape of a TDMoIP packet, and honestly it's giving layers 💅
+---------------------+
| PSN Headers |
+---------------------+
| TDMoIP Control Word |
+---------------------+
| Adapted Payload |
+---------------------+
Figure 1. Basic TDMoIP Packet FormatThe PSN-specific headers are the ones from UDP/IP, L2TPv3/IP, MPLS, or layer 2 Ethernet. 🧚 They hold everything needed to get the packet from the PSN-bound IWF over to the TDM-bound one. The PSN is assumed to be reliable enough and to have enough bandwidth to carry the TDM data, so no drama there 🫶
A TDMoIP IWF can run multiple TDM PWs at once, and the TDMoIP IWF MUST maintain context information for each TDM PW. 💜 The PWs are told apart by PW labels, which ride along in the PSN-specific layers. TDM is inherently bidirectional, so two PWs going in opposite directions have to be associated with each other, no exceptions 🙈 The PW labels for the two directions MAY take different values, so don't assume they match.
Now the extra bit: an OPTIONAL 12-byte RTP header can show up so the timing info can be sent explicitly 🎀 This is a purely formal reuse of the header format from [RFC3550], and that's it. RTP stuff like header extensions, the contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure RTP (SRTP), etc. is not applicable here. Not me being picky, just facts 💅
The RTP timestamp shows when the packet was created, measured in units of a common clock that both communicating TDMoIP IWFs can see. When there's no common clock, or when the TDMoIP IWFs have local clocks that are accurate enough or can get accurate-enough timing without explicit timestamps, the RTP header SHOULD be omitted. ⭐
If RTP is used, the fixed RTP header described in [RFC3550] MUST immediately follow the control word for all PSN types except UDP/IP, and for UDP/IP it MUST precede the control word. 🦋 The version number MUST be set to 2. The P (padding), X (header extension), CC (CSRC count), and M (marker) fields in the RTP header MUST be set to zero. The payload type (PT) values MUST be allocated from the range of dynamic values. The RTP sequence number MUST be identical to the sequence number in the TDMoIP control word (see below). The RTP timestamp MUST be generated in accordance with the rules established in [RFC3550]. The clock frequency MUST be an integer multiple of 8 kHz, and MUST be chosen to enable timing recovery that conforms with the appropriate standards (see Section 7.2). Very strict, very iconic 👑
The 32-bit control word MUST appear in every TDMoIP packet, no skipping. 🌸 Its format, in conformity with [RFC4385], looks like this:
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| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2. Structure of the TDMoIP Control WordLet's break the control word down, bestie 🍓
RES (4 bits): the first nibble of the control word MUST be set to zero when the PSN is MPLS. This is so the packet doesn't look like an IP packet to forwarding devices doing deep packet inspection, which would be a whole mess 😭 For PSNs other than MPLS, the first nibble MAY be set to zero. Earlier versions of TDMoIP used this field as a format identifier that was optionally used to specify the payload format, so that's the history tea ☕
L Local Failure (1 bit): the L flag is set when the IWF has detected, or been told about, a TDM physical layer fault that's messing with the TDM data being forwarded. In the "trail extended" OAM scenario, the L flag MUST be set when the IWF detects loss of signal, loss of frame synchronization, or AIS. When L is set, the packet contents may not be meaningful, and the payload MAY be suppressed to save bandwidth 🧚 Once it's set, if the TDM fault gets fixed, the L flag MUST be cleared. Use of the L flag is further explained in Section 6.
R Remote Failure (1 bit): the R flag is set when the IWF has detected, or been informed, that TDM data is not being received from the remote TDM network. That means the reverse direction of the bidirectional connection has failed 💔 An IWF SHOULD generate TDM Remote Defect Indicator (RDI) upon receipt of an R flag indication. In the "trail extended" OAM scenario, the R flag MUST be set when the IWF detects RDI. Use of the R flag is further explained in Section 6.
M Defect Modifier (2 bits): using the M field is optional, but when you do use it, it adds detail to what the L flag means 🔥
When L is cleared (meaning the TDM data is valid), the M field works like this:
0 0 indicates no local defect modification.
0 1 reserved.
1 0 reserved.
1 1 reserved.When L is set (meaning the TDM data is invalid), the M field works like this:
0 0 indicates a TDM defect that should trigger conditioning
or AIS generation by the TDM-bound IWF.
0 1 indicates idle TDM data that should not trigger any alarm.
If the payload has been suppressed then the preconfigured
idle code should be generated at egress.
1 0 indicates corrupted but potentially recoverable TDM data.
1 1 reserved.Use of the M field is further explained in Section 6. 🌈
RES (2 bits): these bits are reserved and MUST be set to zero. No freestyling here 🙅♀️
Length (6 bits): this is used to indicate the length of the TDMoIP 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, optional RTP, control word, and payload) is less than 64 bytes, and it MUST be set to zero when not used. 🍓
Sequence number (16 bits): the TDMoIP sequence number gives you the common PW sequencing function described in [RFC3985], and it lets you detect lost and misordered packets 👀 The sequence number space is a 16-bit, unsigned circular space. The initial value of the sequence number SHOULD be random (unpredictable) for security purposes, and its value is incremented modulo 2^16 separately for each PW. Pseudocode for a sequence number processing algorithm that a TDM-bound IWF could use is provided in Appendix A. ✨
Last bit of the section, and it's a good one 🫶 To form the TDMoIP payload, the PSN-bound IWF extracts bytes from the continuous TDM stream, filling each byte from its most significant bit. Those extracted bytes then get adapted using one of two adaptation algorithms (see Section 5), and the resulting adapted payload is placed into the packet. Done and dusted 💖
4. Encapsulation Details for Specific PSNs 🦋
TDMoIP PWs can ride on a bunch of different PSNs, including UDP/IP (both IPv4 and IPv6), L2TPv3 over IP (with no intervening UDP), MPLS, and layer-2 Ethernet. 🌸 In the following subsections, we depict the packet format for these cases.
For MPLS PSNs, the format is aligned with those specified in [Y1413] and [Y1414]. For UDP/IP PSNs, the format is aligned with those specified in [Y1453] and [Y1452]. For transport over layer 2 Ethernet, the format is aligned with [MEF8]. Everything lines up with the standards, which is so clean 💅✨
4.1. UDP/IP ✨
okay so ITU-T recommendation Y.1453 [Y1453] is the one that explains how to carry TDM over IP networks, with structure-agnostic and structure-aware options 💖 and ITU-T recommendation Y.1452 [Y1452] covers the structure-reassembly approach 🧚. the words here are a little different from the ITU's, but implementations of TDMoIP over UDP/IP PSNs will still interoperate with anything built to comply with Y.1453 subclause 9.2.2 or Y.1452 clause 10. bestie, that's the dream 🫶
for UDP/IPv4, you stack the headers from [RFC768] and [RFC791] in front of the TDMoIP data. UDP/IPv6 is basically the same vibe, except it uses the IP header from [RFC2460] instead 🦋 the whole packet looks like Figure 3:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 3. TDMoIP Packet Format for UDP/IP
so the first five rows are the IP header, rows six and seven are the UDP header, rows 8 through 10 are the optional RTP header, and row 11 is the TDMoIP control word 🎀
here's the field tea:
IPVER(4 bits) is the IP version number, so IPVER=4 for IPv4 🌸IHL(4 bits) is the length in 32-bit words of the IP header, and here IHL=5 💅IP TOS(8 bits) is the IP type of service 🍓Total Length(16 bits) is the length in bytes of header and data ✨Identification(16 bits) is the IP fragmentation identification field 🦋Flags(3 bits) are the IP control flags, and they MUST be set to 2 so fragmentation gets avoided 🔥Fragment Offset(13 bits) says where in the datagram the fragment belongs, but it is not used for TDMoIP 🙈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 (17) to signify UDP 👑IP Header Checksum(16 bits) is a checksum for the IP header 🌈Source IP Address(32 bits) is the IP address of the source 💜Destination IP Address(32 bits) is the IP address of the destination 🫶- Source and Destination Port Numbers (16 bits each)
either the source UDP port or the destination UDP port MAY be used to multiplex and demultiplex individual PWs between nodes. architecturally [RFC3985], that makes the UDP port act as the PW Label. PW endpoints MUST agree on using either the source UDP or destination UDP port as the PW Label 🧚
UDP ports MUST be manually configured by both endpoints of the PW. the configured source or destination port (one or the other, never both) together with both the source and destination IP addresses uniquely identify the PW. when the source UDP port is used as the PW label, the destination UDP port number MUST be set to the IANA assigned value of 0x085E (2142). all UDP port values that work as PW labels SHOULD be in the dynamically allocated range, which is 0xC000 through 0xFFFF 🎀
so here's the thing: lots of UDP-based protocols survive middleboxes just fine, but using UDP ports as PW labels makes middlebox traversal way harder 😭 which is why it is NOT RECOMMENDED to use UDP-based PWs where port-translating middleboxes sit between PW endpoints 🚫
UDP Length(16 bits) is the length in bytes of UDP header and data 🌸UDP Checksum(16 bits) is the checksum of the UDP/IP header and data. if it isn't computed, it MUST be set to zero 💖
4.2. MPLS 🧚
ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and structure-aware mechanisms for carrying TDM over MPLS networks 💜 and ITU-T recommendation Y.1414 [Y1413] defines the structure-reassembly mechanisms for this purpose. the terminology is a bit different from the ITU's, but implementations of TDMoIP for MPLS PSNs described here will interoperate with anything designed to comply with Y.1413 subclause 9.2.2 or Y.1414 clause 10 🫶
the MPLS header from [RFC3032] gets prefixed to the control word and TDM payload. the packet structure is Figure 4:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4. TDMoIP Packet Format for MPLS
the first two rows are the MPLS header, and the third is the TDMoIP control word. here are the new fields 🌈
Tunnel Label(20 bits) is the MPLS label that identifies the MPLS LSP used to tunnel the TDM packets through the MPLS network. it can be assigned by manual provisioning or via an MPLS control protocol. while transiting the MPLS network there may be zero, one, or several tunnel label rows. for label stack usage, check [RFC3032] 🍓EXP(3 bits) is an experimental field, which may be used to carry Diffserv classification for tunnel labels ✨S(1 bit) is the stacking bit that indicates MPLS stack bottom. S=0 for all tunnel labels, and S=1 for the PW label 💅TTL(8 bits) is the MPLS Time to live 🦋PW Label(20 bits) MUST be a valid MPLS label, and MAY be configured or signaled 👑
4.3. L2TPv3 💖
the L2TPv3 header defined in [RFC3931] gets prefixed to the TDMoIP data. the packet structure is Figure 5:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID = PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 1 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 5. TDMoIP Packet Format for L2TPv3
rows 6 through 8 are the L2TPv3 header. here are the new fields 🧚
Protocol(8 bits) is the IP protocol field. it must be set to 0x73 (115), the user port number that IANA assigned to L2TP 👑Session ID(32 bits) is the locally significant L2TP session identifier, and it contains the PW label. the value 0 is reserved 🌸Cookie(32 or 64 bits) is an optional field containing a randomly selected value that can be used to validate association of the received frame with the expected PW 🦋
4.4. Ethernet 🦋
okay so Metro Ethernet Forum Implementation Agreement 8 [MEF8] is the one that covers structure-agnostic AND structure-aware ways to move TDM over Ethernet networks 🌐. the big win here is that structure-indicated TDMoIP implementations will interoperate with anything built to comply with MEF 8 Section 6.3.3 🤝 bestie, that's the whole vibe.
The TDMoIP payload gets wrapped in an Ethernet frame by slapping on the destination and source MAC addresses, an optional VLAN header, and the Ethertype, then suffixing the four-byte frame check sequence 💅. TDMoIP implementations MUST be able to receive both industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames, and they SHOULD transmit Ethernet frames 🎀.
Ethernet also has size limits on BOTH ends 🙈. Whenever the entire TDMoIP packet is less than 64 bytes, padding gets added and the true length is indicated by using the Length field in the control word. To avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, a UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet has an Ethernet payload length of 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes ✨.
Ethernet frames MAY be used for TDMoIP transport without intervening IP or MPLS layers, however, an MPLS-style label MUST always be present 🧚. In this four-byte header S=1, and all other non-label bits are reserved (set to zero in the PSN-bound direction and ignored in the TDM-bound direction). The Ethertype SHOULD be set to 0x88D8 (35032), the value the IEEE allocated for this purpose, but MAY be set to 0x8847 (34887), which is the Ethertype of MPLS. Here's the overall frame structure 👑:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination MAC Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address (cont) | VLAN Ethertype (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VLP|C| VLAN ID (opt) | Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | RES |1| RES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 6. TDMoIP Packet Format for EthernetRows 1 through 6 are the (DIX) Ethernet header. For 802.3 there may be additional fields, depending on the value of the length field, see [IEEE802.3]. Now let's break down the fields that haven't been explained yet 🔍.
Destination MAC Address(48 bits) is the globally unique address of a single station that is to receive the packet. The format is defined in [IEEE802.3].Source MAC Address(48 bits) is the globally unique address of the station that originated the packet. The format is defined in [IEEE802.3].VLAN Ethertype(16 bits): 0x8100 in this position indicates that optional VLAN tagging specified in [IEEE802.1Q] is employed, and that the next two bytes contain the VLP, C, and VLAN ID fields. VLAN tags may be stacked, in which case the two-byte field following the VLAN ID is once again a VLAN Ethertype.VLP(3 bits) is the VLAN priority, see [IEEE802.1Q].C(1 bit): the "canonical format indicator" being set indicates that route descriptors appear, see [IEEE802.1Q].VLAN ID(12 bits): the VLAN identifier uniquely identifies the VLAN to which the frame belongs. If zero, only the VLP information is meaningful. Values 1 and FFF are reserved. The other 4093 values are valid VLAN identifiers.Ethertype(16 bits) is the protocol identifier, as allocated by the IEEE. The Ethertype SHOULD be set to 0x88D8 (35032), but MAY be set to 0x8847 (34887).PW Label(20 bits): this label MUST be manually configured. The remainder of this row is formatted to resemble an MPLS label.Frame Check Sequence(32 bits) is a Cyclic Redundancy Check (CRC) error detection field, calculated per [IEEE802.3].
5. TDMoIP Payload Types 💜
As discussed at the end of Section 3, TDMoIP transports real-time streams by first extracting bytes from the stream, and then adapting those bytes 🌸. TDMoIP offers two different adaptation algorithms: one for constant-rate real-time traffic, and one for variable-rate real-time traffic.
For unstructured TDM, or structured but unchannelized TDM, or structured channelized TDM with all channels active all the time, you need a constant-rate adaptation. In those cases TDMoIP uses structure-indication to emulate the native TDM circuit, and the adaptation is known as "circuit emulation" ⏱️. BUT, for channelized TDM where the individual channels (the "loops" in telephony terminology) are frequently inactive, you can conserve bandwidth by transporting only the active channels 🫶. That gives you variable-rate real-time traffic, so TDMoIP uses structure-reassembly to emulate the individual loops, and the adaptation is known as "loop emulation".
TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation, while variable-rate AAL2 [AAL2] is used for loop emulation. The AAL1 mode MUST be used for structured transport of unchannelized data and SHOULD be used for circuits with relatively constant usage. In addition, AAL1 MUST be used when the TDM-bound IWF is required to maintain a high timing accuracy (e.g., when its timing is further distributed), and SHOULD be used when high reliability is required. AAL2 SHOULD be used for channelized TDM when bandwidth needs to be conserved, and MAY be used whenever usage of voice-carrying channels is expected to be highly variable 🎧.
Also, a third mode is defined specifically for efficient transport of High-Level Data Link Control (HDLC)-based Common Channel Signaling (CCS) carried in TDM channels 🍓.
The AAL family of protocols is a natural choice for TDM emulation 🥰. Originally they were developed to adapt various types of application data to the rigid format of ATM, but the mechanisms are general solutions to the problem of transporting constant or variable-rate real-time streams over a packet network.
Since the AAL mechanisms are extensively deployed within and on the edge of the public telephony system, they have been demonstrated to reliably transfer voice-grade channels, data and telephony signaling 📞. These mechanisms are mature and well understood, and implementations are readily available.
Finally, simplified service interworking with legacy networks is a major design goal of TDMoIP. Re-using AAL technologies simplifies interworking with existing AAL1- and AAL2-based networks 🌈.
5.1. AAL1 Format Payload 🎀
For the prevalent cases of unchannelized TDM, or channelized TDM for which the channel allocation is static, the payload can be efficiently encoded using constant-rate AAL1 adaptation ✨. The AAL1 format is described in [AAL1], and its use for circuit emulation over ATM in [CES]. We briefly review highlights of AAL1 technology in Appendix B. In this section we describe the use of AAL1 in the context of TDMoIP.
+-------------+----------------+
|control word | AAL1 PDU |
+-------------+----------------+
Figure 7a. Single AAL1 PDU per TDMoIP Packet
+-------------+----------------+ +----------------+
|control word | AAL1 PDU |---| AAL1 PDU |
+-------------+----------------+ +----------------+
Figure 7b. Multiple AAL1 PDUs per TDMoIP PacketIn AAL1 mode the TDMoIP payload consists of at least one, and perhaps many, 48-byte "AAL1 PDUs", see Figures 7a and 7b 📦. The number of PDUs MUST be pre-configured and MUST be chosen such that the overall packet size does not exceed the maximum allowed by the PSN (e.g., 30 for UDP/IP over Ethernet). The precise number of PDUs per packet is typically chosen taking latency and bandwidth constraints into account. Using a single PDU delivers minimal latency, but incurs the highest overhead. All TDMoIP implementations MUST support between 1 and 8 PDUs per packet for E1 and T1 circuits, and between 5 and 15 PDUs per packet for E3 and T3 circuits 💀.
AAL1 differentiates between unstructured and structured data transfer, which correspond to structure-agnostic and structure-aware transport 🧠. For structure-agnostic transport, AAL1 provides no inherent advantage as compared to SAToP; however, there may be scenarios where its use is desirable. For example, when it is necessary to interwork with an existing AAL1 ATM circuit emulation system, or when clock recovery based on AAL1-specific mechanisms is favored.
For structure-aware transport, [CES] defines two modes: structured, and structured with Channel Associated Signaling (CAS). Structured AAL1 maintains TDM frame synchronization by embedding a pointer to the beginning of the next frame in the AAL1 PDU header. Similarly, structured AAL1 with CAS maintains TDM frame and multiframe synchronization by embedding a pointer to the beginning of the next multiframe. Furthermore, structured AAL1 with CAS contains a substructure including the CAS signaling bits 🫧.
5.2. AAL2 Format Payload
okay so AAL1 can be set up for fractional E1 or T1 circuits, but the channel allocation has to be static 😭 because AAL1 is all about constant-rate bit-streams, so it just keeps sending no matter what. the thing is, not every channel in a TDM circuit is active at once ("off-hook") 📞, and you can tell which ones are by watching the TDM signaling channel 👀. even during actual calls, about half the time is silence, and voice activity detection (VAD) can pick that up 🤫. so with the variable-rate AAL2 mode, we can allocate channels dynamically and save bandwidth. the way that's giving efficiency 🦋
The AAL2 format is described in [AAL2] and its use for loop emulation over ATM is explained in [SSCS,LES]. we briefly review highlights of AAL2 technology in Appendix C. in this section, we describe the use of AAL2 in the context of TDMoIP 🎀
+-------------+----------------+ +----------------+
|control word | AAL2 PDU |---| AAL2 PDU |
+-------------+----------------+ +----------------+Figure 8. Concatenation of AAL2 PDUs in a TDMoIP Packet
ok so in AAL2 mode, the TDMoIP payload is one or more variable-length "AAL2 PDUs" ✨ (see Figure 8). each AAL2 PDU has 3 bytes of overhead and between 1 and 64 bytes of payload. you can stuff a packet with PDUs for all the active channels, or append the PDUs that are ready at a certain time, or do it any other way you like 💅 which means more than one PDU from the same channel can show up in a single packet. main character energy 👑
[RFC3985] calls all processing of the TDM data before it becomes payload Native Service Processing (NSP) functions 🧚. and since AAL2 is inherently variable rate, arbitrary NSP functions MAY be performed before the channel is placed in the AAL2 loop emulation payload. that includes checking on-hook/off-hook status, voice activity detection, speech compression, fax/modem/tone relay, and so on 🌸
All mechanisms described in [AAL2,SSCS,LES] may be used for TDMoIP 💖 specifically, channel identifier (CID) encoding and use of PAD octets according to [AAL2], encoding formats defined in [SSCS], and transport of CAS and CCS signaling as described in [LES] MAY all be used in the PSN-bound direction, and MUST be supported in the TDM-bound direction. the overlap functionality and AAL-CU timer and related functionalities may not be required, and the STF (start field) is NOT used 🙈 computing the error detection codes (the Header Error Check (HEC) in the AAL2 PDU header and the CRC in the CAS packet) is superfluous if the PSN already provides an appropriate error detection mechanism. in those cases, these fields MAY be set to zero 🍓
5.3. HDLC Format Payload
the whole reason HDLC is handled in TDMoIP is to efficiently transport common channel signaling (CCS) like SS7 [SS7] or ISDN PRI signaling [ISDN-PRI] that's embedded in the TDM stream 📡 this mechanism is NOT meant for general HDLC payloads, and it assumes the HDLC messages are always shorter than the maximum packet size. no cap, that's a big assumption 😅
the HDLC mode should only be used when the majority of the bandwidth of the input HDLC stream is expected to be occupied by idle flags. otherwise, the CCS channel should be treated as an ordinary channel 🌈
the HDLC format is intended to operate in port mode, transparently passing all HDLC data and control messages over a separate PW ✨ the encapsulation is compatible with that of [RFC4618], however the sequence number generation and processing SHOULD be performed according to Section 3 above 🫶
the PSN-bound IWF monitors flags until a frame is detected. the contents of the frame get collected and the Frame Check Sequence (FCS) is tested. if the FCS is incorrect, the frame is discarded. otherwise, the frame is sent after the initial or final flags and FCS have been discarded and zero removal has been performed 💅 when a TDMoIP-HDLC frame is received, its FCS is recalculated, and the original HDLC frame is reconstituted. ta-da 🎀
6. TDMoIP Defect Handling ✨
okay so native TDM networks signal network faults by carrying indications of forward defects (AIS) and reverse defects (RDI) in the TDM bit stream 📶 structure-agnostic TDM transport carries all of those indications transparently 🫶 however, for structure-aware mechanisms where the PSN-bound IWF may remove the TDM structure overhead that carries defect indications, explicit signaling of TDM defect conditions is required 😭
we saw in Section 3 that defects can be indicated by setting flags in the control word 🚩 putting defect reporting into the packet instead of a separate stream copies how native TDM OAM mechanisms carry those indications as bit patterns inside the TDM stream, which is so iconic 🦋 the flags are designed for urgent messaging, meaning messages whose contents must not be significantly delayed relative to the TDM data they could affect. mechanisms for slow OAM messaging are discussed in Appendix D 🌸
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
|TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM|
| | |TDM 1| | | | PSN | | | |TDM 2| | |
|ES1|-<-| |-<-| IWF1 |-<-| |-<-| IWF2 |-<-| |-<-|ES2|
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+Figure 9. Typical TDMoIP Network Configuration
the best way to get TDMoIP defect handling is to follow the downstream TDM flow 🧭 from TDM end system 1 (ES1), through TDM network 1, through TDMoIP IWF 1 (IWF1), through the PSN, through TDMoIP IWF 2 (IWF2), through TDM network 2, and on toward TDM end system 2 (ES2), like the figure shows. we want to detect defects in TDM network 1, the PSN, and TDM network 2, but we also want to localize them so alarms only go off in the right network 🚨
in the "trail terminated" OAM scenario, only user data gets exchanged between TDM network 1 and TDM network 2 🤝 the IWF acts as a TDM trail termination function, so defects detected in TDM network 1 are not relayed to network 2, or the other way around.
in the "trail extended" OAM scenario, if there's a defect (for example, loss of signal or loss of frame synchronization) anywhere in TDM network 1 before the ultimate link, the following TDM node will generate AIS downstream (toward TDMoIP IWF1) 😬 if a break happens in the ultimate link, the IWF itself detects the loss of signal. either way, IWF1 has either directly detected that the TDM signal isn't valid, or has been told about an earlier problem, so it raises the local ("L") defect flag in the control word of the packets it sends across the PSN 🏳️ this is how the trail gets extended to TDM network 2 across the PSN.
reverse defect indications are different from forward ones because only trail termination functions generate them 💀 forward defects are generated by all network elements. in the trail terminated scenario, IWF1 is a trail termination function for TDM network 1, so when it directly detects that the TDM signal isn't valid or is informed of an earlier problem, it MAY generate TDM RDI towards TDM ES1. in the trail extended scenario, IWF1 is not a trail termination, so it MUST NOT generate TDM RDI. instead, as we've seen, it sets the L defect flag. and here's the payoff: this makes the AIS indication reach ES2, which is the trail termination, and ES2 MAY generate TDM RDI ✨
when the L flag is set, there are four ways to treat the payload content 🎀 the default is for IWF1 to fill the payload with the appropriate amount of AIS (usually all-ones) data. if the AIS was generated before the IWF, this can be done by copying the received TDM data. if the penultimate TDM link fails, the IWF needs to generate the AIS itself. alternatively, with structure-aware transport of channelized TDM, one SHOULD fill the payload with "trunk conditioning" 🧁 this means putting a preconfigured "out of service" code in each individual channel (and the "out of service" code may differ between voice and data channels). trunk conditioning MUST be used when channels taken from several TDM PWs are combined by the TDM-bound IWF into a single TDM circuit 🚫 the third option is to suppress the payload altogether. and finally, if IWF1 believes the TDM defect is minor or correctable (for example, loss of multiframe synchronization, or the early phases of detecting incorrect frame sync), it MAY place the TDM data it received into the payload field and specify in the defect modification field ("M") that the TDM data is corrupted but potentially recoverable 🩹
when IWF2 receives a local defect indication without M field modification, it forwards AIS or trunk conditioning toward ES2 (or generates it, if the payload has been suppressed). the choice between AIS and conditioning is preconfigured 🛠️ so AIS has been properly delivered to ES2, emulating the TDM scenario from the TDM end system's point of view. on top of that, IWF2 receiving the L flag specifically tells us the defect was in TDM network 1 and not in TDM network 2, which means alarms in the correctly functioning network get suppressed 🤫✨
if the M field says the TDM has been marked as potentially recoverable, then implementation specific algorithms (not specified here) may optionally be used to minimize the impact of transient defects on overall network performance 🧠 if the M field says the TDM is "idle", no alarms should be raised, and IWF2 treats the payload contents as regular TDM data. if the payload has been suppressed, IWF2 MUST generate trunk conditioning, and not AIS 💅
the second case is when the defect is in TDM network 2. those defects cause AIS generation toward ES2, which may respond by sending TDM RDI in the reverse direction 😤 in the trail terminated scenario, this RDI stays restricted to network 2. in the trail extended scenario, when IWF2 observes this RDI inserted into valid TDM data, it MUST indicate that by setting the "R" flag in packets sent back across the PSN toward IWF1. when IWF1 receives that indication, it generates RDI toward ES1, which emulates one single conventional TDM network 🌈
the final possibility is a unidirectional defect in the PSN 🌊 in that case, TDMoIP IWF1 sends packets toward IWF2, but they never get received. IWF2 MUST inform the PSN's management system of this problem, and also generate TDM AIS toward ES2. ES2 may respond with TDM RDI, and just like before, in the trail extended scenario, when IWF2 detects RDI it MUST raise the "R" flag indication. when IWF1 receives packets with the "R" flag set, it has been informed of a reverse defect, and it MUST generate TDM RDI toward ES1 💖
in all cases, if any of the above defects persist for a preconfigured period (default value of 2.5 seconds), a service failure is declared ⏱️ since TDM PWs are inherently bidirectional, a persistent defect in either direction results in a bidirectional service failure. also, if signaling is sent over a distinct PW as per Section 5.3, both PWs are considered to have failed when persistent defects are detected in either one 😬
when failure is declared, the PW MUST be withdrawn, and both TDMoIP IWFs commence sending AIS (and not trunk conditioning) to their respective TDM networks. the IWFs then engage in connectivity testing using native methods or TDMoIP OAM, as described in Appendix D, until connectivity is restored 🆘
7. Implementation Issues ✨
okay so the general rules for moving TDM over pseudo-wires are all written up in [RFC4197] 📚 down below we're covering the extra stuff that's basically essential if you want TDMoIP to actually work in the real world 💅
7.1. Jitter and Packet Loss
okay first things first 🫶 a jitter buffer MUST be provided. it's basically a block of memory where the data from the PSN gets written in at its messy, variable arrival rate, and then it gets read out and sent to the destination TDM equipment at a steady, constant rate. the jitter buffer kinda hides the fact that the data went through a PSN instead of a normal synchronous TDM network, except for the extra latency 🙈 the usual move is to keep the buffer about half full, so it's less likely to overflow or run dry. that means the extra delay equals half the jitter buffer size. the length of the jitter buffer SHOULD be configurable and MAY be dynamic (aka it can grow and shrink based on the stats of the Packet Delay Variation (PDV)) ✨
next, a packet sequence integrity mechanism MUST be provided 🔥 to deal with the (infrequent) packet loss and misordering. this mechanism MUST track the serial numbers of arriving packets and MUST take appropriate action when anomalies show up. when lost packets are detected, the mechanism MUST output filler data so the TDM timing stays intact. packets that show up in the wrong order SHOULD be reordered. lost packet processing SHOULD also make sure proper FAS gets sent to the TDM network. there's an example sequence number processing algorithm in Appendix A if you wanna peek 👀
filler data can keep the TDM timing going, but for telephony traffic it can cause audio gaps or artifacts. that's how you end up with choppy, annoying, or even unintelligible audio 😭 so an implementation MAY blindly insert a preconfigured constant value in place of any lost samples, and this value SHOULD be chosen to minimize the perceptual effect. alternatively, you MAY replay the previously received packet 🦋 and when computational resources are available, implementations SHOULD conceal the packet loss event by estimating the missing sample values in a way that minimizes the perceptual error. big brain energy 🧠✨
7.2. Timing Recovery
TDM networks are inherently synchronous, so somewhere in the network there's always at least one extremely accurate primary reference clock, with long-term accuracy of one part in 1E-11 🌈 that node gives reference timing to secondary nodes, which have somewhat lower accuracy, and those secondary nodes pass the timing info further along. this hierarchy of time synchronization is essential for the whole network to work properly. for the details, see [G823][G824] 📚
packets in PSNs reach their destination with a delay that has a random component, known as packet delay variation (PDV) 🌸 when we're emulating TDM on a PSN, pulling data out of the jitter buffer at a constant rate smooths out a lot of the high frequency randomness ("jitter"). the rate we pull data out of the jitter buffer is set by the destination clock. if that matched the source clock exactly, the timing would stay perfect. unfortunately, the source clock info doesn't get disseminated through a PSN, so the destination clock frequency will only nominally equal the source clock frequency. that leads to low frequency timing inaccuracies called "wander" 😩
there are basically four ways to get around this problem 💖 in the first and second methods, timing info comes from somewhere independent of the PSN. that timing can be handed to the TDM end systems (method 1) or to the IWFs (method 2). in the third method, a common clock is assumed to be available to both IWFs, and the relationship between the TDM source clock and that common clock gets encoded in the packet. that encoding can take the form of RTP timestamps, or it can use the synchronous residual timestamp (SRTS) bits in the AAL1 overhead. in the final method, adaptive clock recovery, the timing has to be figured out purely from packet arrival times. you can see example scenarios in [RFC4197] and [Y1413] 🦋
adaptive clock recovery only uses observable stuff from the packets coming in from the PSN, like the precise time a packet arrives at the TDM-bound IWF, or the fill level of the jitter buffer over time. because of the packet delay variation in the PSN, you need filtering processes to handle the statistical nature of those observables. Frequency Locked Loops (FLL) and Phase Locked Loops (PLL) are a great fit for that job 👑
no matter which timing recovery mechanism you use, the output of the TDM-bound IWF MUST conform to the jitter and wander specs for TDM traffic interfaces, as defined in [G823][G824]. for some applications, more stringent jitter and wander tolerances MAY be imposed 💅
7.3. Congestion Control
as [RFC3985] explains, the underlying PSN might get congested 🚨 unless you take proper precautions, TDMoIP's undiminished demand for bandwidth can add to network congestion, and that can mess with network control protocols. not it 💀
the AAL1 mode of TDMoIP is an inelastic constant bit-rate (CBR) flow. it can't respond to congestion in the TCP-friendly way prescribed by [RFC2914], although the percentage of total bandwidth it consumes stays constant. the AAL2 mode is variable bit-rate (VBR), and it's often possible to reduce the bandwidth it eats by using mechanisms that are outside the scope of this document 🌈
whenever possible, TDMoIP SHOULD be carried across traffic-engineered PSNs. those are PSNs that offer either bandwidth reservation and admission control, or forwarding prioritization and boundary traffic conditioning. examples include IntServ-enabled domains supporting Guaranteed Service (GS) [RFC2212], and Diffserv-enabled domains [RFC2475] supporting Expedited Forwarding (EF) [RFC3246]. these mechanisms will negate, to some degree, the effect TDMoIP has on neighboring streams ✨ and to make boundary traffic conditioning of TDMoIP traffic over IP PSNs easier, the TDMoIP packets SHOULD NOT use the Diffserv Code Point (DSCP) value reserved for the Default Per-Hop Behavior (PHB) [RFC2474] 🎀
when TDMoIP runs over a PSN providing best-effort service, packet loss SHOULD be monitored to detect congestion. if congestion is detected and bandwidth reduction is possible, that reduction SHOULD be enacted. if bandwidth reduction isn't possible, the TDMoIP PW SHOULD shut down bi-directionally for some period of time, as described in Section 6.5 of [RFC3985] 🥺
a few things to keep in mind 🧚
- in AAL1 mode, TDMoIP can inherently measure packet loss, since the expected rate of packet arrival is fixed and known.
- the results of the packet loss measurement might not be a reliable sign of whether severe congestion is present or absent if the PSN provides enhanced delivery. for example, if TDMoIP traffic takes precedence over other traffic, severe congestion may not significantly affect TDMoIP packet loss 🙃
- the TDM services emulated by TDMoIP have high availability objectives (see [G826]) that MUST be taken into account when deciding on a temporary shutdown 💜
this spec doesn't define exact criteria for detecting severe congestion, or specific methods for shutting TDMoIP down or restarting it afterwards. however, these considerations may be used as guidelines for implementing the shutdown mechanism 🍓
- if the TDMoIP PW was set up using the PWE3 control protocol [RFC4447], the regular PW teardown procedures of those protocols SHOULD be used.
- if one of the TDMoIP IWFs stops sending packets for a long enough period, its peer (seeing 100% packet loss) will necessarily detect "severe congestion" and also stop transmitting, which gets you bi-directional PW shutdown 🌸
TDMoIP doesn't have mechanisms to ensure timely delivery or any other quality-of-service guarantees, so it's required that the lower-layer services handle that 💅 layer 2 priority can be given to a TDMoIP stream using the VLAN priority field, MPLS priority can come from the EXP bits, and layer 3 priority is controllable using TOS. switches and routers that the TDMoIP stream has to traverse should be configured to respect those priorities 🫶
8. Security Considerations ✨
⚠️ this section is serious business, bestie. please read every word 🚨
TDMoIP doesn't enhance or detract from the security performance of the underlying PSN. instead, it relies on the PSN's own mechanisms for encryption, integrity, and authentication whenever they're required. the level of security provided may be less than what you'd get with a native TDM service 😬
when the PSN is MPLS, PW-specific security mechanisms MAY be required 🔐 while for IP-based PSNs, IPsec [RFC4301] MAY be used. TDMoIP using L2TPv3 is subject to the security considerations discussed in Section 8 of [RFC3931] 🧷
TDMoIP shares susceptibility to a number of pseudowire-layer attacks (see [RFC3985]), so implementations SHOULD use whatever mechanisms for confidentiality, integrity, and authentication are developed for general PWs 💖 those methods are beyond the scope of this document.
random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted TDMoIP more difficult 🎀 encryption of PWs is beyond the scope of this document.
PW labels SHOULD be selected in an unpredictable manner, rather than sequentially or in some other predictable way, to deter session hijacking 🕵️♀️ when using L2TPv3, a cryptographically random [RFC4086] Cookie SHOULD be used to protect against off-path packet insertion attacks. and a 64-bit Cookie is RECOMMENDED for protection against brute-force, blind, insertion attacks 👑
even though TDMoIP MAY employ an RTP header when explicit transfer of timing information is required, SRTP (see [RFC3711]) mechanisms are not applicable 🙅♀️
9. IANA Considerations 🌈
for MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446] 🦋
for UDP/IP PSNs, when the source port is used as the PW label, the destination port number MUST be set to 0x085E (2142), the user port number IANA assigned to TDMoIP 💜
10. Applicability Statement 💅✨
Okay bestie, real talk: TDMoIP is really good, but it's not a perfect copy of the native TDM circuit, and it's important to know where it's different. 🫶
The end-to-end delay of a TDM circuit emulated with TDMoIP can be longer than the delay on a native TDM circuit. 🐢
If you use adaptive clock recovery, the timing of the emulated circuit depends on what the PSN is like, so it might be worse than a native TDM circuit. 😬
If the TDM structure overhead isn't carried over the PSN, then any non-FAS data in that overhead is gone. Bye bye 👋
When packets get lost in the PSN, TDMoIP's mechanisms keep frame synchronization going. When the loss is properly concealed, telephony channels sound basically the same to people's ears. ☎️🎀 But the bit error rate is worse than on the native service, so keep that in mind. 🙈
Data in inactive channels doesn't get transported in AAL2 mode, so that data will be different from what you'd get on the native service. 🌸
Last but not least, native TDM connections are point-to-point, but PSNs are shared infrastructure. So the security of the emulated service might be lower than the native one. Main character energy for the attackers, not for us 💀🔐
11. Acknowledgments 🫶🌈
The authors want to give a huge shoutout to Hugo Silberman, Shimon HaLevy, Tuvia Segal, and Eitan Schwartz of RAD Data Communications. Their contributions to the technology described here were absolutely invaluable 👑💖
Appendix A. Sequence Number Processing (Informative) 🧚📦
Okay, so the sequence number field in the control word is what lets you spot lost and misordered packets. 🔍 This appendix gives pseudocode for an example algorithm so the issues are clearer. These issues are implementation specific, though, and no single explanation covers every possibility, so don't panic if your implementation does things a little differently 🤷♀️
To keep things simple, modulo arithmetic is used everywhere instead of special handling for the wraparound. All differences between indexes are explicitly converted to the range [-2^15 ... +2^15 - 1], so checking the sign of the difference correctly tells you the arrival order. 🧮✨
We also introduce a playout buffer so we can define packet lateness without any ambiguity. When a packet shows up after it was already assumed lost, the TDM-bound IWF may throw it away and keep treating it as lost. 🗑️ Or, if the filler data that was put in its place hasn't been played out yet, you can choose to put the real data into the playout buffer instead 💅 The filler data can be generated when the missing packet is first detected, or when it's played out. 🎀
This description is written in terms of a packet-oriented playout buffer instead of a TDM byte-oriented one. Still, this isn't a strict requirement for re-ordering implementations, because the byte-oriented version could work too, as long as you use pointers to packet start points. 🧠
Now that the playout buffer is introduced, we explicitly cover over-run and under-run. Over-run happens when packets arrive so fast that they can't be stored for playout. That's usually a sign of serious timing inaccuracy or misconfiguration, and honestly, we can't do much except discard those early packets 😭 Under-run is usually a sign of network starvation, caused by congestion or a network failure 🌧️
Here are the external variables the pseudocode uses:
received: sequence number of packet received
played: sequence number of the packet being played out (Note 1)
over-run: is the playout buffer full? (Note 3)
under-run: has the playout buffer been exhausted? (Note 3)And the internal variables:
expected: sequence number we expect to receive next
D: difference between expected and received (Note 2)
L: difference between sequence numbers of packet being played out
and that just received (Notes 1 and 2)The algorithm also needs one parameter:
R: maximum lateness for a packet to be recoverable (Note 1).
Note 1: this is only required for the optional re-ordering
Note 2: this number is always in the range -2^15 ... +2^15 - 1
Note 3: the playout buffer is emptied by the TDM playout process,
which runs asynchronously to the packet arrival processing,
and which is not herein specifiedHere's the Sequence Number Processing Algorithm itself 🦋
Sequence Number Processing Algorithm
Upon receipt of a packet
if received = expected
{ treat packet as in-order }
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else
calculate D = ( (expected-received) mod 2^16 ) - 2^15
if D > 0 then
{ packets expected, expected+1, ... received-1 are lost }
while not over-run
place filler (all-ones or interpolation) into playout buffer
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else { late packet arrived }
declare "received" to be a late packet
do NOT update "expected"
either
discard packet
or
if not under-run then
calculate L = ( (played-received) mod 2^16 ) - 2^15
if 0 < L <= R then
replace data from packet previously marked as lost
else
discard packetNote: by choosing R=0 we always discard the late packet 🥺
Appendix B. AAL1 Review (Informative) 🎀
okay bestie, let's talk AAL1 🫶 the first byte of the 48-byte AAL1 PDU always has an error-protected 3-bit sequence number ✨
1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P| 47 bytes of payload
+-+-+-+-+-+-+-+-+-----------------------C(1 bit) is the convergence sublayer indication. Here it's only used to say whether a pointer is there.C=0means no pointer,C=1means a pointer is present 💅SN(3 bits) is the AAL1 sequence number, and it goes up from PDU to PDU 🔥CRC(3 bits) is a 3-bit error cyclic redundancy code onCandSN🧚P(1 bit) is even byte parity 💜
Okay, so incrementing the sequence number makes an eight-PDU sequence number cycle, and that's going to matter SO much in a sec 👑
The other 47 bytes depend on the PDU type. There are three, matching the three types of AAL1 circuit emulation service defined in [CES]: unstructured circuit emulation, structured circuit emulation, and structured circuit emulation with CAS 🌈
The simplest one is the unstructured PDU, used for transparent transfer of whole circuits (T1,E1,T3,E3). AAL1 doesn't give you any inherent advantage over SAToP for unstructured transport 🙈 but in certain cases AAL1 may be required or desirable. For example, when you need to interwork with an existing AAL1-based network, or when clock recovery based on AAL1-specific mechanisms is favored. Main character energy for sure 🎀
For unstructured AAL1, the 47 bytes after the sequence number byte hold the full 376 bits from the TDM bit stream. No frame synchronization is supplied or implied, so framing is the sole responsibility of the end-user equipment 🫶 That's why unstructured mode can carry data, and circuits with nonstandard frame synchronization. For T1, the raw frame is 193 bits, so 1 183/193 T1 frames fit into each AAL1 PDU ✨ For E1, the frame is 256 bits, so 1 15/32 E1 frames fit into each PDU 🍓
When the TDM circuit is channelized according to [G704], and especially when you want fractional E1 or T1, it's advantageous to use one of the structured AAL1 circuit emulation services 🦋 Structured AAL1 doesn't just see the data as a bit stream. It sees a bundle of channels. Plus, when CAS signaling is used, it can be formatted so it's easy to detect and manipulate 💖
In structured circuit emulation without CAS, N bytes from the N channels being transported are first arranged in order of channel number. So if channels 2, 3, 5, 7 and 11 are being transported, the five corresponding bytes go into the PDU right after the sequence number byte. This placement repeats until all 47 bytes in the PDU are filled 🌸
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3The next PDU picks up exactly where this one left off 🧚
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7And so on and so forth 💅 The set of channels 2,3,5,7,11 is the basic structure, and the point where one structure ends and the next starts is the structure boundary ✨
Now the tea ☕ The problem with this setup is there's no explicit indication of which byte is which channel. As you can see above, each AAL1 PDU starts with a different channel, so one lost packet will misidentify channels from that point onwards, with no way to recover 😭 The fix is to periodically introduce a pointer to the next structure boundary. You don't need to use the pointer very often, since the channel identifications are uniquely inferable unless packets get lost 🫶
AAL1 inserts a pointer once every sequence number cycle of eight PDUs. The pointer is seven bits, protected by an even parity MSB (most significant bit), so it fits in a single byte. Seven bits are enough to represent offsets larger than 47, so the pointer byte only goes in PDUs with even sequence numbers 🎀 Unlike most AAL1 PDUs, which carry 47 TDM bytes, PDUs that contain a pointer (P-format PDUs) look like this 👑
0 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P|E| pointer | 46 bytes of payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------where:
C(1 bit) is the convergence sublayer indication, andC=1for P-format PDUs 🌈SN(3 bits) is an even AAL1 sequence number 💖CRC(3 bits) is a 3-bit error cyclic redundancy code onCandSN🔥P(1 bit) is even byte parity LSB (least significant bit) for the sequence number byte 🦋E(1 bit) is even byte parity MSB for the pointer byte 🍓pointer(7 bits) is the pointer to the next structure boundary ✨
P-format PDUs have 46 bytes of payload and the next PDU has 47, so viewed as one entity, the pointer needs to indicate one of 93 bytes 🧮 If P=0, the structure starts with the following byte (so the first payload byte belongs to the lowest numbered channel). P=93 means the last byte of the second PDU is the final byte of the structure, and the following PDU starts a new structure 💅 The special value P=127 means there's no structure boundary to indicate, which is needed when extremely large structures are being transported 🙈
The P-format PDU always goes in the first possible position in the sequence number cycle where a structure boundary occurs, and it can only occur once per cycle 🫶
The only difference between structured circuit emulation and structured circuit emulation with CAS is how the structure is defined. In structured circuit emulation, the structure is made of the N channels. In structured circuit emulation with CAS, the structure covers the superframe, which is multiple repetitions of the N channels followed by the CAS signaling bits. The CAS bits are tightly packed into bytes, and the final byte is padded with zeros if needed 🌸
For example, for E1 circuits the CAS signaling bits are updated once per superframe of 16 frames. So the structure for N*64 derived from an E1 with CAS signaling is 16 repetitions of N bytes, followed by N sets of the four ABCD bits, and finally four zero bits if N is odd. For instance, the structure for channels 2, 3 and 5 looks like this 🧚
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000]T1 ESF circuits work a bit differently. The superframe is 24 frames, and the structure is 24 repetitions of N bytes, followed by the ABCD bits as before. For T1, the signaling bits will generally appear twice: in their regular (bit-robbed) positions, and at the end of the structure 🦋
Appendix C. AAL2 Review (Informative) 🌈
hey hey, time for AAL2 🧚 here's the basic AAL2 PDU ✨
| Byte 1 | Byte 2 | Byte 3 |
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
| CID | LI | UUI | HEC | PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------CID(8 bits) is the channel identifier, and it has to be unique for the PW 💖 Values 0-7 are reserved for special purposes. If you need to interwork with VoDSL, values 8 through 15 are reserved too, as specified in [LES]. That leaves 248 (240) CIDs per PW 🔥 The mapping of CID values to channels MAY be manually configured manually or signaled 🌸LI(6 bits) is the length indicator, one less than the length of the payload in bytes. The payload is limited to 64 bytes 🍓UUI(5 bits) is the user-to-user indication, the higher layer (application) identifier and counter. For voice data, the UUI is always in the range 0-15, and it SHOULD be incremented modulo 16 each time a channel buffer is sent. The receiver MAY monitor this sequence. UUI is set to 24 for CAS signaling packets 💅HEC(5 bits) is the header error control 🫶
Payload - voice
A block of voice samples, with the length indicated by LI, goes into the AAL2 packet as-is 🎀
Payload - CAS signaling
For CAS signaling, the payload is formatted as an AAL2 "fully protected" (type 3) packet (see [AAL2]), so it gets error protection 🛡️ The signaling is sent with the same CID as the corresponding voice channel. Signaling MUST be sent whenever the state of the ABCD bits changes, and it SHOULD be sent with triple redundancy, meaning sent three times, spaced 5 milliseconds apart. On top of that, the entire set of signaling bits SHOULD be sent periodically to keep things reliable 👑
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | CRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CRC (cont) |
+-+-+-+-+-+-+-+-+RED(2 bits) is the triple redundancy counter. The first packet takes the value 00, the second 01 and the third 10.RED=11means non-redundant information, and it's used when triple redundancy isn't employed and for periodic refresh messages 🔥Timestamp(14 bits) is optional, and it isn't needed at all if RTP is employed 🧚 If it isn't used, the timestamp MUST be set to zero. When used with triple redundancy, it MUST be the same for all three redundant transmissions ✨RES(4 bits) is reserved and MUST be set to zero 🙈ABCD(4 bits) are the CAS signaling bits 🌈type(6 bits) is, for CAS signaling,000011💜CRC-10(10 bits) is a 10-bit CRC error detection code 🦋
Appendix D. Performance Monitoring Mechanisms (Informative) 📊
okay bestie, PWs need OAM mechanisms to keep an eye on the performance measures that affect the emulated service 👀 Things like packet loss ratio and packet delay variation can be used to set different parameters and thresholds 📈 For TDMoIP PWs, adaptive timing recovery and packet loss concealment algorithms may benefit from that info 💅 OAM mechanisms can also collect stats about the underlying PSN [RFC2330], and whether it's suitable for carrying TDM services 🎀
TDMoIP IWFs may benefit from knowing PSN performance metrics, like round trip time (RTT), packet delay variation (PDV) and packet loss ratio (PLR) ✨ These are usually measured with a separate flow of packets made just for that, e.g., ICMP packets [RFC792] or MPLS LSP ping packets [RFC4379] with multiple timestamps 🧚 For AAL1 mode, TDMoIP sends packets across the PSN at a constant rate, so no extra OAM flow is needed to measure PDV or PLR 🌸 But separate OAM flows are required for RTT measurement, for AAL2 mode PWs, for measuring parameters at setup, for monitoring inactive backup PWs, and for low-rate monitoring of PSNs after PWs have been withdrawn due to service failures 😭
If the underlying PSN has appropriate maintenance mechanisms that provide connectivity verification, and RTT, PDV, and PLR measurements that correlate well with those of the PW, then these mechanisms SHOULD be used 💖 If those aren't available, either of two similar OAM signaling mechanisms may be used 🦋 The first is internal to the PW and based on inband VCCV [RFC5085]. The second is defined only for UDP/IP PSNs and is based on a separate PW, and it's particularly efficient for a large number of fate-sharing TDM PWs 👑
D.1. TDMoIP Connectivity Verification
okay so in most conventional IP apps, a server sends some finite amount of info over the network after an explicit request from a client 🙃 With TDMoIP PWs, though, the PSN-bound IWF could send a continuous stream of packets toward the destination without knowing whether the TDM-bound IWF is ready to accept them 😬 For layer-2 networks, this may lead to flooding the PSN with stray packets 🌊
This can happen when a TDMoIP IWF is first brought up, when the TDM-bound IWF fails or gets disconnected from the PSN, or when the PW is broken 💀 After an aging time, the destination IWF becomes unknown, and intermediate switches may flood the network with TDMoIP packets while trying to find a new path 🙈
The fix is to significantly reduce the number of TDMoIP packets transmitted per second when PW failure is detected, and to go back to full rate only when the PW is available 🔥 Detecting failure and restoration is possible thanks to the periodic exchange of one-way connectivity-verification messages 💜
Connectivity is tested by periodically sending OAM messages from the source IWF to the destination IWF, with the destination replying to each message 🫶 The connectivity verification mechanism SHOULD be used during setup and configuration 🎀 Without OAM signaling, you must make sure the destination IWF is ready to receive packets before you start sending them 😤 Since TDMoIP IWFs operate full-duplex, both would need to be set up and properly configured at the same time if flooding is to be avoided 🙅♀️ When using connectivity verification, a configured IWF may wait until it detects its peer before transmitting at full rate ✨ Also, configuration errors may be readily discovered by using the service specific field of the OAM PW packets 🔍
In addition to one-way connectivity, OAM signaling mechanisms can be used to request and report on various PSN metrics, like one-way delay, round trip delay, packet delay variation, etc. 📊 They may also be used for remote diagnostics, and for unsolicited reporting of potential problems (e.g., dying gasp messages) 🚨
D.2. OAM Packet Format
when you use inband performance monitoring, extra packets get sent using the same PW label 🏷️ These packets are identified by their first nibble being equal to 0001, and they must be separated from TDM data packets before any further processing of the control word 🧩
When using a separate OAM PW, all OAM messages MUST use the PW label preconfigured to indicate OAM 🎯 All PSN layer parameters MUST remain those of the PW being monitored 🔒
The format of an inband OAM PW message packet for UDP/IP PSNs is based on [RFC2679] 💜 The PSN-specific layers are identical to those defined in Section 4.1, with the PW label set to the value preconfigured or assigned for PW OAM 🦋
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-specific layers (with preconfigured PW label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R| M |RES| Length | OAM Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Msg Type | OAM Msg Code | Service specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward PW label | Reverse PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+L, R, and M are identical to those of the PW being tested 🪞
Length is the length in bytes of the OAM message packet 📏
OAM Sequence Number (16 bits) is used to uniquely identify the message 🔢 Its value is unrelated to the sequence number of the TDMoIP data packets for the PW in question. It gets incremented in query messages and replicated without change in replies 🔁
OAM Msg Type (8 bits) indicates the function of the message 🎭 At present, the following are defined:
0 for one-way connectivity query message
8 for one-way connectivity reply message.OAM Msg Code (8 bits) carries information related to the message, and its interpretation depends on the message type 🧠 For type 0 (connectivity query) messages, the following codes are defined:
0 validate connection.
1 do not validate connectionFor type 8 (connectivity reply) messages, the available codes are:
0 acknowledge valid query
1 invalid query (configuration mismatch).Service specific information (16 bits) is a field that can be used to exchange configuration information between IWFs 🛠️ If it is not used, this field MUST contain zero 0️⃣ Its interpretation depends on the payload type. At present, the following is defined for AAL1 payloads:
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | Number of SFs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Number of TSs (8 bits) is the number of channels being transported, e.g., 24 for full T1 📡
Number of SFs (8 bits) is the number of 48-byte AAL1 PDUs per packet, e.g., 8 when packing 8 PDUs per packet 📦
Forward PW label (16 bits) is the PW label used for TDMoIP traffic from the source to destination IWF ➡️
Reverse PW label (16 bits) is the PW label used for TDMoIP traffic from the destination to source IWF ⬅️
Source Transmit Timestamp (32 bits) represents the time the PSN-bound IWF transmitted the query message ⏱️ This field and the following ones only appear if delay is being measured. All time units are derived from a clock of preconfigured frequency, the default being 100 microseconds ⏰
Destination Receive Timestamp (32 bits) represents the time the destination IWF received the query message 📥
Destination Transmit Timestamp (32 bits) represents the time the destination IWF transmitted the reply message 📤
Appendix E. Capabilities, Configuration and Statistics (Informative) 🗂️
every TDMoIP IWF will support some number of physical TDM connections, certain types of PSN, and some subset of the modes defined above 💅 The following capabilities SHOULD be able to be queried by the management system:
- AAL1 capable
- AAL2 capable (and AAL2 parameters, e.g., support for VAD and compression)
- HDLC capable
- Supported PSN types (UDP/IPv4, UDP/IPv6, L2TPv3/IPv4, L2TPv3/IPv6, MPLS, Ethernet)
- OAM support (none, separate PW, VCCV) and capabilities (CV, delay measurement, etc.)
- maximum packet size supported.
For every TDM PW, the following parameters MUST be provisioned or signaled 🔧
- PW label (for UDP and Ethernet the label MUST be manually configured)
- TDM type (E1, T1, E3, T3, fractional E1, fractional T1)
- for fractional links: number of timeslots
- TDMoIP mode (AAL1, AAL2, HDLC)
- for AAL1 mode:
- AAL1 type (unstructured, structured, structured with CAS)
- number of AAL1 PDUs per packet
- for AAL2 mode:
- CID mapping
- creation time of full minicell (units of 125 microsecond)
- size of jitter buffer (in 32-bit words)
- clock recovery method (local, loop-back timing, adaptive, common clock)
- use of RTP (if used: frequency of common clock, PT and SSRC values).
During operation, the following statistics and impairment indications SHOULD be collected for each TDM PW, and can be queried by the management system 📈
- average round-trip delay
- packet delay variation (maximum delay - minimum delay)
- number of potentially lost packets
- indication of misordered packets (successfully reordered or dropped)
- for AAL1 mode PWs:
- indication of malformed PDUs (incorrect CRC, bad C, P or E)
- indication of cells with pointer mismatch
- number of seconds with jitter buffer over-run events
- number of seconds with jitter buffer under-run events
- for AAL2 mode PWs:
- number of malformed minicells (incorrect HEC)
- indication of misordered minicells (unexpected UUI)
- indication of stray minicells (CID unknown, illegal UUI)
- indication of mis-sized minicells (unexpected LI)
- for each CID: number of seconds with jitter buffer over-run events
- for HDLC mode PWs:
- number of discarded frames from TDM (e.g., CRC error, illegal packet size)
- number of seconds with jitter buffer over-run events.
During operation, the following statistics MAY be collected for each TDM PW 🌈
- number of packets sent to PSN
- number of packets received from PSN
- number of seconds during which packets were received with L flag set
- number of seconds during which packets were received with R flag set.
References
Normative References
- [AAL1] ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 1 ✨
- [AAL2] ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM Adaptation Layer (AAL) specification: Type 2 💖
- [CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit Emulation Service Interoperability Specification Ver. 2.0 🎀
- [G704] ITU-T Recommendation G.704 (10/98) - Synchronous frame structures used at 1544, 6312, 2048, 8448 and 44736 kbit/s hierarchical levels 🌸
- [G751] 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 🦋
- [G823] ITU-T Recommendation G.823 (03/00) - The control of jitter and wander within digital networks which are based on the 2048 Kbit/s hierarchy 🧚
- [G824] ITU-T Recommendation G.824 (03/00) - The control of jitter and wander within digital networks which are based on the 1544 Kbit/s hierarchy 💜
- [G826] ITU-T Recommendation G.826 (12/02) - End-to-end error performance parameters and objectives for international, constant bit-rate digital paths and connections ✨
- [IEEE802.1Q] IEEE 802.1Q, IEEE Standards for Local and Metropolitan Area Networks -- Virtual Bridged Local Area Networks (2003) 🔥
- [IEEE802.3] IEEE 802.3, IEEE Standard Local and Metropolitan Area Networks - Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications (2002) 👑
- [LES] ATM forum specification atm-vmoa-0145 (LES) Voice and Multimedia over ATM - Loop Emulation Service Using AAL2 🌈
- [MEF8] Metro Ethernet Forum, "Implementation Agreement for the Emulation of PDH Circuits over Metro Ethernet Networks", October 2004. 🍓
- [RFC768] Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC 768, August 1980. 💅
- [RFC791] Postel, J., "Internet Protocol (IP)", STD 5, RFC 791, September 1981. 🫶
- [RFC2119] Bradner, S., "Key Words in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. 🌸
- [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001. 🦋
- [RFC3931] Lau, J., Townsley, M., Goyret, I., "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005. 🧚
- [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and Jacobson, V., "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. 💜
- [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. 🔥
- [RFC4553] Vainshtein A., and Stein YJ., "Structure-Agnostic TDM over Packet (SAToP)", RFC 4553, June 2006. 👑
- [RFC4618] Martini L., Rosen E., Heron G., and Malis A., "Encapsulation Methods for Transport of PPP/High-Level Data Link Control (HDLC) over MPLS Networks", RFC 4618, September 2006. 🌈
- [RFC5085] Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification: A Control Channel for Pseudowires", RFC 5085, December 2007. 🍓
- [SSCS] ITU-T Recommendation I.366.2 (11/00) - AAL type 2 service specific convergence sublayer for narrow-band services. 💅
- [Y1413] ITU-T Recommendation Y.1413 (03/04) - TDM-MPLS network interworking - User plane interworking 🫶
- [Y1414] ITU-T Recommendation Y.1414 (07/04) - Voice services - MPLS network interworking. 🌸
- [Y1452] ITU-T Recommendation Y.1452 (03/06) - Voice trunking over IP networks. 🦋
- [Y1453] ITU-T Recommendation Y.1453 (03/06) - TDM-IP interworking - User plane interworking. 🧚
Informative References
- [ISDN-PRI] ITU-T Recommendation Q.931 (05/98) - ISDN user-network interface layer 3 specification for basic call control. 💜
- [RFC792] Postel J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. ✨
- [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. 🔥
- [RFC2330] Paxson, V., Almes, G., Mahdavi, J., Mathis M., "Framework for IP Performance Metrics", RFC 2330, May 1998. 👑
- [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. 🌈
- [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. 💅
- [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. 🫶
- [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000. 🌸
- [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. 🦋
- [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. 🧚
- [RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005. 💜
- [RFC4086] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005. ✨
- [RFC4197] Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005. 🔥
- [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. 👑
- [RFC4379] Kompella, K. and Swallow, G., "Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures", RFC 4379, February 2006. 🌈
- [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. 🍓
- [RFC5086] Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T., and P. Pate, "Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)", RFC 5086, December 2007. 💅
- [SS7] ITU-T Recommendation Q.700 (03/93) - Introduction to CCITT Signalling System No. 7. 🫶
- [TDM-CONTROL] Vainshtein, A. and Y(J) Stein, "Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks", Work in Progress, November 2007. 🌸
- [TRAU] GSM 08.60 (10/01) - Digital cellular telecommunications system (Phase 2+); Inband control of remote transcoders and rate adaptors for Enhanced Full Rate (EFR) and full rate traffic channels. 🦋
Authors' Addresses
Meet the squad! 💖
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.comRonen Shashoua
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5447
EMail: ronen_s@rad.comRon Insler
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5445
EMail: ron_i@rad.comMotty (Mordechai) Anavi
RAD Data Communications
900 Corporate Drive
Mahwah, NJ 07430
USA
Phone: +1 201 529-1100 Ext. 213
EMail: motty@radusa.comFull Copyright Statement
Copyright (C) The IETF Trust (2007). 🎀
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, THE IETF TRUST 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
Okay so, the IETF doesn't take a side on whether any patents or other rights apply to the tech in this document, or whether you can get a license for it. It also hasn't done its own digging to find any of that out. 🔥
If you want the rules on RFC rights, check out BCP 78 and BCP 79. 👑
Any IPR disclosures sent to the IETF Secretariat, plus any promises of licenses, or the results of trying to get a general permission to use proprietary rights, can be found in the IETF's online IPR repository at http://www.ietf.org/ipr. 🌈
The IETF also wants you to tell it about any copyrights, patents, patent applications, or other proprietary rights that might cover tech needed to implement this standard. Send that to ietf-ipr@ietf.org. 🍓
That's the whole doc, bestie! 🌈💖✨
📦 where this page comes from
- ietf: rfc5087 2007-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms