Request for Comments: 4553 Axerra Networks
Category: Standards Track YJ. Stein, Ed.
RAD Data Communications
June 2006
Structure-Agnostic Time Division Multiplexing (TDM)
over Packet (SAToP)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes a pseudowire encapsulation for Time Division
Multiplexing (TDM) bit-streams (T1, E1, T3, E3) that disregards any
structure that may be imposed on these streams, in particular the
structure imposed by the standard TDM framing.
Table of Contents
1. Introduction ....................................................3
2. Terminology and Reference Models ................................3
2.1. Terminology ................................................3
2.2. Reference Models ...........................................4
3. Emulated Services ...............................................4
4. SAToP Encapsulation Layer .......................................5
4.1. SAToP Packet Format ........................................5
4.2. PSN and PW Demultiplexing Layer Headers ....................5
4.3. SAToP Header ...............................................6
4.3.1. Usage and Structure of the Control Word .............8
4.3.2. Usage of RTP Header .................................9
5. SAToP Payload Layer ............................................10
5.1. General Payloads ..........................................10
5.2. Octet-Aligned T1 ..........................................11
6. SAToP Operation ................................................12
6.1. Common Considerations .....................................12
6.2. IWF Operation .............................................12
6.2.1. PSN-Bound Direction ................................12
6.2.2. CE-Bound Direction .................................13
6.3. SAToP Defects .............................................14
6.4. SAToP PW Performance Monitoring ...........................15
7. Quality of Service (QoS) Issues ................................16
8. Congestion Control .............................................16
9. Security Considerations ........................................18
10. Applicability Statement .......................................18
11. IANA Considerations ...........................................20
12. Acknowledgements ..............................................20
13. Co-Authors ....................................................20
14. Normative References ..........................................21
15. Informative References ........................................22
Appendix A: Old Mode of SAToP Encapsulation over L2TPv3 ...........24
Appendix B: Parameters That MUST Be Agreed upon during the PW
Setup .................................................24
1. Introduction
This document describes a method for encapsulating Time Division
Multiplexing (TDM) bit-streams (T1, E1, T3, E3) as pseudowires over
packet-switching networks (PSN). It addresses only structure-
agnostic transport, i.e., the protocol completely disregards any
structure that may possibly be imposed on these signals, in
particular the structure imposed by standard TDM framing [G.704].
This emulation is referred to as "emulation of unstructured TDM
circuits" in [RFC4197] and suits applications where the PEs have no
need to interpret TDM data or to participate in the TDM signaling.
The SAToP solution presented in this document conforms to the PWE3
architecture described in [RFC3985] and satisfies both the relevant
general requirements put forward in [RFC3916] and specific
requirements for unstructured TDM signals presented in [RFC4197].
As with all PWs, SAToP PWs may be manually configured or set up using
the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control
protocol required for setup and maintenance of SAToP pseudowires and
allocations of code points used for this purpose are described in
separate documents ([TDM-CONTROL] and [RFC4446], respectively).
2. Terminology and Reference Models
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2.1. Terminology
The following acronyms used in this document are defined in [RFC3985]
and [RFC4197]:
ATM Asynchronous Transfer Mode
CE Customer Edge
CES Circuit Emulation Service
NSP Native Service Processing
PE Provider Edge
PDH Plesiochronous Digital Hierarchy
PW Pseudowire
SDH Synchronous Digital Hierarchy
SONET Synchronous Optical Network
TDM Time Division Multiplexing
In addition, the following TDM-specific terms are needed:
o Loss of Signal (LOS) - a condition of the TDM attachment
circuit wherein the incoming signal cannot be detected.
Criteria for entering and leaving the LOS condition can be
found in [G.775].
o Alarm Indication Signal (AIS) - a special bit pattern (e.g., as
described in [G.775]) in the TDM bit stream that indicates
presence of an upstream circuit outage. For E1, T1, and E3
circuits, the AIS pattern is a sequence of binary "1" values of
appropriate duration (the "all ones" pattern), and hence it can
be detected and generated by structure-agnostic means. The T3
AIS pattern requires T3 framing (see [G.704], Section
2.5.3.6.1) and hence can only be handled by a structure-aware
NSP.
We also use the term Interworking Function (IWF) to describe the
functional block that segments and encapsulates TDM into SAToP
packets and that in the reverse direction decapsulates SAToP packets
and reconstitutes TDM.
2.2. Reference Models
The generic models defined in Sections 4.1, 4.2, and 4.4 of [RFC3985]
fully apply to SAToP.
The native service addressed in this document is a special case of
the bit stream payload type defined in Section 3.3.3 of [RFC3985].
The Network Synchronization reference model and deployment scenarios
for emulation of TDM services are described in [RFC4197], Section
4.3.
3. Emulated Services
This specification describes edge-to-edge emulation of the following
TDM services described in [G.702]:
1. E1 (2048 kbit/s)
2. T1 (1544 kbit/s); this service is also known as DS1
3. E3 (34368 kbit/s)
4. T3 (44736 kbit/s); this service is also known as DS3
The protocol used for emulation of these services does not depend on
the method in which attachment circuits are delivered to the PEs.
For example, a T1 attachment circuit is treated in the same way
regardless of whether it is delivered to the PE on copper [G.703],
multiplexed in a T3 circuit [T1.107], mapped into a virtual tributary
of a SONET/SDH circuit [G.707], or carried over an ATM network using
unstructured ATM Circuit Emulation Service (CES) [ATM-CES].
Termination of any specific "carrier layers" used between the PE and
CE is performed by an appropriate NSP.
4. SAToP Encapsulation Layer
4.1. SAToP Packet Format
The basic format of SAToP packets is shown in Figure 1 below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| PSN and PW demultiplexing layer headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
+-- --+
| SAToP Encapsulation Header |
+-- --+
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. Basic SAToP Packet Format
4.2. PSN and PW Demultiplexing Layer Headers
Both UDP and L2TPv3 [RFC3931] can provide the PW demultiplexing
mechanisms for SAToP PWs over an IPv4/IPv6 PSN. The PW label
provides the demultiplexing function for an MPLS PSN as described in
Section 5.4.2 of [RFC3985].
The total size of a SAToP packet for a specific PW MUST NOT exceed
path MTU between the pair of PEs terminating this PW. SAToP
implementations using IPv4 PSN MUST mark the IPv4 datagrams they
generate as "Don’t Fragment" [RFC791] (see also [PWE3-FRAG]).
4.3. SAToP Header
The SAToP header MUST contain the SAToP Control Word (4 bytes) and
MAY also contain a fixed RTP header [RFC3550]. If the RTP header is
included in the SAToP header, it MUST immediately follow the SAToP
control word in all cases except UDP multiplexing, where it MUST
precede it (see Figures 2a, 2b, and 2c below).
Note: Such an arrangement complies with the traditional usage of RTP
for the IPv4/IPv6 PSN with UDP multiplexing while making SAToP PWs
Equal Cost Multi-Path (ECMP)-safe for the MPLS PSN by providing for
PW-IP packet discrimination (see [RFC3985], Section 5.4.3).
Furthermore, it facilitates seamless stitching of L2TPv3-based and
MPLS-based segments of SAToP PWs (see [PWE3-MS]).
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and UDP (PW demultiplexing layer) headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- OPTIONAL --+
| |
+-- Fixed RTP Header (see [RFC3550]) --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SAToP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with
UDP PW Demultiplexing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| IPv4/IPv6 and L2TPv3 (PW demultiplexing layer) headers |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SAToP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- OPTIONAL --+
| |
+-- Fixed RTP Header (see [RFC3550]) --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with
L2TPv3 PW Demultiplexing
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
| MPLS Label Stack |
| ... |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| SAToP Control Word |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| |
+-- OPTIONAL --+
| |
+-- Fixed RTP Header (see [RFC3550]) --+
| |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| ... |
| TDM data (Payload) |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2c. SAToP Packet Format for an MPLS PSN
4.3.1. Usage and Structure of the Control Word
Usage of the SAToP control word allows:
1. Detection of packet loss or misordering
2. Differentiation between the PSN and attachment circuit problems
as causes for the outage of the emulated service
3. PSN bandwidth conservation by not transferring invalid data
(AIS)
4. Signaling of faults detected at the PW egress to the PW
ingress.
The structure of the SAToP Control Word is shown in Figure 3 below.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R|RSV|FRG| LEN | Sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3. Structure of the SAToP Control Word
The use of Bits 0 to 3 is described in [RFC4385]. These bits MUST be
set to zero unless they are being used to indicate the start of an
Associated Channel Header (ACH). An ACH is needed if the state of
the SAToP PW is being monitored using Virtual Circuit Connectivity
Verification [PWE3-VCCV].
L - If set, indicates that TDM data carried in the payload is invalid
due to an attachment circuit fault. When the L bit is set the
payload MAY be omitted in order to conserve bandwidth. The CE-
bound IWF MUST play out an appropriate amount of filler data
regardless of the payload size. Once set, if the fault is
rectified, the L bit MUST be cleared.
Note: This document does not specify which TDM fault conditions are
treated as invalidating the data carried in the SAToP packets.
Possible examples include, but are not limited to LOS and AIS.
R - If set by the PSN-bound IWF, indicates that its local CE-bound
IWF is in the packet loss state, i.e., has lost a preconfigured
number of consecutive packets. The R bit MUST be cleared by the
PSN-bound IWF once its local CE-bound IWF has exited the packet
loss state, i.e., has received a preconfigured number of
consecutive packets.
RSV and FRG (bits 6 to 9) - MUST be set to 0 by the PSN-bound IWF and
MUST be ignored by the CE-bound IWF. RSV is reserved. FRG is
fragmentation; see [PWE3-FRAG].
LEN (bits 10 to 15) - MAY be used to carry the length of the SAToP
packet (defined as the size of the SAToP header + the payload
size) if it is less than 64 bytes, and MUST be set to zero
otherwise. When the LEN field is set to 0, the preconfigured
size of the SAToP packet payload MUST be assumed to be as
described in Section 5.1, and if the actual packet size is
inconsistent with this length, the packet MUST be considered
malformed.
Sequence number - used to provide the common PW sequencing function
as well as detection of lost packets. It MUST be generated in
accordance with the rules defined in Section 5.1 of [RFC3550] for
the RTP sequence number:
o Its space is a 16-bit unsigned circular space
o Its initial value SHOULD be random (unpredictable).
It MUST be incremented with each SAToP data packet sent in the
specific PW.
4.3.2. Usage of RTP Header
When RTP is used, the following fields of the fixed RTP header (see
[RFC3550], Section 5.1) MUST be set to zero: P (padding), X (header
extension), CC (CSRC count), and M (marker).
The PT (payload type) field is used as follows:
1. One PT value MUST be allocated from the range of dynamic values
(see [RTP-TYPES]) for each direction of the PW. The same PT
value MAY be reused for both directions of the PW and also
reused between different PWs.
2. The PSN-bound IWF MUST set the PT field in the RTP header to
the allocated value.