RFC 4197
Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks
RFC 4197: Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks 🎀
Okay bestie, this one is all about how to fake a TDM circuit over a packet network without it falling apart 💅 It was written by M. Riegel of Siemens AG, and it's categorized as Informational, so it's giving "here's some info" and not an official Internet standard 🤓 The date is October 2005. The title block doesn't list anything it obsoletes or updates, so it's standing on its own ✨
Status of This Memo ✨
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
Copyright Notice 🌸
Copyright (C) The Internet Society (2005).
Abstract 🦋
This doc lays out the specific requirements for edge-to-edge emulation of circuits that carry Time Division Multiplexed (TDM) digital signals. That covers the Plesiochronous Digital Hierarchy, plus the Synchronous Optical NETwork and Synchronous Digital Hierarchy, all running over packet-switched networks 🫶 It lines up with the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3). It points back to the generic PWE3 requirements wherever they apply, then adds its own requirements that come from the specifics of TDM circuits 💜
Table of Contents 🧚
1. Introduction ....................................................3
1.1. TDM Circuits Belonging to the PDH Hierarchy ................3
1.1.1. TDM Structure and Transport Modes ...................4
1.2. SONET/SDH Circuits .........................................4
2. Motivation ......................................................5
3. Terminology .....................................................6
4. Reference Models ................................................7
4.1. Generic PWE3 Models ........................................7
4.2. Clock Recovery .............................................7
4.3. Network Synchronization Reference Model ....................8
4.3.1. Synchronous Network Scenarios ......................10
4.3.2. Relative Network Scenario ..........................12
4.3.3. Adaptive Network Scenario ..........................12
5. Emulated Services ..............................................13
5.1. Structure-Agnostic Transport of Signals out of the
PDH Hierarchy .............................................13
5.2. Structure-Aware Transport of Signals out of the
PDH Hierarchy .............................................14
5.3. Structure-Aware Transport of SONET/SDH Circuits ...........14
6. Generic Requirements ...........................................14
6.1. Relevant Common PW Requirements ...........................14
6.2. Common Circuit Payload Requirements .......................15
6.3. General Design Issues .....................................16
7. Service-Specific Requirements ..................................16
7.1. Connectivity ..............................................16
7.2. Network Synchronization ...................................16
7.3. Robustness ................................................16
7.3.1. Packet loss ........................................17
7.3.2. Out-of-order delivery ..............................17
7.4. CE Signaling ..............................................17
7.5. PSN Bandwidth Utilization .................................18
7.6. Packet Delay Variation ....................................19
7.7. Compatibility with the Existing PSN Infrastructure ........19
7.8. Congestion Control ........................................19
7.9. Fault Detection and Handling ..............................20
7.10. Performance Monitoring ...................................20
8. Security Considerations ........................................20
9. References .....................................................20
9.1. Normative References ......................................20
9.2. Informative References ....................................21
10. Contributors Section ..........................................221. Introduction ✨
This doc lays out the specific requirements for edge-to-edge emulation of circuits carrying Time Division Multiplexed (TDM) digital signals of the Plesiochronous Digital Hierarchy (PDH), plus the Synchronous Optical NETwork (SONET) and Synchronous Digital Hierarchy (SDH), all running over Packet-Switched Networks (PSN). It lines up with the common architecture for Pseudo Wire Emulation Edge-to-Edge (PWE3) as defined in [RFC3985]. It references the requirements in [RFC3916] where they apply, then adds to [RFC3916] with requirements that come from the specifics of TDM circuits 💖
The word "TDM" is used throughout this document as a general label for the synchronous bit streams that belong to either the PDH or the SONET/SDH hierarchies 🎀
1.1. TDM Circuits Belonging to the PDH Hierarchy 🌈
The bit rates that different regions of the world traditionally use are detailed in the normative reference [G.702]. For example, in North America the T1 bit stream of 1.544 Mbps and the T3 bit stream of 44.736 Mbps are mandated, while in Europe the E1 bit stream of 2.048 Mbps and the E3 bit stream of 34.368 Mbps are used 🇺🇸🇪🇺
TDM can carry unstructured bit streams at the rates defined in [G.702], but there's also a standard way to carry bit streams in bigger units called frames. Every frame contains the same number of bits 🍓
The bitrate is always a multiple of 8000, which ties back to how often voice traffic gets sampled. That's why a T1 frame is 193 bits and an E1 frame is 256 bits. The number of bits in a frame is called the frame size ✨
Framing works by putting a repeating pattern into the bit stream so the receiver can find where each frame starts and ends (for example, 1 framing bit per T1 frame, or a sequence of 8 framing bits per E1 frame). The details of how these framing bits are generated and used are explained in [G.704], [G.706], and [G.751]. Unframed TDM has every bit available for payload 💅
Framed TDM is often used to multiplex several channels (for example, voice channels that each consist of 8000 8-bit samples per second) into a sequence of "timeslots" that show up in the same spot in every frame. This multiplexing is called "channelized TDM", and it adds more structure 🧚
Sometimes framing also groups consecutive frames together into multiframes. That grouping adds one more level of structure to the TDM bit stream 🦋
1.1.1. TDM Structure and Transport Modes 💜
- Unstructured TDM: TDM that is a raw bit stream at a rate defined in [G.702], with all bits available for payload.
- Structured TDM: TDM with one or more levels of structure delineation, including frames, channelization, and multiframes (for example, as defined in [G.704], [G.751], and [T1.107]).
- Structure-Agnostic Transport: Transport of unstructured TDM, or of structured TDM when the structure is considered inconsequential from the transport point of view. In structure-agnostic transport, any structural overhead that may be present is transparently carried along with the payload data, and the encapsulation provides no mechanisms for its location or use. It's giving "don't touch the structure, just move the bits" 🫶
- Structure-Aware Transport: Transport of structured TDM that takes at least some level of the structure into account. In structure-aware transport, there's no guarantee that all bits of the TDM bit stream will be carried over the PSN. The synchronization bits and related overhead may be stripped at ingress and usually get regenerated at egress. There's also no guarantee that the transported bits will land in the packet in their original order, though the bit order is usually recovered at egress. One known exception is loss of multiframe synchronization between the TDM data and the CAS bits, introduced by a digital cross-connect acting as a Native Service Processing (NSP) block (see [TR-NWT-170]) 👑
1.2. SONET/SDH Circuits 🎀
The term SONET refers to the North American Synchronous Optical NETwork as specified by [T1.105]. It's built on a Nx783 byte payload container that repeats every 125us. This payload is called an STS-1 SPE, and it can be concatenated into higher bandwidth circuits (for example, STS-Nc) or sub-divided into lower bandwidth circuits (Virtual Tributaries). The bigger concatenated circuits can carry pretty much anything, from IP packets to ATM cells to digital video signals. Individual STS-1 SPEs are often used to carry individual DS3 or E3 TDM circuits. When the 783 byte containers get sub-divided for lower rate payloads, they're frequently used to carry individual T1 or E1 TDM circuits 💖
The Synchronous Digital Hierarchy (SDH) is the international equivalent and upgrade of SONET, and it's specified by [G.707] 🌸
Both SONET and SDH have a lot of transport overhead for performance monitoring, fault isolation, and other maintenance jobs along the different kinds of optical or electrical spans. That overhead also includes a pointer-based mechanism for carrying payloads asynchronously. On top of that, the payload area has dedicated overhead for end-to-end performance monitoring, fault isolation, and maintenance of the service being carried. If the main payload area gets sub-divided into lower rate circuits (like T1/E1), extra overhead is added for end-to-end monitoring of each individual T1/E1 circuit 🙈
This document covers the requirements for emulating SONET/SDH services. Those services include end-to-end emulation of the SONET payload (STS-1 SPE), emulation of concatenated payloads (STS-Nc SPE), and emulation of a variety of sub-STS-1 rate circuits, collectively called Virtual Tributaries (VT) along with their SDH analogs ✨
2. Motivation 🦋
[RFC3916] specifies common requirements for edge-to-edge emulation of circuits of various types. However, those requirements, along with the references in [RFC3985], don't cover the specifics of PWs carrying TDM circuits 😭
So this doc is needed to add to the [RFC3916] coverage of edge-to-edge emulation of TDM circuits, and the reasons are:
- Specifics of the TDM circuits. For example:
- the need for balance between the clock of ingress and egress attachment circuits in each direction of the Pseudo Wire (PW),
- the need to keep the jitter and wander of the clock of the egress end service within the limits set by the appropriate normative documents, even with the packet delay variation the PSN produces.
- Specifics of applications that use TDM circuits. For example, voice applications:
- put special emphasis on minimizing one-way delay, and
- are relatively tolerant of data errors.
- Other applications can have different specifics. For example, transport of signaling information:
- is relatively tolerant of one-way delay, and
- is sensitive to errors in the transmitted data.
- Specifics of customer expectations about end-to-end behavior of services that contain emulated TDM circuits. For example, experience with carrying these services over SONET/SDH networks increases the need for:
- isolation of problems introduced by the PSN from those that occur beyond the PSN bounds,
- sensitivity to misconnection,
- sensitivity to unexpected connection termination, and so on 💅🫶
3. Terminology ✨
okay so 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]. 💅
The terms defined in [RFC3985], Section 1.4 are used consistently. 🫶 However, some terms and acronyms are used together with the TDM services, like it's their whole thing. In particular:
TDM networks use Channel-Associated Signaling (CAS) or Common Channel Signaling (CCS) to supervise and advertise the status of telephony applications, send alerts to those applications (about requests to connect or disconnect), and transfer routing and addressing information. 📞 These signals must be reliably transported over the PSNs for the telephony end-systems to function properly. 😭
CAS (Channel-Associated Signaling)
CAS is carried in the same T1 or E1 frame as the voice signals, but not in the speech band. 🎀 Since CAS signaling may be transferred at a rate slower than the TDM traffic in a timeslot, you don't need to update all the CAS bits in every TDM frame. So CAS systems cycle through all the signaling bits only after some number of TDM frames, and that cycle defines a new structure known as a multiframe or superframe. ✨ Common multiframes are 12, 16, or 24 frames in length, corresponding to 1.5, 2, and 3 milliseconds in duration. ⏱️
CCS (Common Channel Signaling)
CCS signaling uses a separate digital channel to carry asynchronous messages about the state of telephony applications over related TDM timeslots of a TDM trunk. 🦋 This channel may be physically situated in one or more adjacent timeslots of the same TDM trunk (trunk associated CCS), or it may be transported over an entirely separate network. 🌈
CCS is typically HDLC-based, with idle codes or keep-alive messages being sent until a signaling event (e.g., on-hook or off-hook) occurs. 💜 Examples of HDLC-based CCS systems are SS7 [Q.700] and ISDN PRI signaling [Q.931]. 🧚
Note: For the TDM network, we use the terms "jitter" and "wander" as defined in [G.810] to describe short- and long-term variance of the significant instants of the digital signal. 🙈 For the PSN, we use the term packet delay variation (PDV) (see [RFC3393]). 🌸
4. Reference Models 🌷
4.1. Generic PWE3 Models
Generic models have already been defined in [RFC3985] in these sections, and they're fully applicable for this document without any modification. 🍓
- 4.1 (Network Reference Model),
- 4.2 (PWE3 Pre-processing),
- 4.3 (Maintenance Reference Model),
- 4.4 (Protocol Stack Reference Model) and
- 4.5 (Pre-processing Extension to Protocol Stack Reference Model).
All the services considered in this document are special cases of the Bit-stream and Structured bit-stream payload type defined in Section 3.3 of [RFC3985]. 👑
4.2. Clock Recovery ⏰
Clock recovery is the extraction of the transmission bit timing information from the delivered packet stream. 🔥 Pulling that info out of a highly jittered source, like a packet stream, can be a complex task. 😵💫
4.3. Network Synchronization Reference Model 🔄
Figure 1 shows a generic network synchronization reference model. Look at this beauty. 😍
+---------------+ +---------------+
| PE1 | | PE2 |
K | +--+ | | +--+ | G
| | | J| | | | H| | |
v | v | | | v | | v
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
| | | |P| |D| |P| | | | | | | |P| |E| |P| | | |
| |<===|h|<:|e|<:|h|<:::| |<::| |<:::|h|<:|n|<=|h|<===| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
| C | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | C |
| E | | | |S1| |S2| | | | E |
| 1 | | +-+ +-+ +-+ | | | | | | +-+ +-+ +-+ | | 2 |
| | | |P| |E| |P| | | | | | | |P| |D| |P| | | |
| |===>|h|=>|n|:>|h|:::>| |::>| |:::>|h|:>|e|=>|h|===>| |
| | | |y| |c| |y| | | | | | | |y| |c| |y| | | |
+---+ | +-+ +-+ +-+ | +--+ +--+ | +-+ +-+ +-+ | +---+
^ ^ | | ^ | | | ^ | ^ ^
| | | |B | |<------+------>| | | | | |
| A | +--+ | | | +--+-E | F |
| +---------------+ +-+ +---------------+ |
| ^ |I| ^ |
| | +-+ | |
| C D |
+-----------------------------L-----------------------------+
Figure 1: The Network Synchronization Reference ModelThe following notation is used in Figure 1. 🧩
- CE1, CE2 Customer edge devices terminating TDM circuits to be emulated. 📦
- PE1, PE2 Provider edge devices adapting these end services to PW. 🎀
- S1, S2 Provider core routers. 🛰️
- Phy Physical interface terminating the TDM circuit. 🔌
- Enc PSN-bound interface of the PW, where the encapsulation takes place. 📤
- Dec CE-bound interface of the PW, where the decapsulation takes place. It contains a compensation buffer (also known as the "jitter buffer") of limited size. 📥
- "==>" TDM attachment circuits. 🧵
- "::>" PW providing edge-to-edge emulation for the TDM circuit. 🦋
The characters "A" - "L" denote various clocks. ⏰
- "A" The clock used by CE1 for transmission of the TDM attachment circuit towards CE1. 🕐
- "B" The clock recovered by PE1 from the incoming TDM attachment circuit. "A" and "B" always have the same frequency. 💞
- "G" The clock used by CE2 for transmission of the TDM attachment circuit towards CE2. 🕑
- "H" The clock recovered by PE2 from the incoming TDM attachment circuit. "G" and "H" always have the same frequency. 💖
- "C", "D" Local oscillators available to PE1 and PE2, respectively. 🎵
- "E" Clock used by PE2 to transmit the TDM attachment service circuit to CE2 (the recovered clock). 🌟
- "F" Clock recovered by CE2 from the incoming TDM attachment service ("E" and "F" have the same frequency). ✨
- "I" If the clock exists, it is the common network reference clock available to PE1 and PE2. 👑
- "J" Clock used by PE1 to transmit the TDM attachment service circuit to CE1 (the recovered clock). 💫
- "K" Clock recovered by CE1 from the incoming TDM attachment service ("J" and "K" have the same frequency). 🌈
- "L" If it exists, it is the common reference clock of CE1 and CE2. Note that different pairs of CE devices may use different common reference clocks. 🍭
A requirement of edge-to-edge emulation of a TDM circuit is that clock "B" and "E", as well as clock "H" and "J", are of the same frequency. 🫶 The most appropriate method will depend on the network synchronization scheme. 🤔
The following groups of synchronization scenarios can be considered. 💅
4.3.1. Synchronous Network Scenarios 🌐
Depending on which part of the network is synchronized by a common clock, there are two scenarios. 🎀
- PE Synchronized Network:
Figure 2 is an adapted version of the generic network reference model, and presents the PE synchronized network scenario. 🌸
The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I". 🔒
- Clocks "E" and "J" are the same as "D" and "C", respectively.
- Clocks "A" and "G" are the same as "K" and "F", respectively (i.e., CE1 and CE2 use loop timing).
+-----+ +-----+
+-----+ | |- - -|=================|- - -| | +-----+
| /-- |<---------|............PW1..............|<---------| <-\ |
|| CE | | | PE1 | | PE2 | | |CE2 ||
| \-> |--------->|............PW2..............|--------->| --/ |
+-----+ | |- - -|=================|- - -| | +-----+
+-----+ +-----+
^ ^
|C |D
+-----------+-----------+
|
+-+
|I|
+-+
Figure 2: PE Synchronized Scenario- CE Synchronized Network:
Figure 3 is an adapted version of the generic network reference model, and presents the CE synchronized network scenario. 🌷
The common network reference clock "L" is available to all the CE devices, and local oscillators "A" and "G" are locked to "L". 🔐
- Clocks "E" and "J" are the same as "G" and "A", respectively (i.e., PE1 and PE2 use loop timing).
+-----+ +-----+
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+ +-----+ ^
|A G|
+----------------------------+------------------------------+
|
+-+
|L|
+-+
Figure 3: CE Synchronized ScenarioNo timing information has to be transferred in these cases. 🙌
4.3.2. Relative Network Scenario 🦋
In this case, each CE uses its own transmission clock source, which must be carried across the PSN and recovered by the remote PE, respectively. 🛤️ The common PE clock "I" can be used as a reference for this purpose. 🧭
Figure 4 shows the relative network scenario. 🖼️
The common network reference clock "I" is available to all the PE devices, and local oscillators "C" and "D" are locked to "I". 🔒
- Clocks "A" and "G" are generated locally without reference to a common clock.
- Clocks "E" and "J" are generated in reference to a common clock available at all PE devices.
In a slight modification of this scenario, one (but not both!) of the CE devices may use its receive clock as its transmission clock (i.e., use loop timing). 🔁
|G
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+<-------+------->+-----+
|A |
+-+
|I|
+-+
Figure 4: Relative Network Scenario TimingIn this case, timing information (the difference between the common reference clock "I" and the incoming clock "A") MUST be explicitly transferred from the ingress PE to the egress PE. 🚨💖
4.3.3. Adaptive Network Scenario 🦋
okay so the adaptive scenario has two big vibes, bestie 💅
- No common network reference clock "I" is available to PE1 and PE2. 😭
- No common reference clock "L" is available to CE1 and CE2. 💀
Figure 5 shows the whole setup 👇
|J |G
v |
+-----+ +-----+ v
+-----+ | |- - -|=================|- - -| | +-----+
| |<---------|............PW1..............|<---------| |
| CE1 | | | PE1 | | PE2 | | | CE2 |
| |--------->|............PW2..............|--------->| |
+-----+ | |- - -|=================|- - -| | +-----+
^ +-----+ +-----+
| ^
A| E|Figure 5: Adaptive Scenario
Syncing clocks "A" and "E" here is lowkey harder than in the other scenarios. It's literally the hardest one 🥺
Also, the tolerance between clocks "A" and "E" must be small enough to make sure the jitter buffer doesn't overflow or underflow. Not optional, babe 🫶
In this case, timing information MAY be explicitly transferred from the ingress PE to the egress PE, e.g., by RTP. That's the iconic move 👑
5. Emulated Services ✨
This section lays out the requirements for the payload and encapsulation layers for edge-to-edge emulation of TDM services, both bit-stream payload and structured bit-stream payload 🎀
Wherever possible, the requirements in this document SHOULD be satisfied by setting up the encapsulation layer properly, and that's it 💖 The (rare) cases where the requirements hit both the encapsulation and payload layers (or even just the payload layer) get called out explicitly, so you won't miss them 👀
The service-specific encapsulation layer for edge-to-edge emulation covers the following services over a PSN 🧚
5.1. Structure-Agnostic Transport of Signals out of the PDH Hierarchy 🍓
Structure-agnostic transport is considered for these signals:
- E1 as described in [G.704].
- T1 (DS1) as described in [G.704].
- E3 as defined in [G.751].
- T3 (DS3) as described in [T1.107].
5.2. Structure-Aware Transport of Signals out of the PDH Hierarchy 🌸
Structure-aware transport is considered for these signals:
- E1/T1 with one of the structures imposed by framing as described in [G.704].
- NxDS0 with or without CAS.
5.3. Structure-Aware Transport of SONET/SDH Circuits 💜
Structure-aware transport is considered for these SONET/SDH circuits:
SONET STS-1 synchronous payload envelope (SPE)/SDH VC-3.SONET STS-Nc SPE (N = 3, 12, 48, 192) / SDH VC-4, VC-4-4c, VC-4-16c, VC-4-64c.SONET VT-N (N = 1.5, 2, 3, 6) / SDH VC-11, VC-12, VC-2.SONET Nx VT-N / SDH Nx VC-11/VC-12/VC-2/VC-3.
Note: There is no requirement for the structure-agnostic transport of SONET/SDH. For this case, it would seem that structure must be taken into account. Not the vibe for agnostic, so keep the structure 🙈
6. Generic Requirements 🌈
6.1. Relevant Common PW Requirements 🦋
The encapsulation and payload layers MUST conform to the common PW requirements defined in [RFC3916]:
- Conveyance of Necessary Header Information:
- A. For structure-agnostic transport, this functionality MAY be provided by the payload layer.
- B. For structure-aware transport, the necessary information MUST be provided by the encapsulation layer.
- C. Structure-aware transport of SONET/SDH circuits MUST preserve path overhead information as part of the payload. Relevant components of the transport overhead MAY be carried in the encapsulation layer.
- Support of Multiplexing and Demultiplexing if supported by the native services. This is relevant for Nx DS0 circuits (with or without signaling) and Nx VT-x in a single STS-1 SPE or VC-4.:
- A. For these circuits, the combination of encapsulation and payload layers MUST provide for separate treatment of every sub-circuit.
- B. Enough information SHOULD be provided by the pseudo wire to allow multiplexing and demultiplexing by the NSP. Reduction of the complexity of the PW emulation by using NSP circuitry for multiplexing and demultiplexing MAY be the preferred solution.
- Intervention or transparent transfer of Maintenance Messages of the Native Services, depending on the particular scenario.
- Consideration of Per-PSN Packet Overhead (see also Section 7.5 below).
- Detection and handling of PW faults. The list of faults is given in Section 7.9 below.
Fragmentation indications MAY be used for structure-aware transport when the structures in question either exceed desired packetization delay or exceed Path MTU between the pair of PEs. Big structures, big feelings 🥹
The following requirement listed in [RFC3916] is not applicable to emulation of TDM services:
- Support of variable length PDUs.
6.2. Common Circuit Payload Requirements 🎀
Structure-agnostic transport treats TDM circuits as belonging to the 'Bit-stream' payload type defined in [RFC3985].
Structure-aware transport treats these circuits as belonging to the "Structured bit-stream" payload type defined in [RFC3985].
So, the encapsulation layer MUST provide the common Sequencing service and SHOULD provide Timing information (Synchronization services) when required (see Section 4.3 above). Sequencing is non-negotiable, bestie ✨
Note: Length service MAY be provided by the encapsulation layer, but is not required. Totally optional, no pressure 💅
6.3. General Design Issues 🧚
The combination of payload and encapsulation layers SHOULD comply with the general design principles of the Internet protocols as presented in Section 3 of [RFC1958] and [RFC3985]. Classic Internet vibes 🌸
If necessary, the payload layer MAY use some forms of adaptation of the native TDM payload in order to achieve specific, well-documented design objectives. In these cases, standard adaptation techniques SHOULD be used. Stick to the standard stuff, it's safer 🫶
7. Service-Specific Requirements 👑
7.1. Connectivity 🦋
- The emulation MUST support the transport of signals between Attachment Circuits (ACs) of the same type (see Section 5) and, wherever appropriate, bit-rate.
- The encapsulation layer SHOULD remain unaffected by specific characteristics of connection between the ACs and PE devices at the two ends of the PW. It should not care how the ACs connect, periodt 💖
7.2. Network Synchronization ⏰
- The encapsulation layer MUST provide synchronization services that are sufficient to:
- A. match the ingress and egress end service clocks regardless of the specific network synchronization scenario, and
- B. keep the jitter and wander of the egress service clock within the service-specific limits defined by the appropriate normative references.
- If the same high-quality synchronization source is available to all the PE devices in the given domain, the encapsulation layer SHOULD be able to make use of it (e.g., for better reconstruction of the native service clock). Use the good clock if you've got one, no cap 🔥
7.3. Robustness 🛡️
The robustness of the emulated service depends not only upon the edge-to-edge emulation protocol, but also upon proper implementation of the following procedures. It's a team effort ✨
7.3.1. Packet loss 🌧️
Edge-to-edge emulation of TDM circuits MAY assume very low probability of packet loss between ingress and egress PE. In particular, no retransmission mechanisms are required. Low loss is the expectation, and no resending drama 🙈
In order to minimize the effect of lost packets on the egress service, the encapsulation layer SHOULD:
- Enable independent interpretation of TDM data in each packet by the egress PE (see [RFC2736]). This requirement MAY be disregarded if the egress PE needs to interpret structures that exceed the path MTU between the ingress and egress PEs.
- Allow reliable detection of lost packets (see next section). In particular, it SHOULD allow estimation of the arrival time of the next packet and detection of lost packets based on this estimate.
- Minimize possible effect of lost packets on recovery of the circuit clock by the egress PE.
- Increase the resilience of the CE TDM interface to packet loss by allowing the egress PE to substitute appropriate data.
7.3.2. Out-of-order delivery 🔀
The encapsulation layer MUST provide the necessary mechanisms to guarantee ordered delivery of packets carrying the TDM data over the PSN. Packets that have arrived out-of-order:
- MUST be detected, and
- SHOULD be reordered if not judged to be too late or too early for playout.
Out-of-order packets that cannot be reordered MUST be treated as lost. Gone, but not forgotten 😭
7.4. CE Signaling 📡
Unstructured TDM circuits would not usually require any special mechanism for carrying CE signaling, as this would be carried as part of the emulated service. Main character energy from the data itself 💅
Some CE applications using structured TDM circuits (e.g., telephony) require specific signaling that conveys the changes of state of these applications relative to the TDM data.
The encapsulation layer SHOULD support signaling of state of CE applications for the relevant circuits, providing for:
- Ability to support different signaling schemes with minimal impact on encapsulation of TDM data,
- Multiplexing of application-specific CE signals and data of the emulated service in the same PW,
- Synchronization (within the application-specific tolerance limits) between CE signals and data at the PW egress,
- Probabilistic recovery against possible, occasional loss of packets in the PSN, and
- Deterministic recovery of the CE application state after PW setup and network outages.
CE signaling that is used for maintenance purposes (loopback commands, performance monitoring data retrieval, etc.) SHOULD use the generic PWE3 maintenance protocol. Maintenance stays in its lane 🧹
7.5. PSN Bandwidth Utilization 🌊
- The encapsulation layer SHOULD allow for an effective trade-off between the following requirements:
- A. Effective PSN bandwidth utilization. Assuming that the size of the encapsulation layer header does not depend on the size of its payload, an increase in the packet payload size results in increased efficiency.
- B. Low edge-to-edge latency. Low end-to-end latency is the common requirement for Voice applications over TDM services. Packetization latency is one of the components comprising edge-to-edge latency, and it decreases with the packet payload size.
The compensation buffer used by the CE-bound IWF increases latency to the emulated circuit. Additional delays introduced by this buffer SHOULD NOT exceed the packet delay variation observed in the PSN. Don't let the buffer slow things down more than the wobble already there 🙃
- The encapsulation layer MAY provide for saving PSN bandwidth by not sending corrupted TDM data across the PSN. Why send the trash? 🗑️
- The encapsulation layer MAY provide the ability to save the PSN bandwidth for the structure-aware case by not sending channels that are permanently inactive.
- The encapsulation layer MAY enable the dynamic suppression of temporarily unused channels from transmission for the structure-aware case.
If used, dynamic suppression of temporarily unused channels MUST NOT violate the integrity of the structures delivered over the PW. Suppress the idle stuff, but never break the structure 🫶
- For NxDS0, the encapsulation layer MUST provide the ability to keep the edge-to-edge delay independent of the service rate. Latency stays chill no matter the rate 🦋
7.6. Packet Delay Variation 🌊
okay so packet delay variation is when packets don't all arrive at the same time, and bestie, the encapsulation layer SHOULD be able to compensate for that 💅 while keeping the jitter and wander of the egress end service clock within the tolerances in the normative references 🫶.
The encapsulation layer MAY also do run-time adaptation of the delay added by the jitter buffer, if the packet delay variation changes over time 🦋. That adaptation MAY introduce a low level of errors (within the limits the application can tolerate), but it SHOULD NOT add extra wander to the egress end service clock 😭.
7.7. Compatibility with the Existing PSN Infrastructure 🧚
the combo of encapsulation and PSN tunnel layers used for edge-to-edge emulation of TDM circuits SHOULD be compatible with the PSN infrastructure that already exists 💖. especially, compatibility with header compression over links where capacity is at a premium SHOULD be provided ✨.
7.8. Congestion Control 🌸
TDM circuits run at a constant rate, so they give the PSN a constant traffic load 🍓. the rate-varying trick TCP uses to match demand to congestion state is therefore not applicable here 🙈.
The ability to shut down a TDM PW when congestion has been detected MUST be provided. 🚨
Precautions should be taken to avoid situations where multiple TDM PWs get shut down or re-established at the same time, because that leads to PSN instability 💀.
Further congestion considerations are discussed in chapter 6.5 of [RFC3985] 📚.
7.9. Fault Detection and Handling 🔥
The encapsulation layer for edge-to-edge emulation of TDM services SHOULD, on its own or together with the lower layers of the PWE3 stack, provide for detection, handling, and reporting of the following defects 👑:
- Misconnection, or Stray Packets. this one matters because customers expect the reliable misconnection detection they get in SONET/SDH networks 💅.
- Packet Loss. packet loss detection is required to keep clock integrity, as we covered in Section 7.3.1 above 🫶. on top of that, packet loss detection mechanisms SHOULD provide for localization of the outage in the end-to-end emulated service 🔍.
- Malformed packets. 🙅♀️
7.10. Performance Monitoring 📊
The encapsulation layer for edge-to-edge emulation of TDM services SHOULD provide for collection of performance monitoring (PM) data that is compatible with the parameters defined for 'classic', TDM-based carriers of these services 🎀. whether [G.826] applies is left for further study 🧐.
8. Security Considerations 🔐
The security considerations in [RFC3916] are fully applicable to the emulation of TDM services 🛡️. on top of that, TDM services are sensitive to packet delay variation [Section 7.6], and they need to be protected from this method of attack 🚨😱. this is serious, babe, so take it seriously 💜.
9. References 📖
9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.9.2. Informative References
[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.
[G.702] ITU-T Recommendation G.702 (11/88) - Digital hierarchy
bit rates
[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.706] ITU-T Recommendation G.706 (04/91) - Frame alignment and
cyclic redundancy check (CRC) procedures relating to
basic frame structures defined in Recommendation G.704
[G.707] ITU-T Recommendation G.707 (10/00) - Network node
interface for the synchronous digital hierarchy (SDH)
[G.751] ITU-T Recommendation G.751 (11/88) - Digital multiplex
equipments operating at the third order bit rate of 34
368 Kbit/s and the fourth order bit rate of 139 264
Kbit/s and using positive justification
[G.810] ITU-T Recommendation G.810 (08/96) - Definitions and
terminology for synchronization networks
[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
[Q.700] ITU-T Recommendation Q.700 (03/93) - Introduction to
CCITT Signalling System No. 7
[Q.931] ITU-T Recommendation Q.931 (05/98) - ISDN user-network
interface layer 3 specification for basic call control
[RFC1958] Carpenter, B., "Architectural Principles of the
Internet", RFC 1958, June 1996.
[RFC2736] Handley, M. and C. Perkins, "Guidelines for Writers of
RTP Payload Format Specifications", BCP 36, RFC 2736,
December 1999.
[RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay
Variation Metric for IP Performance Metrics (IPPM)", RFC
3393, November 2002.
[T1.105] ANSI T1.105 - 2001 Synchronous Optical Network (SONET) -
Basic Description including Multiplex Structure, Rates,
and Formats, May 2001
[T1.107] ANSI T1.107 - 1995. Digital Hierarchy - Format
Specification
[TR-NWT-170] Digital Cross Connect Systems - Generic Requirements and
Objectives, Bellcore, TR-NWT-170, January 199310. Contributors Section 🫶
The following have contributed to this document 💖:
Sasha Vainshtein
Axerra Networks
EMail: sasha@axerra.com
Yaakov Stein
RAD Data Communication
EMail: yaakov_s@rad.com
Prayson Pate
Overture Networks, Inc.
EMail: prayson.pate@overturenetworks.com
Ron Cohen
Lycium Networks
EMail: ronc@lyciumnetworks.com
Tim Frost
Zarlink Semiconductor
EMail: tim.frost@zarlink.comAuthor's Address 🎀
Maximilian Riegel
Siemens AG
St-Martin-Str 76
Munich 81541
Germany
Phone: +49-89-636-75194
EMail: maximilian.riegel@siemens.comFull Copyright Statement ©️
Copyright (C) The Internet Society (2005).
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 currently provided by the Internet Society ✨.
📦 where this page comes from
- ietf: rfc4197 2005-10
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms