RFC 5086
Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN)
RFC 5086: Structure-Aware Time Division Multiplexed (TDM) Circuit Emulation Service over Packet Switched Network (CESoPSN) 💖
Okay bestie, let's get into RFC 5086 🦋. It's an Informational document from December 2007, so it's sharing info with the Internet community, not defining an Internet standard. Vibes: very focused, very helpful 💅.
The main author is A. Vainshtein, who is the editor 📝. The other authors are I. Sasson from Axerra Networks, E. Metz from KPN, T. Frost from Zarlink Semiconductor, and P. Pate from Overture Networks. It's a Network Working Group document. The header doesn't list anything it obsoletes or updates, so it's not replacing or patching any older RFCs 🌸.
Status of This Memo 📌
This memo gives info to the Internet community. It doesn't specify an Internet standard of any kind. Distribution is unlimited, so share it with your whole group chat 🫶.
Abstract ✨
So the big idea here is a way to wrap up structured TDM signals (the NxDS0 kind) and send them as pseudowires over packet-switching networks (PSNs) 🧚. It's the sibling of the structure-agnostic TDM bit-stream work in RFC 4553, so think of it as the "structure-aware" glow-up 💜.
Table of Contents 📑
Table of Contents
1. Introduction ....................................................3
2. Terminology and Reference Models ................................3
2.1. Terminology ................................................3
2.2. Reference Models ...........................................4
2.3. Requirements and Design Constraint .........................4
3. Emulated Services ...............................................5
4. CESoPSN Encapsulation Layer .....................................6
4.1. CESoPSN Packet Format ......................................6
4.2. PSN and Multiplexing Layer Headers .........................8
4.3. CESoPSN Control Word .......................................9
4.4. Usage of the RTP Header ...................................11
5. CESoPSN Payload Layer ..........................................12
5.1. Common Payload Format Considerations ......................12
5.2. Basic NxDS0 Services ......................................13
5.3. Extending Basic NxDS0 Services with CE Application
Signaling .................................................15
5.4. Trunk-Specific NxDS0 Services with CAS ....................18
6. CESoPSN Operation ..............................................20
6.1. Common Considerations .....................................20
6.2. IWF Operation .............................................20
6.2.1. PSN-Bound Direction ................................20
6.2.2. CE-Bound Direction .................................20
6.3. CESoPSN Defects ...........................................23
6.4. CESoPSN PW Performance Monitoring .........................24
7. QoS Issues .....................................................25
8. Congestion Control .............................................25
9. Security Considerations ........................................27
10. IANA Considerations ...........................................27
11. Applicability Statement .......................................27
12. Acknowledgements ..............................................29
13. Normative References ..........................................30
14. Informative References ........................................31
Appendix A. A Common CE Application State Signaling Mechanism .....33
Appendix B. Reference PE Architecture for Emulation of NxDS0
Services ......................................................34
Appendix C. Old Mode of CESoPSN Encapsulation Over L2TPV3 .........361. Introduction 🌷
Okay so this doc describes how to wrap up structured (NxDS0) TDM signals and send them as pseudowires over packet-switching networks (PSN) 🎀. It's the sibling of the structure-agnostic TDM bit-stream work in [RFC4553], so they're basically a dynamic duo 👯♀️.
Why do we even want this? Emulating NxDS0 circuits saves PSN bandwidth, and it supports DS0-level grooming and distributed cross-connect applications 💅. It also makes CE devices more resilient when packets go missing in the PSN, which is honestly so iconic 🙌.
The CESoPSN solution here fits the Pseudowire Emulation Edge-to-Edge (PWE3) architecture from [RFC3985], meets the general requirements in [RFC3916], and meets the specific requirements for structured TDM emulation in [RFC4197] 🔥.
2. Terminology and Reference Models 📚
2.1. Terminology
Here's the key word rule: the words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document get read the way [RFC2119] says. Those capital words are the serious ones, so pay attention when you see them 👀⚠️.
The terms defined in [RFC3985], Section 1.4, and in [RFC4197], Section 3, are used consistently here without extra explanation, so go check those if you're lost 🧠.
This doc also uses some TDM terms and acronyms that show up a lot with TDM services. Here's the tea:
- Loss of Signal (LOS) is a common term for when a valid TDM signal can't be pulled out of the trunk's physical layer 📡. The actual rules for detecting and clearing LOS are in [G.775].
- Frame Alignment Signal (FAS) is a special repeating pattern used to give E1 and T1 circuits their TDM structure 🧩. Those patterns are described in [G.704].
- Out of Frame Synchronization (OOF) is the state a TDM receiver is in when it failed to find valid FAS 😵. The rules for declaring and clearing OOF are in [G.706]. Handling this condition includes invalidating the TDM data, so yeah, that's not a vibe 💀.
- Alarm Indication Signal (AIS) is a special bit pattern in the TDM bit stream that says there's an outage upstream 🚨. The rules for declaring and clearing AIS in a TDM stream are defined in [G.775].
- Remote Alarm Indication (RAI) and Remote Defect Indication (RDI) are usually used as synonyms 🪞. They're a special pattern in the framing of a TDM service that gets sent back by the receiver that's experiencing an AIS condition. This one can't be detected while LOS, OOF, or AIS is detected, so it's a whole vibe check 🙈. The specific rules for encoding this pattern in TDM framing are discussed in [G.775].
We also use the term Interworking Function (IWF) for the functional block that chops up TDM and encapsulates it into CESoPSN packets. In the other direction, it unwraps CESoPSN packets and rebuilds the TDM 🪄.
2.2. Reference Models
The generic models defined in Sections 4.1, 4.2, and 4.4 of [RFC3985] totally apply to this document with no changes needed 🙌.
The Network Synchronization reference model and the deployment scenarios for emulating TDM services are described in [RFC4197], Section 4.3 🗺️.
The structured services in this document are special cases of the "Structured bit stream" payload type defined in Section 3.3.4 of [RFC3985]. In each specific case, the basic service structures that a CESoPSN PW preserves are explicitly specified (see Section 3 below) 💜.
Following the principle of minimum intervention ([RFC3985], Section 3.3.5), the TDM payload is encapsulated without any changes 🫶. Hands off the data, bestie 🤚.
2.3. Requirements and Design Constraints
CESoPSN was designed to meet these design constraints 📐:
- Fixed amount of TDM data per packet: All the packets belonging to a given CESoPSN PW MUST carry the same amount of TDM data. This makes it way easier to fix a lost PW packet by sending a packet with exactly the same amount of "replacement" TDM data 🩹.
- Fixed end-to-end delay: CESoPSN implementations SHOULD provide the same end-to-end delay between a given pair of CEs, no matter what bit rate the emulated service is running at ⏱️.
- Packetization latency range:
- a) All the implementations of CESoPSN SHOULD support packetization latencies in the range 1 to 5 milliseconds 🏃♀️.
- b) CESoPSN implementations that support configurable packetization latency MUST allow configuration of this parameter with a granularity that is a multiple of 125 microseconds 🎚️.
- Common data path for services with and without CE application signaling (e.g., Channel-Associated Signaling (CAS)-- see [RFC4197]): If CE signaling has to be transferred between a pair of CE devices, in addition to TDM data, for the normal operation of the emulated service, that signaling is passed in dedicated signaling packets specific to the signaling protocol. The format and processing of the packets carrying TDM data stay exactly the same 🧃. Clean, clear, no drama 💖.
3. Emulated Services 🎀
Following [RFC4197], the structured services in this spec are NxDS0 services, with and without CAS 💅.
NxDS0 services usually ride inside appropriate physical trunks. The Provider Edges (PEs) that emulate them include the right Native Service Processing (NSP) blocks, which people often just call Framers 🖥️.
NSPs can also act as digital cross-connects, building structured TDM services out of multiple synchronous trunks. So the service might have more timeslots than any single trunk could carry, or the timeslots might not come from one trunk at all. Plot twist 😳🌈.
The reference PE architecture for these services is described in Appendix B 🏛️.
This document defines one single format for packets carrying TDM data, whether or not you need CAS or any other CE application signaling. The resulting "basic NxDS0 service" can be extended to carry CE application signaling (e.g., CAS) using separate signaling packets. Signaling packets MAY be carried in the same PW as the packets carrying TDM data, or in a separate dedicated PW 🧁.
This document also defines dedicated formats for carrying NxDS0 services with CAS, where the signaling sits in sub-structures inside some of the packets. These formats are different for NxDS0 services that came from different trunks, so when you use them you end up emulating trunk-specific NxDS0 services with CAS 🦋✨.
4. CESoPSN Encapsulation Layer 🎀
4.1. CESoPSN Packet Format 🎀
okay so the CESoPSN header MUST contain the CESoPSN Control Word (4 bytes) 💖 and it MAY also contain a fixed RTP header [RFC3550]. if the RTP header is in there, it MUST come right after the control word in every case except UDP demultiplexing, where it MUST go before the control word 🦋 (check out Figures 1a, 1b, and 1c below, they're giving everything ✨).
Note: why is the IP PSN with UDP demultiplexing layout different from the rest? the reasons are lowkey iconic 👑
- Compliance with the existing header compression mechanisms for IPv4/IPv6 PSNs with UDP demultiplexing means the RTP header has to sit right after the UDP header 🌸.
- Compliance with the common PWE3 mechanisms for keeping PWs Equal Cost Multipath (ECMP)-safe on the MPLS PSN, by giving PW-IP packet discrimination (see [RFC3985], Section 5.4.3) 🧚. this needs the PWE3 control word to sit right after the PW label.
- Commonality of the packet formats between MPLS networks and IPv4/IPv6 networks with Layer 2 Tunneling Protocol Version 3 (L2TPv3) demultiplexing makes it way easier to stitch L2TPv3-based and MPLS-based segments of CESoPSN PWs together (see [PWE3-MS]) 🫶. literally the best kind of teamwork.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and UDP (demultiplexing layer) headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| OPTIONAL |
+-- --+
| |
+-- --+
| Fixed RTP Header (see [RFC3550]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Packetized TDM data (Payload) |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1a. CESoPSN Packet Format for an IPv4/IPv6 PSN with
UDP demultiplexing 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MPLS Label Stack |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| OPTIONAL |
+-- --+
| |
+-- --+
| Fixed RTP Header (see [RFC3550]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Packetized TDM data (Payload) |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1b. CESoPSN Packet Format for an MPLS PSN 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and L2TPv3 (demultiplexing layer) headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| OPTIONAL |
+-- --+
| |
+-- --+
| Fixed RTP Header (see [RFC3550]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Packetized TDM data (Payload) |
| ... |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1c. CESoPSN Packet Format for an IPv4/IPv6 PSN with
L2TPv3 Demultiplexing4.2. PSN and Multiplexing Layer Headers 🦋
the total size of a CESoPSN packet for a specific PW MUST NOT exceed path MTU between the pair of PEs terminating this PW 🙈. no going over, bestie.
CESoPSN implementations working with IPv4 PSN MUST set the "Don't Fragment" flag in IP headers of the packets they generate 🔥.
usage of MPLS and L2TPv3 as demultiplexing layers is explained in [RFC3985] and [RFC3931], respectively 📚.
setup and maintenance of CESoPSN PWs over MPLS PSN is described in [PWE3-TDM-CONTROL] 🌈.
setup and maintenance of CESoPSN PWs over IPv4/IPv6 using L2TPv3 demultiplexing is defined in [L2TPEXT-TDM] 💜.
the destination UDP port MUST be used to multiplex and demultiplex individual PWs between nodes. architecturally (see [RFC3985]) this makes the destination UDP port act as the PW Label, which is so smart ✨.
UDP ports MUST be manually configured by both endpoints of the PW 🎀. the configured destination port together with both the source and destination IP addresses uniquely identifies the PW for the receiver. all UDP port values that function as PW labels SHOULD be in the range of dynamically allocated UDP port numbers (49152 through 65535) 🧚.
While many UDP-based protocols can traverse middleboxes without dire consequences, using UDP ports as PW labels makes middlebox traversal way harder. so it is NOT RECOMMENDED to use UDP-based PWs where port-translating middleboxes are present between PW endpoints 😭.
4.3. CESoPSN Control Word 🎀
Okay bestie, the CESoPSN Control Word is the one that MUST be used with every combo of the PSN and demultiplexing mechanisms from the last section 💅 Here's the layout:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|0|0|0|L|R| M |FRG| LEN | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 2. Structure of the CESoPSN Control Word
Bits 0 to 3 are covered in [RFC4385] 🦋 These bits MUST be set to zero unless they're being used to indicate the start of an Associated Channel Header (ACH). An ACH is needed if the state of the CESoPSN PW is being monitored using Virtual Circuit Connectivity Verification [RFC5085] 👀
- L: if set, it flags some abnormal condition of the attachment circuit 🚩
- M: a 2-bit modifier field 🌸 When L is cleared, this field lets you tell signaling packets apart and carry RDI of the attachment circuit across the PSN. When L is set, only the '00' value is currently defined, and the other values are reserved for future extensions. L and M bits can be treated as a 3-bit code point space, which Table 1 below breaks down in detail.
- R: if set by the PSN-bound IWF, it means its local CE-bound IWF is in the packet loss state, i.e., it has lost a pre-configured number of consecutive packets 😭 The R bit MUST be cleared by the PSN-bound IWF once its local CE-bound IWF has exited the packet loss state, i.e., has received a pre-configured number of consecutive packets ✨
|=================================================================|
| L | M | Code Point Interpretation |
|===|=====|=======================================================|
| 0 | 00 | CESoPSN data packet - normal situation. All CESoPSN |
| | | implementations MUST recognize this code point. |
| | | Payload MUST be played out "as received". |
|---|-----|-------------------------------------------------------|
| 0 | 01 | Reserved for future extensions. |
|---|-----|-------------------------------------------------------|
| 0 | 10 | CESoPSN data packet, RDI condition of the AC. All |
| | | CESoPSN implementations MUST support this codepoint: |
| | | payload MUST be played out "as received", and, if |
| | | so configured, the receiving CESoPSN IWF instance |
| | | SHOULD be able to command the NSP to force the RDI |
| | | condition on the outgoing TDM trunk. |
|---|-----|-------------------------------------------------------|
| 0 | 11 | Reserved for CESoPSN signaling packets. |
|---|-----|-------------------------------------------------------|
| 1 | 00 | TDM data is invalid; payload MAY be omitted. All |
| | | implementations MUST recognize this code point and |
| | | insert appropriate amount of the configured "idle |
| | | code" in the outgoing attachment circuit. In addition,|
| | | if so configured, the receiving CESoPSN IWF instance |
| | | SHOULD be able to force the AIS condition on the |
| | | outgoing TDM trunk. |
|---|-----|-------------------------------------------------------|
| 1 | 01 | Reserved for future extensions |
|---|-----|-------------------------------------------------------|
| 1 | 10 | Reserved for future extensions |
|---|-----|-------------------------------------------------------|
| 1 | 11 | Reserved for future extensions |
|=================================================================|Table 1. Interpretation of bits L and M in the CESoPSN CW
Notes:
- Bits in the M field are shown in the same order as in Figure 2 (i.e., bit 6 of the CW followed by bit 7 of the CW). 💅
- Implementations that do not support the reserved code points MUST silently discard the corresponding packets upon reception. 🙈
The FRG bits in the CESoPSN control word MUST be cleared for all services, excluding trunk-specific NxDS0 with CAS. For those services, they MAY be used to denote fragmentation of the multiframe structures between CESoPSN packets as described in [RFC4623]; see Section 5.4 below. ✨
LEN (bits (10 to 15) MAY be used to carry the length of the CESoPSN packet (defined as the size of the CESoPSN header + the payload size) if it is less than 64 bytes, and MUST be set to zero otherwise.
Note: If fixed RTP header is used in the encapsulation, it is considered part of the CESoPSN header. 🧚
The sequence number gives you the common PW sequencing function and helps you detect lost packets 🍓 It MUST be generated following the rules in Section 5.1 of [RFC3550] for the RTP sequence number, which means:
- Its space is a 16-bit unsigned circular space 🔁
- Its initial value SHOULD be random (unpredictable) 🎲
- It MUST be incremented with each CESoPSN data packet sent in the specific PW 📈
4.4. Usage of the RTP Header 🌈
CESoPSN MAY employ an RTP header when explicit transfer of timing information is required, but honestly this is purely formal reuse of the header format, not the full RTP vibe 💀 RTP mechanisms like header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure RTP (SRTP), etc., are not applicable to CESoPSN pseudowires. 🙅♀️
When a fixed RTP header (see [RFC3550], Section 5.1) is used with CESoPSN, its fields get used like this:
- V (version) is always set to 2. 💜
- P (padding), X (header extension), CC (CSRC count), and M (marker) are always set to 0. 🫶
- PT (payload type) is used as follows: 🎀
- a) One PT value MUST be allocated from the range of dynamic values (see [RTP-TYPES]) for each direction of the PW. The same PT value MAY be reused for both directions of the PW and also reused between different PWs.
- b) The PE at the PW ingress MUST set the PT field in the RTP header to the allocated value.
- c) The PE at the PW egress MAY use the received value to detect malformed packets.
- The sequence number in the RTP header MUST be equal to the sequence number in the CESoPSN CW. 🔢
- Timestamps are used for carrying timing information over the network ⏰
- a) Their values are generated in accordance with the rules established in [RFC3550].
- b) The frequency of the clock used for generating timestamps MUST be an integer multiple of 8 kHz. All implementations of CESoPSN MUST support the 8 kHz clock. Other frequencies that are integer multiples of 8 kHz MAY be used if both sides agree to that.
- c) Possible modes of timestamp generation are discussed below.
- The SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections. 🕵️♀️
The RTP header in CESoPSN can be used with at least the following modes of timestamp generation:
- Absolute mode: the ingress PE sets timestamps using the clock recovered from the incoming TDM circuit. As a consequence, the timestamps are closely correlated with the sequence numbers. All CESoPSN implementations MUST support this mode. 👑
- Differential mode: PE devices connected by the PW have access to the same high-quality synchronization source, and this synchronization source is used for timestamp generation. As a consequence, the second derivative of the timestamp series represents the difference between the common timing source and the clock of the incoming TDM circuit. Support of this mode is OPTIONAL. 🦋
5. CESoPSN Payload Layer 🌸
5.1. Common Payload Format Considerations 💖
All the services considered in this document are treated as sequences of "basic structures" (see Section 3 above). The payload of a CESoPSN packet always consists of a fixed number of octets, filled octet by octet with the data from the corresponding consecutive basic structures. This preserves octet alignment between those structures and the packet payload boundaries, following these rules:
- The order of the payload octets corresponds to their order on the TDM AC. 📋
- Consecutive bits coming from the TDM AC fill each payload octet, starting from its most significant bit to the least significant one. 🔍
- All the CESoPSN packets MUST carry the same amount of valid TDM data in both directions of the PW. In other words, the time that is required to fill a CESoPSN packet with the TDM data must be constant. The PE devices terminating a CESoPSN PW MUST agree on the number of TDM payload octets in the PW packets for both directions of the PW at the time of the PW setup. ⏱️
Notes:
- CESoPSN packets MAY omit invalid TDM data in order to save the PSN bandwidth. If the CESoPSN packet payload is omitted, the L bit in the CESoPSN control word MUST be set. 🥳
- CESoPSN PWs MAY carry CE signaling information either in separate packets or appended to packets carrying valid TDM data. If signaling information and valid TDM data are carried in the same CESoPSN packet, the amount of the former does not affect the amount of the latter. 🧠
5.2. Basic NxDS0 Services ✨
okay so the basic structure that gets carried across the PSN here is N octets filled with data from the matching NxDS0 channels in the same frame of the originating trunk(s), and the service makes 8000 of these structures every second 🎀
CESoPSN MUST line the basic structures up with the packet payload boundaries so they can be carried across the PSN. that means:
- The amount of TDM data in a CESoPSN packet MUST be an integer multiple of the basic structure size
- The first structure in the packet MUST start immediately at the beginning of the packet payload.
the resulting payload format is shown in Figure 3 below 🦋
0 1 2 3 4 5 6 7
--- +-+-+-+-+-+-+-+-+
| Timeslot 1 |
+-+-+-+-+-+-+-+-+
| Timeslot 2 |
Frame #1 | ... |
| Timeslot N |
--- +-+-+-+-+-+-+-+-+
| Timeslot 1 |
+-+-+-+-+-+-+-+-+
| Timeslot 2 |
Frame #2 | ... |
| Timeslot N |
--- +-+-+-+-+-+-+-+-+
... | ... |
--- +-+-+-+-+-+-+-+-+
| Timeslot 1 |
+-+-+-+-+-+-+-+-+
| Timeslot 2 |
Frame #m | ... |
| Timeslot N |
--- +-+-+-+-+-+-+-+-+Figure 3. The CESoPSN Packet Payload Format for the Basic NxDS0 Service
this mode of operation follows the advice in [RFC3985] to use similar encapsulations for structured bit stream and cell generic payload types 💜
packetization latency, number of timeslots, and payload size are linked by this super obvious relationship:
L = 8*N*Dwhere:
- D is packetization latency, milliseconds
- L is packet payload size, octets
- N is number of DS0 channels.
CESoPSN implementations supporting NxDS0 services MUST support the following set of configurable packetization latency values:
- For N = 1: 8 milliseconds (with the corresponding packet payload size of 64 bytes)
- For 2 <=N <= 4: 4 millisecond (with the corresponding packet payload size of 32*N bytes)
- For N >= 5: 1 millisecond (with the corresponding packet payload size of 8*N octets).
Support of 5 ms packetization latency for N = 1 is RECOMMENDED 🌸
Usage of any other packetization latency (packet payload size) that is compatible with the restrictions described above is OPTIONAL 🍓
5.3. Extending Basic NxDS0 Services with CE Application Signaling 🌈
okay this part is for implementations that want to level up the basic NxDS0 service and support CE application state signaling. these implementations carry the encoded CE application state signals in separate signaling packets 💅
the format of the CESoPSN signaling packets over both IPv4/IPv6 and MPLS PSNs, for when the CE keeps a separate application state per DS0 channel (e.g., CAS for the telephony applications), is shown in Figures 4a and 4b below, respectively 🧚
Signaling packets SHOULD be carried in a separate dedicated PW. however, implementations MAY carry them in the same PW as the TDM data packets for the basic NxDS0 service. the methods of "pairing" the PWs that carry TDM data and signaling packets for the same extended NxDS0 service are out of scope of this document 🙈
no matter how the signaling packets get carried across the PSN, these rules apply:
- The CESoPSN signaling packets MUST:
- a) Use their own sequence numbers in the control word
- b) Set the flags in the control word like following:
- i) L = 0
- ii) M = '11'
- iii) R = 0
- If an RTP header is used in the data packets, it MUST be also used in the signaling packets with the following restrictions:
- a) An additional RTP payload type (from the range of dynamically allocated types) MUST be allocated for the signaling packets.
- b) In addition, the signaling packets MUST use their own SSRC value.
the protocol used to make sure signaling packets get delivered reliably is discussed in Appendix A 👑
encoding of CE application state for telephony applications using CAS follows [RFC2833] (which has since been obsoleted by [RFC4733] and [RFC4734], but those do not affect the relevant text) ✨
encoding of CE application state for telephony applications using CCS will be considered in a separate document 🫶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and multiplexing layer headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| OPTIONAL Fixed |
+-- --+
| RTP |
+-- --+
| Header (see [RFC3550]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Encoded CE application state entry for the DS0 channel #1 |
+-- --+
| ... |
+-- --+
| Encoded CE application state entry for the DS0 channel #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4a. CESoPSN Signaling Packet Format over an IPv4/IPv6 PSN
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MPLS Label Stack |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| CESoPSN Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| OPTIONAL Fixed |
+-- --+
| RTP |
+-- --+
| Header (see [RFC3550]) |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| Encoded CE application state entry for the DS0 channel #1 |
+-- --+
| ... |
+-- --+
| Encoded CE application state entry for the DS0 channel #N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+Figure 4b. CESoPSN Signaling Packet Format over an MPLS PSN
5.4. Trunk-Specific NxDS0 Services with CAS ✨
okay so this is the trunk-specific NxDS0 with CAS era 💅 CESoPSN keeps the trunk multiframe split into its trunk frames 🎀 and the signaling info gets tacked onto the end of the TDM data, using the signaling substructures from [ATM-CES]. Each substructure is N consecutive nibbles, so the i-th nibble holds the CAS bits for the i-th DS0 channel, and if N is odd you add a dummy nibble as padding 🫶
CESoPSN implementations supporting trunk-specific NxDS0 services with CAS MUST NOT carry more TDM data per packet than is contained in a single trunk multiframe. no overstuffing the packets, bestie 🙅♀️
All CESoPSN implementations supporting trunk-specific NxDS0 with CAS MUST support the default mode 👑 In the default mode, one CESoPSN packet carries exactly the amount of TDM data in exactly one trunk multiframe, with the signaling substructure appended. The TDM data lines up with the packet payload. In this case:
- Packetization latency is:
- a) 2 milliseconds for E1 NxDS0
- b) 3 milliseconds for T1 NxDS0
- The packet payload size is:
- a)
16*N + floor((N+1)/2)for E1-NxDS0 - b)
24*N + floor((N+1)/2)for T1/ESF-NxDS0 and T1/SF- NxDS0
- a)
- The packet payload format coincides with the multiframe structure described in [ATM-CES] (Section 2.3.1.2).
In order to get lower packetization latency, CESoPSN implementations for trunk-specific NxDS0 with CAS SHOULD support fragmentation of multiframe structures between multiple CESoPSN packets 🌈 In this case:
- The FRG bits MUST be used to indicate first, intermediate, and last fragment of a multiframe as described in [RFC4623].
- The amount of the TDM data per CESoPSN packet must be constant.
- Each multiframe fragment MUST comprise an integer multiple of the trunk frames.
- The signaling substructure MUST be appended to the last fragment of each multiframe.
The format of CESoPSN packets carrying trunk-specific NxDS0 service with CAS, both with and without signaling substructures, is shown in Figures 5 (a) and (b) respectively 🦋 In these figures, the number of the trunk frames per multiframe fragment ("m") MUST be an integer divisor of the number of frames per trunk multiframe.
--- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+
| Timeslot 1 | | Timeslot 1 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 2 | | Timeslot 2 |
Frame #1 | ... | Frame #1 | ... |
| Timeslot N | | Timeslot N |
--- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+
| Timeslot 1 | | Timeslot 1 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 2 | Frame #2 | Timeslot 2 |
Frame #2 | ... | | ... |
| Timeslot N | | Timeslot N |
--- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+
... | ... | | ... |
--- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+
| Timeslot 1 | | Timeslot 1 |
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Timeslot 2 | | Timeslot 2 |
Frame #m | ... | Frame #m | ... |
| Timeslot N | | Timeslot N |
--- +-+-+-+-+-+-+-+-+ --- +-+-+-+-+-+-+-+-+
Nibbles 1,2 |A B C D|A B C D|
+-+-+-+-+-+-+-+-+
Nibbles 3,4 |A B C D|A B C D|
+-+-+-+-+-+-+-+-+
Nibble n |A B C D| (pad) |
(odd) & pad +-+-+-+-+-+-+-+-+
(a) The packet with (b) The packet without
the signaling structure the signaling structure
(the last fragment of (not the last fragment
the multiframe) of the multiframe)
Figure 5. The CESoPSN Packet Payload Format for
Trunk-Specific NxDS0 with CASNotes:
- In case of T1-NxDS0 with CAS, the signaling bits are carried in the TDM data, as well as in the signaling substructure. However, the receiver MUST use the CAS bits as carried in the signaling substructures. 🔥 the receiver is the one who needs to listen to the substructure, not the TDM bits.
- In case of trunk-specific NxDS0 with CAS originating in a T1-SF trunk, each nibble of the signaling substructure contains A and B bits from two consecutive trunk multiframes as described in [ATM-CES].
6. CESoPSN Operation 🧚
6.1. Common Considerations
okay so edge-to-edge emulation of a TDM service using CESoPSN only works when the two PW attachment circuits are the same type (basic NxDS0 or one of the trunk-specific NxDS0 with CAS) and the same bit rate 💖 The service type and bit rate get swapped at PW setup, as described in [RFC4447].
6.2. IWF Operation
6.2.1. PSN-Bound Direction
Once the PW is set up, the PSN-bound CESoPSN IWF does the following 🌸
- TDM data gets packetized using the configured number of payload bytes per packet.
- Sequence numbers, flags, and timestamps (if the RTP header is used) go into the CESoPSN headers. For trunk-specific NxDS0 with CAS, signaling substructures get appended to the packets carrying the last fragment of a multiframe.
- CESoPSN, multiplexing layer, and PSN headers get prepended to the packetized service data.
- The resulting packets are transmitted over the PSN.
6.2.2. CE-Bound Direction
The CE-bound CESoPSN IWF SHOULD include a jitter buffer 🍓 The received CESoPSN packets' payload gets stored there before it's played out to the local TDM attachment circuit. The size of this buffer SHOULD be locally configurable, so it can adapt to the PSN-specific packet delay variation.
The CE-bound CESoPSN IWF MUST detect lost and misordered packets. It SHOULD use the sequence number in the control word for these purposes, but if the RTP header is used, the RTP sequence number MAY be used instead.
The CE-bound CESoPSN IWF MAY reorder misordered packets. Misordered packets that cannot be reordered MUST be discarded and treated as lost.
The payload of received CESoPSN data packets marked with the L bit set SHOULD be replaced by the equivalent amount of some locally configured "idle" bit pattern, even if it has not been omitted. On top of that, the CE-bound CESoPSN IWF will be locally configured to tell its local NSP what to do, picking one of these actions:
- None (MUST be supported by all the implementations)
- Transmit the AIS pattern towards the local CE on the E1 or T1 trunk carrying the local attachment circuit (support of this action is RECOMMENDED)
- Send the "Channel Idle" signal to the local CE for all the DS0 channels comprising the local attachment circuit (support of this action is OPTIONAL).
If the data packets received are marked with L bit cleared and M bits set to '10', or with R bit set, the CE-bound CESoPSN IWF will be locally configured to tell its local NSP what to do, picking one of these actions:
- None (MUST be supported by all the implementations)
- Transmit the RAI pattern towards the local CE on the E1 or T1 trunk carrying the local attachment circuit (support of this action is RECOMMENDED)
- Send the "Channel Idle" signal to the local CE for all the DS0 channels comprising the local attachment circuit (support of this action is OPTIONAL and requires also that the CE-bound CES IWF replaces the actually received payload with the equivalent amount of the locally configured "idle" bit pattern.
Notes:
- If the pair of IWFs at the two ends of the PW have been configured to force the TDM trunks carrying their ACs to transmit AIS upon reception of data packets with the L bit set, and to transmit RAI upon reception of data packets with the R bit set or with the L bit cleared and M bits set to '10', this PW provides a bandwidth-saving emulation of a fractional E1 or T1 service between the pair of CE devices 💜
- If the pair of IWFs at the two ends of the PW have been configured to signal "Channel Idle" CE application state to its local CE upon reception of packets marked with L bit set, R bit set, or (L,M) set to '010', and to replace the actually received payload with the locally configured "idle" bit pattern, the resulting PW will comply with the requirements for Downstream Trunk conditioning as defined in [TR-NWT-170].
- Usage of bits R, L, and M described above additionally provides the tools for "single-ended" management of the CESoPSN pseudowires, with the ability to distinguish between problems in the PSN and in the TDM attachment circuits 🫶
The payload of each lost CESoPSN data packet MUST be replaced with the equivalent amount of the replacement data. The contents of the replacement data are implementation-specific and MAY be locally configurable. By default, all CESoPSN implementations MUST support generation of the locally configurable "idle" pattern as the replacement data.
Before a PW has been set up and after a PW has been torn down, the IWF MUST play out the locally configurable "idle" pattern to its TDM attachment circuit.
Once the PW has been set up, the CE-bound IWF begins to receive CESoPSN packets and to store their payload in the jitter buffer, but it keeps playing out the locally configurable "idle" pattern to its TDM attachment circuit ⭐ This intermediate state lasts until a pre-configured amount of TDM data (usually half of the jitter buffer) has been received in consecutive CESoPSN packets, or until a pre-configured intermediate state timer expires.
Once the pre-configured amount of TDM data has been received, the CE-bound CESoPSN IWF enters its normal operation state 🎀 It keeps receiving CESoPSN packets and storing their payload in the jitter buffer, while playing out the contents of the jitter buffer in accordance with the required clock. In this state, the CE-bound IWF performs clock recovery, MAY monitor PW defects, and MAY collect PW performance-monitoring data.
If the CE-bound CESoPSN IWF detects loss of a pre-configured number of consecutive packets, or if the intermediate state timer expires before the required amount of TDM data has been received, it enters its packet loss state 💀 While in this state:
- The locally configurable "idle" pattern SHOULD be played out to the TDM attachment circuit.
- The local PSN-bound CESoPSN IWF SHOULD mark every packet it transmits with the R bit set.
The CE-bound CESoPSN IWF leaves this state and transitions back to the normal one once a pre-configured number of consecutive CESoPSN packets have been received 🦋
6.3. CESoPSN Defects 💅✨
Okay so, besides the packet loss state of the CE-bound CESoPSN IWF we just talked about, the IWF MAY also detect these defects, bestie 🫶:
- Stray packets
- Malformed packets
- Excessive packet loss rate
- Buffer overrun
- Remote packet loss
Each defect has its own defect state of the IWF, a detection criterion that kicks the IWF out of normal operation and into that defect state, and an alarm that MAY get reported to the management system and then cleared later 🔔. Alarms only show up if the defect state sticks around for a pre-configured amount of time (typically 2.5 seconds), and they MUST be cleared once the defect has been undetected for a second pre-configured amount of time (typically 10 seconds) 🧹. The trigger and release times for the different alarms can be set independently, so they don't have to match, which is very mix-and-match of them 💜.
Stray packets MAY be detected by the PSN and multiplexing layers 🕵️♀️. If you're using RTP, the SSRC field in the RTP header MAY be used for this too. Stray packets MUST be discarded by the CE-bound IWF, and detecting them MUST NOT affect how packet loss detection works. Don't let the stray packet drama mess with the loss detection, periodt 🙅♀️.
Malformed packets MAY be detected when the expected packet size (with the L bit taken into account) doesn't match the actual packet size that the PSN and multiplexing layers show. If RTP is in use, a mismatch between the PT value and the one allocated for this direction of the PW MAY also be used for this purpose 🎀. Other ways of spotting malformed packets are implementation-specific, so do your own thing there 🛠️. Malformed in-order packets MUST be discarded by the CE-bound IWF, and replacement data gets generated the same way it does for lost packets 🩹.
Excessive packet loss rate is detected by working out the average packet loss rate over a configurable amount of times and then comparing it to a pre-configured threshold 📉.
Buffer overrun shows up in the normal operation state when the jitter buffer of the CE-bound IWF can't fit newly arrived CESoPSN packets. Too many packets, not enough room, it's giving overflowing 🌊.
Remote packet loss gets indicated when packets come in with their R bit set 🚩.
6.4. CESoPSN PW Performance Monitoring 📊🌸
Okay, performance monitoring (PM) parameters get collected all the time for TDM services, and they're a huge maintenance tool in TDM networks 🧰. So being able to collect compatible PM parameters for CESoPSN PWs really levels up their maintenance game 🆙.
Collecting the CESoPSN PW performance monitoring parameters is OPTIONAL. If you do implement it, it only happens after the CE-bound IWF has exited its intermediate state 🚪.
CESoPSN defines error events, errored blocks, and defects like this 📝:
- A CESoPSN error event is when a single replacement packet gets inserted into the jitter buffer. Replacing the payload of CESoPSN packets with the
Lbit set does not count as inserting a replacement packet, so don't count those 🙅♀️. - A CESoPSN errored data block is a block of data played out to the TDM attachment circuit. Its size follows the [G.826] rules for the matching TDM service, and it has experienced at least one CESoPSN error event 💔.
- A CESoPSN defect is the packet loss state of the CE-bound CESoPSN IWF 🚨.
The CESoPSN PW PM parameters (Errored, Severely Errored, and Unavailable Seconds) come straight from these definitions, following [G.826] 🎯.
7. QoS Issues 👑
So if the PSN connecting the PE devices is Diffserv-enabled and offers a per-domain behavior (PDB) [RFC3086] that guarantees low jitter and low loss, the CESoPSN PW SHOULD use that PDB and follow the admission and allocation rules the PSN set up for it. For example, that means marking packets the way the PSN tells you to 🏷️✨. Main character QoS energy 🦋.
8. Congestion Control 🚦
As [RFC3985] explains, the PSN carrying the PW may run into congestion 🚗💨. CESoPSN PWs are inelastic, constant bit rate (CBR) flows, so they can't back off in the TCP-friendly way that [RFC2914] describes. The share of total bandwidth they eat stays the same no matter what, which is a lot 😤.
If nobody takes precautions, that unchanging bandwidth demand from CESoPSN PWs can add to network congestion, and that can mess with network control protocols 😭.
Whenever it's possible, CESoPSN PWs SHOULD run over traffic-engineered PSNs. Those either reserve bandwidth with admission control, or they give forwarding priority and boundary traffic conditioning. Examples are IntServ-enabled domains that support Guaranteed Service (GS) [RFC2212], and Diffserv-enabled domains [RFC2475] that support Expedited Forwarding (EF) [RFC3246] 💅. These mechanisms cut down, to some degree, the impact CESoPSN PWs have on the streams next to them 🫶. To make boundary traffic conditioning of CESoPSN traffic easier over IP PSNs, the CESoPSN IP packets SHOULD NOT use the Diffserv Code Point (DSCP) value reserved for the Default PHB [RFC2474] 🙅♀️🎀.
If CESoPSN PWs run over a best-effort PSN, they SHOULD keep an eye on packet loss so they can spot "severe congestion" 👀. If they do detect it, a CESoPSN PW SHOULD shut down in both directions for a while, as described in Section 6.5 of [RFC3985] 🛑.
A few notes, because the details matter ✍️:
- The CESoPSN IWF can measure packet loss on its own, since the rate CESoPSN packets arrive at is fixed and known 🧮.
- The CESoPSN packet loss results might not reliably show whether severe congestion is there or not, if the PSN gives enhanced delivery. For example:
- a) If CESoPSN traffic takes precedence over non-CESoPSN traffic, severe congestion can build up without much CESoPSN packet loss 😶.
- b) If non-CESoPSN traffic takes precedence over CESoPSN traffic, CESoPSN may lose a lot of packets because of a short burst of high-priority traffic 💥.
- The TDM services that CESoPSN PWs emulate have high availability objectives (see [G.826]), and these MUST be taken into account before you decide to temporarily shut down a CESoPSN PW 🫡.
This specification does not define the exact criteria for detecting "severe congestion" from the CESoPSN packet loss rate, and it doesn't define the specific methods for a bidirectional shutdown of CESoPSN PWs once severe congestion is detected, or how they restart after a suitable delay. That's left for further study 🔭. Still, these considerations can be used as guidelines for implementing the CESoPSN severe congestion shutdown mechanism 🧭:
- CESoPSN Performance Monitoring techniques (see Section 6.4) give entry and exit criteria for the CESoPSN PW "Unavailable" state. That makes it closely correlated with the "Unavailable" state of the emulated TDM circuit specified in [G.826]. Using the same criteria for "severe congestion" detection may lower the risk of shutting down the CESoPSN PW while the CE still considers the emulated TDM circuit available 🥰.
- If the CESoPSN PW was set up using either the PWE3 control protocol [RFC4447] or L2TPv3 [RFC3931], the regular PW teardown procedures of those protocols SHOULD be used 🧹.
- If one of the CESoPSN PW end points stops sending packets for a long enough time, its peer will see 100% packet loss and will necessarily detect "severe congestion". That peer will then stop transmitting too, so you get a bidirectional PW shutdown with no extra effort 🤝✨.
9. Security Considerations 🔐
CESoPSN doesn't make the security of the underlying PSN any better or any worse. Instead, it relies on the PSN's own mechanisms for encryption, integrity, and authentication whenever they're needed 🛡️.
CESoPSN PWs share their vulnerability to a number of pseudowire-layer attacks 😬. They'll use whatever confidentiality, integrity, and authentication mechanisms get developed for general PWs. Those methods are beyond the scope of this document 🙈.
Even though CESoPSN PWs MAY employ an RTP header when explicit transfer of timing information is required, you can't use SRTP (see [RFC3711]) mechanisms as a stand-in for PW layer security. Not a substitute, bestie, no cap 🚫.
🚨 Important: SRTP is NOT a replacement for PW layer security here. Don't skip the PW-layer protections just because RTP is in the picture.
The misconnection detection capabilities of CESoPSN make it more resilient to misconfiguration and to some types of DoS attacks 💪.
Random initialization of sequence numbers, in both the control word and the optional RTP header, makes known-plaintext attacks on encrypted CESoPSN PWs harder to pull off 🎲🔒. Encryption of PWs is beyond the scope of this document 🙃.
10. IANA Considerations 📋
The allocation of PW Types for the corresponding CESoPSN PWs is defined in [RFC4446] 🦋.
11. Applicability Statement 🦋
Okay bestie, this is the section where they explain where CESoPSN actually slays 💅. It's an encapsulation layer for carrying NxDS0 services, with or without CAS, over a PSN ✨.
CESoPSN can emulate certain end-to-end delay properties of TDM networks 🕰️. The big win is that the end-to-end delay of a TDM circuit emulated by a CESoPSN PW does not depend on the bit rate of the service. Iconic 👑.
It also fully complies with the principle of minimal intervention 🌸. The overhead is kept small, and so is the computational power needed for encapsulation. Lean and mean 🧚.
CESoPSN works with various clock recovery techniques and does not assume a global synchronous clock is available at the ends of a PW ⏱️. BUT if that global synchronous clock is available at both ends of a CESoPSN PW, using RTP and differential mode of timestamp generation makes the recovered clock better quality 🎀.
CESoPSN can carry CE application state signaling that needs to stay synchronized with data, using in-band separate signaling packets 📦. A special combo of flags in the CESoPSN control word tells data and signaling packets apart, and the Timestamp field in the RTP headers handles the synchronization 🫶. The best part is that this makes CESoPSN extendable to different types of CE signaling without messing with the data path in the PE devices 💖.
CESoPSN also lets you emulate NxDS0 services with CAS, where the signaling info gets appended to (some of) the packets carrying the TDM data 🍓.
It can save PSN bandwidth by carrying only AIS and/or Idle Code indications instead of data 🌈.
It also allows bandwidth-saving Fractional point-to-point E1/T1 applications 🦋. Here's how those work:
- The pair of CE devices acts as if they're connected by an emulated E1 or T1 circuit. Specifically, it reacts to AIS and RAI states of its local ACs in the standard way 💅.
- The PSN only carries an NxDS0 service, where N is the number of actually used timeslots in the circuit connecting the pair of CE devices. That's how the bandwidth gets saved 💸.
Being a constant bit rate (CBR) service, CESoPSN can't provide TCP-friendly behavior under network congestion 😭. So if the service runs into congestion, it SHOULD be temporarily shut down 🛑.
CESoPSN can collect TDM-like faults and performance monitoring parameters, which means it can emulate 'classic' carrier services of TDM circuits (e.g., SONET/SDH) 🧚♀️. It gets even more similar to those services because CESoPSN can carry 'far end error' indications 👀.
CESoPSN also has a carrier-independent ability to detect misconnections and malformed packets 🕵️♀️. That makes the emulated service more resilient to misconfiguration and DoS attacks 🛡️.
CESoPSN detects lost packets and lets you use various techniques to generate "replacement packets" 🩹.
It carries indications of outages on the incoming attachment circuit across the PSN too 🚨. That gives you effective fault isolation, which is so helpful 🫶.
A CESoPSN PW can be even more faithful if the carrying PSN is Diffserv-enabled and implements a PDB that guarantees low loss and low jitter ✨.
Now the honest tea ☕. CESoPSN does NOT have any mechanisms for protecting against PSN outages 😬. So how resilient the emulated service is to those outages comes down to how the PSN behaves. BUT there are a couple of perks:
- The jitter buffer and packet reordering mechanisms associated with CESoPSN make the emulated service more resilient to fast PSN re-convergence events 🏃♀️.
- Remote indication of lost packets gets carried backward across the PSN, from the receiver that detected the loss to the transmitter 🔙. Such an indication MAY be used as a trigger for activating proprietary, service-specific protection mechanisms 🔐.
Last but not least, security of TDM services provided by CESoPSN across a shared PSN may be below the level of security people usually expect from TDM services carried across TDM networks 🙈. So keep that in mind, babe 🫣.
12. Acknowledgements 💜
Akiva Sadovski was an active participant on the team that co-authored the early versions of this document 🤝.
We express deep gratitude to Stephen Casner, who reviewed an early version of this document in detail, corrected some serious errors, and provided many valuable inputs 🙌.
The present version of the text of the QoS section was suggested by Kathleen Nichols 🌟.
We thank Maximilian Riegel, Sim Narasimha, Tom Johnson, Ron Cohen, and Yaron Raz for valuable feedback 💖.
We thank Alik Shimelmits for many fruitful discussions 🍓.
13. Normative References 📚
[ATM-CES]The ATM Forum Technical Committee. Circuit Emulation Service Interoperability Specification version 2.0 af-vtoa-0078.000, January 1997.[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 Structured Defined in Recommendation G.704[G.775]ITU-T Recommendation G.775 (10/98) - Loss of Signal (LOS), Alarm Indication Signal (AIS), and Remote Defect Indication (RDI) Defect Detection and Clearance Criteria for PDH Signals[G.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[RFC2119]Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.[RFC2833]Schulzrinne, H. and S. Petrack, "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals", RFC 2833, May 2000.[RFC2914]Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000.[RFC3086]Nichols, K. and B. Carpenter, "Definition of Differentiated Services Per Domain Behaviors and Rules for their Specification", RFC 3086, April 2001.[RFC3916]Xiao, X., McPherson, D., and P. Pate, "Requirements for Pseudo-Wire Emulation Edge-to-Edge (PWE3)", RFC 3916, September 2004.[RFC4197]Riegel, M., "Requirements for Edge-to-Edge Emulation of Time Division Multiplexed (TDM) Circuits over Packet Switching Networks", RFC 4197, October 2005.[RFC3985]Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture", RFC 3985, March 2005.[RFC3550]Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003.[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.[RFC4447]Martini L. et al, Pseudowire Setup and Maintenance Using the Label Distribution Protocol (LDP), RFC 4447, April 2006[RFC4623]Malis, A. and M. Townsley, "Pseudowire Emulation Edge-to-Edge (PWE3) Fragmentation and Reassembly", RFC 4623, August 2006.[RTP-TYPES]RTP PARAMETERS,<http://www.iana.org/assignments/rtp-parameters>.[TR-NWT-170]Digital Cross Connect Systems - Generic Requirements and Objectives, Bellcore, TR-NWT-170, January 1993
14. Informative References 🧠
[L2TPEXT-TDM]Vainshtein, A. and S. Galtsur, "Layer Two Tunneling Protocol - Setup of TDM Pseudowires", Work in Progress, February 2007.[PWE3-MS]Martini, L., Metz, C., Nadeau, T., and M. Duckett, "Segmented Pseudo Wire", Work in Progress, November 2007.[PWE3-TDM-CONTROL]Vainshtein, A. and Y. Stein, "Control Protocol Extensions for Setup of TDM Pseudowires in MPLS Networks", Work in Progress, November 2007.[RFC2212]Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997.[RFC2474]Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.[RFC2475]Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998.[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.[RFC3931]Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.[RFC4446]Martini, L., "IANA Allocations for Pseudowire Edge to Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.[RFC4553]Vainshtein, A. and YJ. Stein, "Structure-Agnostic Time Division Multiplexing (TDM) over Packet (SAToP)", RFC 4553, June 2006.[RFC4733]Schulzrinne, H. and T. Taylor, "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals", RFC 4733, December 2006.[RFC4734]Schulzrinne, H. and T. Taylor, "Definition of Events for Modem, Fax, and Text Telephony Signals", RFC 4734, December 2006.[RFC5085]Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire Virtual Circuit Connectivity Verification (VCCV): A Control Channel for Pseudowires", Work in Progress, RFC 5085, December 2007.
Appendix A. A Common CE Application State Signaling Mechanism ✨
okay bestie, this appendix is all about how the CE application state signaling packets get made 🎀 Their format was already covered back in Section 5.3, so we're not doing that again 💅
The sequence number in the CESoPSN control word for the signaling packets gets generated with the exact same rules as the TDM data packets. Same vibes, same rules 🫶
If the RTP header is used in the CESoPSN signaling packets, the timestamp in that header shows the time when the CE application state was collected ⏰
The ingress PE makes the signaling packets using the logic below (adapted from [RFC2833]) 🧚
- The CESoPSN signaling packet with the same information (including the timestamp in the case RTP header is used) is sent 3 times at an interval of 5 ms under one of the following conditions:
- a) The CESoPSN PW has been set up
- b) A change in the CE application state has been detected. If another change of the CE application state has been detected during the 10 ms period (i.e., before all 3 signaling packets reporting the previous change have been sent), this process is re-started, i.e.:
- i) The unsent signaling packet(s) with the previous CE application state are discarded
- ii) Triple send of packets with the new CE application state begins.
- c) Loss of packets defect has been cleared
- d) Remote Loss of Packets indication has been cleared (after previously being set)
- Otherwise, the CESoPSN signaling packet with the current CE application state information is sent every 5 seconds.
These rules give you fast, probabilistic recovery after losing a single signaling packet 🦋 They also give you deterministic (but possibly slow) recovery after PW setup and PSN outages 🌈
Appendix B. Reference PE Architecture for Emulation of NxDS0 Services 🌸
Structured TDM services don't exist as physical circuits, bestie 🙈 They always ride inside physical attachment circuits (AC), and the PE that emulates them always has a Native Service Processing Block (NSP), which people usually call the Framer. So a PE doing edge-to-edge emulation for these services includes the Framer and Forwarder blocks 💖
For NxDS0 services (the only structured services this document looks at), the AC is either an E1 or a T1 trunk, and bundles of NxDS0 get cut out of it using one of the framing methods in [G.704] 🍓
Besides detecting the FAS and giving the "trunk" AC, E1, and T1 their structure, framers usually do a few extra things too:
- Detection of special states of the incoming AC (e.g., AIS, OOF, or RAI)
- Forcing special states (e.g., AIS and RAI) on the outgoing AC upon explicit request
- Extraction and insertion of CE application signals that may accompany specific DS0 channel(s).
Here's the resulting PE architecture for NxDS0 services, shown in Figure B.1 below. In this diagram:
- In the PSN-bound direction:
- a) The Framer:
- i) Detects frame alignment signal (FAS) and splits the incoming ACs into separate DS0 channels
- ii) Detects special AC states
- iii) If necessary, extracts CE application signals accompanying each of the separate DS0 services
- b) The Forwarder:
- i) Creates one or more NxDS0 bundles
- ii) Sends the data received in each such bundle to the PSN-bound direction of a respective CESoPSN IWF instance
- iii) If necessary, sends the current CE application state data of the DS0 services in the bundle to the PSN-bound direction of the respective CESoPSN IWF instance
- iv) If necessary, sends the AC state indications to the PSN-bound directions of all the CESoPSN instances associated with the given AC
- c) Each PSN-bound PW IWF instance encapsulates the received data, application state signal, and the AC state into PW PDUs, and sends the resulting packets to the PSN
- a) The Framer:
- In the CE-bound direction:
- a) Each CE-bound instance of the CESoPSN IWF receives the PW PDUs from the PSN, extracts the TDM data, AC state, and CE application state signals, and sends them
- b) The Forwarder sends the TDM data, application state signals and, if necessary, a single command representing the desired AC state, to the Framer
- c) The Framer accepts all the data of one or more NxDS0 bundles possibly accompanied by the associated CE application state, and commands referring to the desired AC state, and generates a single AC accordingly with correct FAS.
Notes: this model is asymmetric, so keep that in mind 👀
- AC state indication can be forwarded from the framer to multiple instances of the CESoPSN IWF
- No more than one CESoPSN IWF instance should forward AC state-affecting commands to the framer.
+------------------------------------------+
| PE Device |
+------------------------------------------+
| | Forwarder | |
| |---------------------| |
| | | |
| +<-- AC State---->- | |
| | | | |
| | | | |
E1 or T1 | | | | |
AC | | | | |
<=======>| |-----------------+---|--------------|
| | | | At most, one |
| | |-->+ PW IWF |
| | | instance |
... | +<---NxDS0 TDM Data-->+ imposing | PW Instance
| F | | state X<===========>
| +<---CE App State --->+ on the |
E1 or T1 | R | | outgoing AC |
AC | +<--AC Command -------+ |
<=======>o A |---------------------|--------------|
| | ... | ... | ...
| M |-----------------+---|--------------|
| | | | Zero, one or |
| E | |-->+ more PW IWF |
| | | instances |
| R +<---NxDS0 TDM Data-->+ that do not | PW Instance
| | | impose state X<===========>
| +<---CE App State --->+ on the out- |
| | | going AC |
+------------------------------------------+
Figure B.1. Reference PE Architecture for NxDS0 ServicesAppendix C. Old Mode of CESoPSN Encapsulation Over L2TPV3 🧸
Earlier versions of this spec defined a CESoPSN PW encapsulation over L2TPv3 that's different from the one in Section 4.1 and Figure 1c 👑 In those versions, the RTP header (if used) comes before the CESoPSN control word.
Existing implementations of the old encapsulation mode MUST be distinguished from the encapsulations conforming to this specification via the CESoPSN PW setup. 🌈
Authors' Addresses 🎀
Alexander ("Sasha") Vainshtein
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
EMail: sasha@axerra.com, vainshtein.alex@gmail.com
Israel Sasson
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
EMail: israel@axerra.com
Eduard Metz
KPN
Regulusweg 1
2316 AC The Hague
Netherlands
EMail: eduard.metz@kpn.com
Tim Frost
Symmetricom, Inc.
Tamerton Road
Roborough, Plymouth
PL6 7BQ, UK
EMail: tfrost@symmetricom.com
Prayson Pate
Overture Networks
507 Airport Boulevard
Building 111
Morrisville, North Carolina 27560 USA
EMail: prayson.pate@overturenetworks.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.
The legal fine print, bestie, and it matters 📜
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 🦋
The IETF doesn't take a position on whether any Intellectual Property Rights or other rights that someone might claim over the technology in this document are valid or in scope, or on whether any license under those rights might be available. It also doesn't claim to have made any independent effort to find such rights. For the procedures on rights in RFC documents, check BCP 78 and BCP 79 🔍
Copies of IPR disclosures made to the IETF Secretariat, any assurances of licenses to be made available, or the result of an attempt to get a general license or permission for implementers or users to use those proprietary rights can be found in the IETF's online IPR repository at http://www.ietf.org/ipr.
The IETF invites anyone to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that might cover technology needed to implement this standard. Send that info to the IETF at ietf-ipr@ietf.org 💜
📦 where this page comes from
- ietf: rfc5086 2007-12
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms