PWE3 Y(J) Stein
Internet-Draft R. Shashoua
Expires: March 25, 2006 R. Insler
M. Anavi
RAD Data Communications
Sept 21, 2005
TDM over IP
draft-ietf-pwe3-tdmoip-04.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on March 25, 2006.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document describes methods for structure-aware transport of TDM
traffic over packet switched networks using pseudowires.
Stein, et al. Expires March 25, 2006 [Page 1]
Internet-Draft TDMoIP Sept 2005
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . 5
3. Encapsulation Details for Specific PSNs . . . . . . . . . . 8
3.1 UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2 MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.4 Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 13
4. TDMoIP Payload types . . . . . . . . . . . . . . . . . . . . 15
4.1 AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 16
4.2 AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 17
4.3 HDLC Format Payload . . . . . . . . . . . . . . . . . . . 18
5. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . 19
6. Implementation Issues . . . . . . . . . . . . . . . . . . . 22
6.1 Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 22
6.2 Timing Recovery . . . . . . . . . . . . . . . . . . . . . 22
6.3 Quality of Service . . . . . . . . . . . . . . . . . . . . 24
7. Security Considerations . . . . . . . . . . . . . . . . . . 24
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24
9. Trademarks . . . . . . . . . . . . . . . . . . . . . . . . . 25
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1 Normative References . . . . . . . . . . . . . . . . . . 26
10.2 Informative References . . . . . . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 29
A. Sequence Number Processing . . . . . . . . . . . . . . . . . 30
B. AAL1 Review . . . . . . . . . . . . . . . . . . . . . . . . 32
C. AAL2 Review . . . . . . . . . . . . . . . . . . . . . . . . 36
D. Performance Monitoring Mechanisms . . . . . . . . . . . . . 38
D.1 TDMoIP Connectivity Verification . . . . . . . . . . . . . 38
D.2 OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39
E. Capabilities, Configuration and Statistics . . . . . . . . . 43
Intellectual Property and Copyright Statements . . . . . . . 46
Stein, et al. Expires March 25, 2006 [Page 2]
Internet-Draft TDMoIP Sept 2005
1. Introduction
Telephony traffic is conventionally carried over connection-oriented
synchronous or plesiochronous links (loosely called TDM circuits
herein). With the proliferation of packet switched networks (PSNs),
integration of TDM services into a unified PSN infrastructure has
become desirable. Such integration requires emulation of TDM
circuits within the PSN, a function that can be carried out using
pseudowires (PWs), as described in the PWE3 architecture [PWE-ARCH].
This emulation must ensure QoS and voice quality similar to those of
existing TDM networks as well as preserving signaling features, as
described in the TDM PW requirements [TDM-REQ].
The interworking function that connects between the TDM and PSN
worlds will be called a TDMoIP gateway (GW), and it may be situated
at the provider edge (PE) or at the customer edge (CE). The TDM
gateway that encapsulates TDM and injects packets into the PSN will
be called the PSN-bound gateway, while the gateway that extracts TDM
data from packets and generates traffic on a TDM network will be
called the TDM-bound gateway. Emulated TDM circuits are always
point-to-point, bidirectional, and transport the same TDM rate in
both directions.
Although TDM circuits can be used to carry arbitrary bit-streams,
there are standardized methods for carrying constant-length blocks of
data called "structures". Familiar structures are the T1 or E1
frames [G.704] of length 193 and 256 bits, respectively. T3 and E3
frames [G.704,G.751] are much larger than those of T1 and E1, and
even larger structures are used in the GSM Abis channel described in
[TRAU]. TDM structures contain TDM data plus structure overhead; for
example, the 193-bit T1 frame contains a single bit of structure
overhead and 24 bytes of data, while the 32-byte E1 frame contains a
byte of overhead and 31 data bytes.
TDM circuits are often used to transport multiplexed 64 kbps
channels. A frame of a channelized T1 carries 24 byte-sized
channels, while an E1 frame consists of 32 channels. By
concatenation of consecutive T1 or E1 frames we can build higher
level structures called superframes or multiframes.
TDM structures are universally delimited by placing an easily
detectable periodic bit pattern, called the Frame Alignment Signal
(FAS), in the structure overhead. The structure overhead may
additionally contain error monitoring and defect indications. We
will use the term "structured TDM" to refer to TDM with any level of
structure imposed by an FAS. Unstructured TDM signifies a bit stream
upon which no structure has been imposed, implying that all bits are
available for user data.
Stein, et al. Expires March 25, 2006 [Page 3]
Internet-Draft TDMoIP Sept 2005
SAToP [SAToP] is a structure-agnostic protocol for transporting TDM
over PWs. SAToP treats the TDM input as an arbitrary bit-stream,
completely disregarding any structure that may exist in the TDM bit-
stream. Hence SAToP is ideal for transport of truly unstructured
TDM, and also suitable for transport of structured TDM when there is
no need to protect structure integrity nor interpret or manipulate
individual channels during transport. In particular, SAToP is the
technique of choice for PSNs with negligible packet loss, and for
applications that do not require discrimination between channels nor
intervention in TDM signaling.
As described in [SAToP], when a SAToP packet is lost an "all ones"
pattern is played out to the TDM interface. Except for the shortest
of packets, this pattern is interpreted by the TDM end equipment as
an AIS indication, which immediately triggers a "severely errored
second" according to the TDM standards [G826]. Since [G826] further
stipulates that the fraction of severely errored must remain under
one fifth of one percent, the suitability of SAToP is limited to
extremely reliable and overprovisioned PSNs.
When structure-aware TDM transport is employed, it is possible to
explicitly safeguard TDM structure during transport over the PSN,
thus making possible to effectively conceal packet loss events.
Structure-aware transport exploits at least some level of the TDM
structure to enhance robustness to packet loss or other PSN
shortcomings. Structure-aware TDM PWs are not required to transport
structure overhead across the PSN; in particular, the FAS MAY be
stripped by the PSN-bound GW and MUST be regenerated by the TDM-bound
GW. However, structure overhead MAY be transported over the PSN,
since it may contain information other than FAS.
In addition to guaranteeing maintenance of TDM synchonization,
structure-aware TDM transport can also distinguish individual
timeslots enabling sophisticated packet loss concealment at the
channel level. TDM signaling also becomes visible, facilitating
mechanisms that maintain or exploit this information. Finally, by
taking advantage of TDM signaling and/or voice activity detection,
structure-aware TDM transport makes bandwidth conservation possible.
There are three conceptually distinct methods of ensuring TDM
structure integrity, namely structure-locking, structure-indication,
and structure-reassembly. Structure-locking requires each packet to
commence at the start of a TDM structure, and to contain an entire
structure or integral multiples thereof. Structure-indication allows
packets to contain arbitrary fragments of basic structures, but
employs pointers to indicate where each structure commences.
Structure-reassembly is only meaningful for channelized TDM; the PSN-
bound GW extracts and buffers the individual channels, and the
Stein, et al. Expires March 25, 2006 [Page 4]
Internet-Draft TDMoIP Sept 2005
original structure is reassembled from the received constituents by
the TDM-bound GW.
All three methods of TDM structure preservation have their
advantages. Structure-locking is described in [CESoPSN], while the
present document specifies both structure-indication (see
Section 4.1) and structure-reassembly (see Section 4.2) approaches.
Structure-indication is used when channels may be allocated
statically, and/or when it is required to interwork with existing
circuit emulation systems (CES) based on AAL1. Structure-reassembly
is used when dynamic allocation of channels is desirable and/or when
it is required to interwork with existing loop emulation systems
(LES) based on AAL2.
Operation, administration, and maintenance (OAM) mechanisms are vital
for proper TDM depolyments. As aforementioned, structure-aware
mechanisms may refrain from transporting structure overhead across
the PSN, disrupting OAM functionality. It is beneficial to
distinguish between two OAM cases, the trail terminated and the trail
extended scenarios. A trail is defined to be the combination of data
and associated OAM information transfer. When the TDM trail is
terminated, OAM information such as error monitoring and defect
indications are not transported over the PSN, and the TDM networks
function as separate OAM domains. In the trail extended case we
transfer the OAM information over the PSN (although not necessarily
in its native format). This will be discussed further in Section 5.
Despite its name, the TDMoIP(R) protocol herein described may operate
over several types of PSN, including UDP over IPv4 or IPv6, MPLS,
L2TPv3 over IP, or pure Ethernet. Implementation specifics for
particular PSNs are discussed in Section 3. Although the protocol
should be more generally called TDMoPW and its specific
implementations TDMoIP, TDMoMPLS, etc. we retain the nomenclature
TDMoIP for consistency with earlier usage.
2. TDMoIP Encapsulation
The overall format of TDMoIP packets is shown in the following
figure.
+---------------------+
| PSN Headers |
+---------------------+
| TDMoIP Control Word |
+---------------------+
| Adapted Payload |
+---------------------+
Stein, et al. Expires March 25, 2006 [Page 5]
Internet-Draft TDMoIP Sept 2005
The PSN-specific headers are those of UDP/IP, L2TPv3/IP, MPLS or
layer 2 Ethernet, and contain all information necessary for
forwarding the packet from the PSN-bound GW to the TDM-bound one.
The PSN is assumed to be reliable enough and of sufficient bandwidth
to enable transport of the required TDM data.
A TDMoIP gateway may simultaneously support multiple TDM PWs, and the
TDMoIP gateway MUST maintain context information for each TDM PW.
Distinct PWs are differentiated based on PW labels, which are carried
in the PSN-specific layers. Since TDM is inherently bidirectional,
the association of two PWs in opposite directions is required. In
general the PW labels of these PWs will take different values.
In addition to the aforementioned headers, an OPTIONAL 12-byte RTP
header may appear in order to enable explicit transfer of timing
information. The RTP timestamp indicates the packet creation time in
units of a common clock available to both communicating TDMoIP GWs.
When no common clock is available, or when the TDMoIP gateways have
sufficiently accurate local clocks or can derive sufficiently
accurate timing without explicit timestamps, the RTP header SHOULD be
omitted. If RTP is used, the fixed RTP header described in [RTP]
MUST immediately follow the control word for all PSN types except
UDP/IP, for which it MUST precede the control word. The version
number MUST be set to 2, the P (padding), X (header extension), CC
(CSRC count), and M (marker) fields in the RTP header MUST be set to
zero, and the PT values MUST be allocated from the range of dynamic
values. The RTP sequence number MUST be identical to the sequence
number in the TDMoIP control word (see below). The RTP timestamp
MUST be generated in accordance with the rules established in [RTP];
the clock frequency MUST be an integer multiple of 8 kHz, and MUST be
chosen to enable timing recovery that conforms with the appropriate
standards (see Section 6.2).
The 32-bit control word MUST appear in every TDMoIP packet. Its
format is depicted in the following figure.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RES The first nibble of the control word MUST be set to zero when the
PSN is MPLS, in order to ensure that the packet does not alias an
IP packet when forwarding devices perform deep packet inspection.
For other PSNs the first nibble SHOULD be set to zero. In earlier
versions of TDMoIP this field contained a format identifier that
was optionally used to specify the payload format.
Stein, et al. Expires March 25, 2006 [Page 6]
Internet-Draft TDMoIP Sept 2005
L Local Failure (1 bit) The L flag is set when the GW has detected or
has been informed of a TDM physical layer fault impacting the TDM
data being forwarded. In the trail extended OAM scenario the L
flag MUST be set when the GW detects loss of signal, loss of frame
synchronization, or AIS. When the L flag is set the contents of
the packet may not be meaningful, and the payload MAY be
suppressed in order to conserve bandwidth. Once set, if the TDM
fault is rectified the L flag MUST be cleared. Use of the L flag
is further explained in Section 5.
R Remote Failure (1 bit) The R flag is set when the GW has detected
or has been informed, that TDM data is not being received from the
remote TDM network, indicating failure of the reverse direction of
the bidirectional connection. A GW SHOULD generate TDM RDI upon
receipt of an R flag indication. In the trail extended OAM
scenario the R flag MUST be set when the GW detects RDI. Use of
the R flag is further explained in Section 5.
Defect Modifier (2 bits) Use of the M field is optional, and when
used supplements the meaning of the L flag.
When L is cleared (indicating valid TDM data) the M field is used
as follows:
0 0 indicates no local defect modification.
0 1 reserved.
1 0 reserved.
1 1 reserved.
When L is set (indicating invalid TDM data) the M field is used as
follows:
0 0 indicates a TDM defect that should trigger conditioning
or AIS generation by the TDM-bound gateway.
0 1 indicates idle TDM data that should not trigger any alarm.
If the payload has been suppressed then the preconfigured
idle code should be generated at egress.
1 0 indicates corrupted but potentially recoverable TDM data.
1 1 reserved.
Use of the M field is further explained in Section 5.
RES (2 bits) These bits are reserved and MUST be set to zero.
Stein, et al. Expires March 25, 2006 [Page 7]
Internet-Draft TDMoIP Sept 2005
Length (6 bits) is used to indicate the length of the TDMoIP packet
(control word and payload), in case padding is employed to meet
minimum transmission unit requirements of the PSN. It MUST be
used if the total packet length (including PSN, optional RTP,
control word, and payload) is less than 64 bytes, and MUST be set
to zero when not used.
Sequence number (16 bits) The TDMoIP sequence number provides the
common PW sequencing function described in [PWE-ARCH], and enables
detection of lost and misordered packets. The sequence number
space is a 16-bit, unsigned circular space; the initial value of
the sequence number SHOULD be random (unpredictable) for security
purposes, and its value is incremented modulo 2^16 separately for
PW. Pseudocode for a sequence number processing algorithm that
could be used by a TDM-bound GW is provided in Appendix A.
In order to form the TDMoIP payload, the PSN-bound GW extracts bytes
from the continuous TDM stream, filling each byte from its most
significant bit. The extracted bytes are then adapted using one of
two adaptation algorithms (see Section 4), and the resulting adapted
payload is placed into the packet.
3. Encapsulation Details for Specific PSNs
TDMoIP PWs may exploit various PSNs, including UDP/IP (both IPv4 and
IPv6), L2TPv3 over IP (with no intervening UDP), MPLS, and layer-2
Ethernet. In the following subsections we depict the packet format
for these cases.
For MPLS PSNs, the format is aligned with those specified in [Y1413]
and [Y.1414].
3.1 UDP/IP
The UDP/IP header as described in [UDP] and [IP] is prefixed to the
TDMoIP data. The TDMoIP packet structure is as follows:
Stein, et al. Expires March 25, 2006 [Page 8]
Internet-Draft TDMoIP Sept 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first five rows are the IP header, the sixth and seventh rows are
the UDP header. Rows 8 through 10 are the optional RTP header. Row
11 is the TDMoIP control word.
IPVER (4 bits) is the IP version number, e.g. for IPv4 IPVER=4.
IHL (4 bits) is the length in 32-bit words of the IP header, IHL=5.
IP TOS (8 bits) is the IP type of service.
Total Length (16 bits) is the length in bytes of header and data.
Identification (16 bits) is the IP fragmentation identification
field.
Stein, et al. Expires March 25, 2006 [Page 9]
Internet-Draft TDMoIP Sept 2005
Flags (3 bits) are the IP control flags and MUST be set to Flags=010
to avoid fragmentation.
Fragment Offset (13 bits) indicates where in the datagram the
fragment belongs and is not used for TDMoIP.
Time to Live (8 bits) is the IP time to live field. Datagrams with
zero in this field are to be discarded.
Protocol (8 bits) MUST be set to 11 hex = 17 dec to signify UDP.
IP Header Checksum (16 bits) is a checksum for the IP header.
Source IP Address (32 bits) is the IP address of the source.
Destination IP Address (32 bits) is the IP address of the
destination.
Source and Destination Port Numbers (16 bits each) The UDP ports MUST
be manually configured, and either field may contain the PW label.
In this fashion the destination IP and one of the UDP ports
together uniquely identify the specific TDM stream being
transported. The choice of whether the source port field or
destination port field is used as TDM stream identifier is
implementation dependent, but the choice MUST be agreed upon by
the communicating two TDMoIP GWs. When used as a TDM stream
identifier, the UDP port number SHOULD be chosen from the range of
dynamically allocated UDP ports numbers (49152 through 65535)
[UDP]. The value 0 is reserved; when using a separate OAM PW (see
Appendix D), a value (default 1FFF hex = 8191 dec) is
preconfigured for the OAM PW. When the source port is used to
identify the TDM stream, the destination port number MUST be set
to 0x085E (2142), the user port number assigned by IANA to TDMoIP.
UDP Length (16 bits) is the length in bytes of UDP header and data.
UDP Checksum (16 bits) is the checksum of UDP/IP header and data. If
not computed it must be set to zero.
3.2 MPLS
ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and
structure-aware mechanisms for transporting TDM over MPLS networks.
Similarly, ITU-T recommendation Y.1414 [Y1413] defines structure-
reassembly mechanisms for this purpose. Although the terminology
used here differs slightly from that of the ITU, implementations of
TDMoIP for MPLS PSNs as described herein will interoperate with
Stein, et al. Expires March 25, 2006 [Page 10]
Internet-Draft TDMoIP Sept 2005
implementations designed to comply with Y.1413 subclause 9.2.2 or
Y.1414 clause 10.
The MPLS header as described in [MPLS] is prefixed to the control
word and TDM payload. The packet structure is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Tunnel Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | EXP |1| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first two rows depicted above are the MPLS header; the third is
the TDMoIP control word. Fields not previously described will now be
explained.
Tunnel Label (20 bits) is the MPLS label that identifies the MPLS LSP
used to tunnel the TDM packets through the MPLS network. The
label can be assigned either by manual provisioning or via an MPLS
control protocol. While transiting the MPLS network there may be
zero, one or several tunnel label rows. For label stack usage see
[MPLS].
EXP (3 bits) experimental field, may be used to carry DiffServ
classification for tunnel labels.
S (1 bit) the stacking bit indicates MPLS stack bottom. S=0 for
all tunnel labels, and S=1 for the PW label.
TTL (8 bits) MPLS Time to live. Should be set to 2 for the PW label.
Stein, et al. Expires March 25, 2006 [Page 11]
Internet-Draft TDMoIP Sept 2005
PW Label (20 bits) This label MUST be a valid MPLS label, and MAY be
configured or signaled. When using a separate OAM PW (see
Appendix D), one PW label (default FFFFF hex = 1048575 dec) MUST
be reserved for the OAM PW.
3.3 L2TPv3
The L2TPv3 header defined in [L2TPv3] is prefixed to the TDMoIP data.
The packet structure is as follows:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPVER | IHL | IP TOS | Total Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identification |Flags| Fragment Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Time to Live | Protocol | IP Header Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID = PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 1 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rows 6 through 8 are the L2TPv3 header. Fields not previously
described will now be explained.
Stein, et al. Expires March 25, 2006 [Page 12]
Internet-Draft TDMoIP Sept 2005
Protocol the IP protocol field must be set to 73 hex = 115 dec, the
user port number that has been assigned to L2TP by IANA.
Session ID (32 bits) is the locally significant L2TP session
identifier, and contains the PW label. The value 0 is reserved;
When using a separate OAM PW (see Appendix D), one PW label
(default FFFFFFFF hex) MUST be reserved for the OAM PW.
Cookie (32 or 64 bits) is an optional field that contains a randomly
selected value that can be used to validate association of the
received frame with the expected PW.
3.4 Ethernet
The TDMoIP packet described in the previous subsections will
frequently be further encapsulated in an Ethernet frame by prefixing
the Ethernet preamble, destination and source MAC addresses, optional
VLAN header, and Ethertype, and suffixing the four-byte frame check
sequence. TDMoIP implementations MUST be able to receive both
industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames
and SHOULD transmit Ethernet frames.
Ethernet encapsulation introduces restrictions on both minimum and
maximum packet size. Whenever the entire TDMoIP packet is less than
64 bytes, padding is introduced and the true length indicated by
using the Length field in the control word. In order to avoid
fragmentation the TDMoIP packet MUST be restricted to the maximum
payload size. For example, the length of the Ethernet payload for a
UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet
is 1472 bytes, which falls below the maximal permitted payload size
of 1500 bytes.
Ethernet frames may be used for TDMoIP transport without intervening
IP or MPLS layers, however, an MPLS-style label MUST always be
present. In this four-byte header S=1, and all other non-label bits
are reserved (set to zero in the PSN-bound direction and ignored in
the TDM-bound direction). The Ethertype SHOULD be set to 0x88D8
(35032), the value allocated for CESoETH by the IEEE, but MAY be set
to 0x8847 (34887), the Ethertype of MPLS. The packet structure is as
follows:
Stein, et al. Expires March 25, 2006 [Page 13]
Internet-Draft TDMoIP Sept 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Destination MAC Address (cont) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source MAC Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source MAC Address (cont) | VLAN Ethertype (opt) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|VLP|C| VLAN ID (opt) | Ethertype |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PW label | RES |1| RES |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES |L|R| M |RES| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
opt| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Adapted Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Frame Check Sequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may
be additional fields, depending on the value of the length field, see
[IEEE802.3]. Fields not previously described will now be explained.
Destination MAC Address (48 bits) is the globally unique address of a
single station that is to receive the packet. The format is
defined in [IEEE802.3].
Source MAC Address (48 bits) is the globally unique address of the
station that originated the packet. The format is defined in
[IEEE802.3].
VLAN Ethertype (16 bits) a 8100 hex in this position indicates that
optional VLAN tagging according to [IEEE802.1Q] is employed, and
that the next two bytes contain the VLP, C and VLAN ID fields.
VLAN tags may be stacked, in which case the two-byte field
following the VLAN ID is once again a VLAN Ethertype.
Stein, et al. Expires March 25, 2006 [Page 14]
Internet-Draft TDMoIP Sept 2005
VLP (3 bits) is the VLAN priority, see [IEEE802.1Q].
C (1 bit) the "canonical format indicator" being set, indicates that
route descriptors appear; see [IEEE802.1Q].
VLAN ID (12 bits) the VLAN identifier uniquely identifies the VLAN to
which the frame belongs. If zero only the VLP information is
meaningful. Values 1 and FFF are reserved. The other 4193 values
are valid VLAN identifiers.
Ethertype (16 bits) is the protocol identifier, as allocated by the
IEEE.
PW Label (20 bits) This label MUST be manually configured. When
using a separate OAM PW (see Appendix D), one PW label (default
FFFFF hex = 1048575 dec) MUST be reserved for the OAM PW. The
remainder of this row is formatted to resemble an MPLS label.
Frame Check Sequence (32 bits) is a CRC error detection field,
calculated per [IEEE802.3].
4. TDMoIP Payload types
As discussed at the end of Section 2, TDMoIP transports real-time
streams by first extracting bytes from the stream, and then adapting
these bytes. TDMoIP offers two different adaptation algorithms, one
for constant rate real-time traffic, and one for variable rate real-
time traffic.
Since native TDM is always constant bit-rate, why is a variable rate
adaptation needed? For unstructured TDM, or structured but
unchannelized TDM, of structured channelized TDM with all channels
active all the time, there is indeed no need. In such cases TDMoIP
uses structure-indication to emulate the native TDM circuit,
utilizing an adaptation known as circuit emulation. However,
individual "local loops" are frequently "on-hook" and thus inactive,
and bandwidth may be conserved by transporting only channels
corresponding to active loops. This results in variable rate real-
time traffic, for which TDMoIP uses structure-reassembly to emulate
the individual loops, utilizing an adaptation known as loop
emulation.
TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation,
while variable-rate AAL2 [AAL2] is employed for loop emulation. The
AAL1 mode MUST be used for structured transport of unchannelized data
and SHOULD be used for circuits with relatively constant usage. In
addition, AAL1 MUST be used when the TDM-bound GW is required to
Stein, et al. Expires March 25, 2006 [Page 15]
Internet-Draft TDMoIP Sept 2005
maintain a high timing accuracy (e.g. when its timing is further
distributed) and SHOULD be used when high reliability is required.
AAL2 SHOULD be used for channelized TDM when bandwidth needs to be
conserved, and MAY be used whenever usage of voice-carrying channels
is expected to be highly variable.
Additionally, a third mode is defined specifically for efficient
transport of HDLC-based CCS signaling carried in TDM channels.
The AAL family of protocols is a natural choice for TDM emulation.
Although originally developed to adapt various types of application
data to the rigid format of ATM, the mechanisms are general solutions
to the problem of transporting constant or variable rate real-time
streams over a packet network.
Since the AAL mechanisms are extensively deployed within and on the
edge of the public telephony system, they have been demonstrated to
reliably transfer voice-grade channels, data and telephony signaling.
These mechanisms are mature and well understood, and implementations
are readily available.
Finally, simplified service interworking with legacy networks is a
major design goal of TDMoIP. Re-use of AAL technologies simplifies
interworking with existing AAL1- and AAL2-based networks.
4.1 AAL1 Format Payload
For the prevalent cases of unchannelized TDM, or channelized TDM for
which the channel allocation is static, the payload can be
efficiently encoded using constant rate AAL1 adaptation. The AAL1
format is described in [AAL1] and its use for circuit emulation over
ATM in [CES]. We briefly review highlights of AAL1 technology in
Appendix B. In this section we describe the use of AAL1 in the
context of TDMoIP.
+-------------+----------------+
|control word | AAL1 PDU |
+-------------+----------------+
Single AAL1 PDU per TDMoIP packet
+-------------+----------------+ +----------------+
|control word | AAL1 PDU |---| AAL1 PDU |
+-------------+----------------+ +----------------+
Multiple AAL1 PDUs per TDMoIP packet
Stein, et al. Expires March 25, 2006 [Page 16]
Internet-Draft TDMoIP Sept 2005
In AAL1 mode the TDMoIP payload consists of at least one, and perhaps
many, 48-byte "AAL1 PDUs". The number of PDUs must be pre-configured
and must be chosen such that the overall packet size does not exceed
the maximum allowed by the PSN (e.g. 30 for UDP/IP over Ethernet).
The precise number of PDUs per packet is typically chosen taking
latency and bandwidth constraints into account. Using a single PDU
delivers minimal latency, but incurs the highest overhead. All
TDMoIP implementations MUST support between 1 and 8 PDUs per packet
for E1 and T1 circuits, and between 5 and 15 PDUs per packet for E3
and T3 circuits.
AAL1 differentiates between unstructured and structured data
transfer, which correspond to structure-agnostic and structure-aware
transport. For structure-agnostic transport, AAL1 provides no
inherent advantage as compared to SAToP; however, there may be
scenarios for which its use is desirable. For example, when it is
necessary to interwork with an existing AAL1 ATM circuit emulation
system, or when clock recovery based on AAL1-specific mechanisms is
favored.
For structure-aware transport, [CES] defines two modes, structured
and structured with CAS. Structured AAL1 maintains TDM frame
synchronization by embedding a pointer to the beginning of the next
frame in the AAL1 PDU header. Similarly, structured AAL1 with CAS
maintains TDM frame and multiframe synchronization by embedding a
pointer to the beginning of the next multiframe. Furthermore,
structured AAL1 with CAS contains a substructure including the CAS
signaling bits.
4.2 AAL2 Format Payload
Although AAL1 may be configured to transport fractional E1 or T1
circuits, the allocation of channels to be transported must be static
due to the fact that AAL1 transports constant rate bit-streams. It
is often the case that not all the channels in a TDM circuit are
simultaneously active ("off-hook"), and by observation of the TDM
signaling channel activity status may be determined. Moreover, even
during active calls about half the time is silence that can be
identified using voice activity detection (VAD). Using the variable
rate AAL2 mode we may dynamically allocate channels to be
transported, thus conserving bandwidth.
The AAL2 format is described in [AAL2] and its use for loop emulation
over ATM is explained in [SSCS,LES]. We briefly review highlights of
AAL2 technology in Appendix C. In this section we describe the use
of AAL2 in the context of TDMoIP.
Stein, et al. Expires March 25, 2006 [Page 17]
Internet-Draft TDMoIP Sept 2005
+-------------+----------------+ +----------------+
|control word | AAL2 PDU |---| AAL2 PDU |
+-------------+----------------+ +----------------+
Concatenation of AAL2 PDUs in a TDMoIP packet
In AAL2 mode the TDMoIP payload consists of one or more variable-
length "AAL2 PDUs". Each AAL2 PDU contains 3 bytes of overhead and
between 1 and 64 bytes of payload. A packet may be constructed by
inserting PDUs corresponding to all active channels, by appending
PDUs ready at a certain time, or by any other means. Hence, more
than one PDU belonging to a single channel may appear in a packet.
[PWE-ARCH] denotes as Native Service Processing (NSP) functions all
processing of the TDM data before its use as payload. Since AAL2 is
inherently variable rate, arbitrary NSP functions MAY be performed
before the channel is placed in the AAL2 loop emulation payload.
These include testing for on-hook/off-hook status, voice activity
detection, speech compression, fax/modem/tone relay, etc.
All mechanisms described in [AAL2,SSCS,LES] may be used for TDMoIP.
In particular, CID encoding and use of PAD octets according to
[AAL2], encoding formats defined in [SSCS], and transport of CAS and
CCS signaling as described in [LES] MAY all be used in the PSN-bound
direction, and MUST be supported in the TDM-bound direction. The
overlap functionality and AAL-CU timer and related functionalities
may not be required, and the STF field is NOT used. Computation of
error detection codes, namely the HEC in the AAL2 PDU header and the
CRC in the CAS packet, is superfluous if an appropriate error
detection mechanism is provided by the PSN. In such cases these
fields MAY be set to zero.
4.3 HDLC Format Payload
The motivation for handling HDLC in TDMoIP is to efficiently
transport common channel signaling (CCS) such as SS7 [SS7] or ISDN
PRI signaling [ISDN-PRI], embedded in the TDM stream. This mechanism
is not intended for general HDLC payloads, and assumes that the HDLC
messages are always shorter than the maximum packet size.
The HDLC mode should only be used when the majority of the bandwidth
of the input HDLC stream is expected to be occupied by idle flags.
Otherwise the CCS channel should be treated as an ordinary channel.
The HDLC format is intended to operate in port mode, transparently
passing all HDLC data and control messages over a separate PW.
Stein, et al. Expires March 25, 2006 [Page 18]
Internet-Draft TDMoIP Sept 2005
The PSN-bound GW monitors flags until a frame is detected. The
contents of the frame are collected and the FCS tested. If the FCS
is incorrect the frame is discarded, otherwise the frame is sent
after initial or final flags and FCS have been discarded and zero
removal has been performed. When an TDMoIP- HDLC frame is received
its FCS is recalculated, and the original HDLC frame reconstituted.
5. TDMoIP Defect Handling
Native TDM networks signify network faults by carrying indications of
forward defects (AIS) and reverse defects (RDI) in the TDM bit
stream. Structure-agnostic TDM transport transparently carries all
such indications; however, for structure-aware mechanisms where the
PSN-bound GW may remove TDM structure overhead carrying defect
indications, explicit signaling of TDM defect conditions is required.
We saw in Section 2 that defects can be indicated by setting flags in
the control word. This insertion of defect reporting into the packet
rather than in a separate stream mimics the behavior of native TDM
OAM mechanisms that carry such indications as bit patterns embedded
in the TDM stream. The flags are designed to address the urgent
messaging, i.e. messages whose contents must not be significantly
delayed with respect to the TDM data that they potentially impact.
Mechanisms for slow OAM messaging are discussed in Appendix D.
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
|TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM|
| | |TDM 1| | | | PSN | | | |TDM 2| | |
|ES1|-<-| |-<-| GW1 |-<-| |-<-| GW2 |-<-| |-<-|ES2|
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
Typical TDMoIP network configuration
The operation of TDMoIP defect handling is best understood by
considering the downstream TDM flow from TDM end system 1 (ES1)
through TDM network 1, through TDMoIP gateway 1 (GW1), through the
PSN, through TDMoIP gateway 2 (GW2), through TDM network 2, towards
TDM end system 2 (ES2), as depicted in the figure. We wish not only
to detect defects in TDM network 1, the PSN, and TDM network 2, but
to localize such defects in order to raise alarms only in the
appropriate network.
In the trail terminated OAM scenario, only user data is exchanged
between TDM network 1 and TDM network 2. The GW functions as a TDM
trail termination function, and defects detected in TDM network 1 are
not relayed to network 2, or vice versa.
Stein, et al. Expires March 25, 2006 [Page 19]
Internet-Draft TDMoIP Sept 2005
In the trail extended OAM scenario, if there is a defect (e.g. loss
of signal or loss of frame synchronization) anywhere in TDM network 1
before the ultimate link, the following TDM node will generate AIS
downstream (towards TDMoIP GW1). If a break occurs in the ultimate
link, the GW itself will detect the loss of signal. In either case,
GW1 having directly detected lack of validity of the TDM signal, or
having been informed of an earlier problem, raises the local ("L")
defect flag in the control word of the packets it sends across the
PSN. In this way the trail is extended to TDM network 2 across the
PSN.
Unlike forward defect indications that are generated by all network
elements, reverse defect indications are only generated by trail
termination functions. In the trail terminated scenario, GW1 serves
as a trail termination function for TDM network 1, and thus when GW1
directly detects lack of validity of the TDM signal, or is informed
of an earlier problem, it MAY generate TDM RDI towards TDM ES1. In
the trail extended scenario GW1 is not a trail termination, and hence
MUST NOT generate TDM RDI, but rather, as we have seen, sets the "L"
defect flag. As we shall see, this will cause the AIS indication to
reach ES2, which is the trail termination, and which MAY generate TDM
RDI.
When the "L" flag is set there are four possibilities for treatment
of payload content. The default is for GW1 to fill the payload with
the appropriate amount of AIS (usually all-ones) data. If the AIS
has been generated before the GW this can be accomplished by copying
the received TDM data; if the penultimate TDM link fails and the GW
needs to generate the AIS itself. Alternatively, with structure-
aware transport of channelized TDM one SHOULD fill the payload with
"trunk conditioning"; this involves placing a preconfigured "out of
service" code in each individual channel (the "out of service" code
may differ between voice and data channels). Trunk conditioning MUST
be used when channels taken from several TDM PWs are combined by the
TDM-bound GW into a single TDM circuit. The third possibility is to
suppress the payload altogether. Finally, if GW1 believes that the
TDM defect is minor or correctable (e.g. loss of multiframe
synchronization, or initial phases of detection of incorrect frame
sync), it MAY place the TDM data it has received into the payload
field, and specify in the defect modification field ("M") that the
TDM data is corrupted, but potentially recoverable.
When GW2 receives a local defect indication without "M"-field
modification, it forwards (or generates if the payload has been
suppressed) AIS or trunk conditioning towards ES2 (the choice between
AIS and conditioning being preconfigured). Thus AIS has been
properly delivered to ES2 emulating the TDM scenario from the TDM end
system's point of view. In addition, GW2 receiving the "L"
Stein, et al. Expires March 25, 2006 [Page 20]
Internet-Draft TDMoIP Sept 2005
indication uniquely specifies that the defect was in TDM network 1
and not in TDM network 2, thus suppressing alarms in the correctly
functioning network.
If the M field indicates that the TDM has been marked as potentially
recoverable, then implementation specific algorithms (not herein
specified) may optionally be utilized to minimize the impact of
transient defects on the overall network performance. If the "M"
field indicates that the TDM is "idle", no alarms should be raised
and GW2 treats the payload contents as regular TDM data. If the
payload has been suppressed, trunk conditioning and not AIS MUST be
generated by GW2.
The second case is when the defect is in TDM network 2. Such defects
cause AIS generation towards ES2, which may respond by sending TDM
RDI in the reverse direction. In the trail terminated scenario this
RDI is restricted to network 2. In the trail extended scenario, GW2
upon observing this RDI inserted into valid TDM data, MUST indicate
this by setting the "R" flag in packets sent back across the PSN
towards GW1. GW1, upon receiving this indication, generates RDI
towards ES1, thus emulating a single conventional TDM network.
The final possibility is that of a unidirectional defect in the PSN.
In such a case TDMoIP GW1 sends packets toward GW2, but these are not
received. GW2 MUST inform the PSN's management system of this
problem, and furthermore generate TDM AIS towards ES2. ES2 may
respond with TDM RDI, and as before, in the trail extended scenario,
when GW2 detects RDI it MUST raise the "R" flag indication. When GW1
receives packets with the "R" flag set it has been informed of a
reverse defect, and MUST generate TDM RDI towards ES1.
In all cases, if any of the above defects persist for a preconfigured
period (default value of 2.5 seconds) a service failure is declared.
Since TDM PWs are inherently bidirectional, a persistent defect in
either directional results in a bidirectional service failure. In
addition, if signaling is sent over a distinct PW as per Section 4.3,
both PWs are considered to have failed when persistent defects are
detected in either.
When failure is declared the PW MUST be withdrawn, and both TDMoIP
GWs commence sending AIS (and not trunk conditioning) to their
respective TDM networks. The GWs then engage in connectivity testing
using VCCV or TDMoIP OAM as described in Appendix D until
connectivity is restored.
Stein, et al. Expires March 25, 2006 [Page 21]
Internet-Draft TDMoIP Sept 2005
6. Implementation Issues
General requirements for transport of TDM over pseudo-wires are
detailed in [TDM-REQ]. In the following subsections we review
additional aspects essential to successful TDMoIP implementation.
6.1 Jitter and Packet Loss
In order to compensate for packet delay variation that exists in any
PSN, a jitter buffer MUST be provided. A jitter buffer is a block of
memory into which the data from the PSN is written at its variable
arrival rate, and data is read out and sent to the destination TDM
equipment at a constant rate. Use of a jitter buffer partially hides
the fact that a PSN has been traversed rather than a conventional
synchronous TDM network, except for the additional latency.
Customary practice is to operate with the jitter buffer approximately
half full, thus minimizing the probability of its overflow or
underflow. Hence the additional delay equals half the jitter buffer
size. The length of the jitter buffer SHOULD be configurable and MAY
be dynamic (i.e. grow and shrink in length according to the
statistics of the PDV).
In order to handle (infrequent) packet loss and misordering a packet
sequence integrity mechanism MUST be provided. This mechanism MUST
track the serial numbers of packets in the jitter buffer and MUST
take appropriate action when anomalies are detected. When missing
packet(s) are detected the mechanism MUST output filler packet(s) in
order to retain TDM timing. Packets with incorrect serial numbers or
other detectable header errors MUST be discarded. Packets arriving
in incorrect order SHOULD be swapped. Processing of filler packets
SHOULD ensure that proper FAS is sent to the TDM network. An example
sequence number processing algorithm is provided in Appendix A.
While the insertion of arbitrary filler packets may be sufficient to
maintain the TDM timing, for voice traffic it may lead to gaps or
artifacts that result in choppy, annoying or even unintelligible
speech. An implementation MAY blindly insert a preconfigured
constant value in place of any lost speech samples, and this value
SHOULD be chosen to minimize the perceptual effect. Alternatively
one MAY replay the previously received packet. Since a TDMoIP packet
is usually declared lost following the reception of the next packet,
when computational resources are available, implementations SHOULD
conceal the packet loss event by properly estimating the missing
speech sample values in such fashion as to minimize perceptual error.
6.2 Timing Recovery
TDM networks are inherently synchronous; somewhere in the network
Stein, et al. Expires March 25, 2006 [Page 22]
Internet-Draft TDMoIP Sept 2005
there will always be at least one extremely accurate primary
reference clock, with long-term accuracy of one part in 10E-11. This
node provides reference timing to secondary nodes with somewhat lower
accuracy, and these in turn distribute timing information further.
This hierarchy of time synchronization is essential for the proper
functioning of the network as a whole; for details see [G823,G824].
Packets in PSNs reach their destination with delay that has a random
component, known as packet delay variation (PDV). When emulating TDM
on a PSN, extracting data from the jitter buffer at a constant rate
overcomes much of the high frequency component of this randomness
("jitter"). The rate at which we extract data from the jitter buffer
is determined by the destination clock, and were this to be precisely
matched to the source clock proper timing would be maintained.
Unfortunately the source clock information is not disseminated
through a PSN, and the destination clock frequency will only
nominally equal the source clock frequency, leading to low frequency
("wander") timing inaccuracies.
In broadest terms there are three methods of overcoming this
difficulty. In the first method timing information is provided by
some means independent of the PSN. This timing may be provided to
the TDM end system or to the GWs. In a second method a common clock
is assumed available to both gateways, and the relationship between
the TDM source clock and this clock is encoded in the packet. This
encoding may be take the form of RTP timestamps or may utilizing the
SRTS bits in the AAL1 overhead. In the final method (adaptive clock
recovery) the timing must be deduced solely based on the packet
arrival times. Example scenarios are detailed in [TDM-REQ] and in
[Y1413].
Adaptive clock recovery utilizes only observable characteristics of
the packets arriving from the PSN, such as the precise time of
arrival of the packet at the TDM-bound GW, or the fill-level of the
jitter buffer as a function of time. Due to the packet delay
variation in the PSN, filtering processes that combat the statistical
nature of the observable characteristics must be employed. Frequency
Locked Loops (FLL) and Phase Locked Loops (PLL) are well suited for
this task.
Whatever timing recovery mechanism is employed, the output of the
TDM-bound GW MUST conform to the jitter and wander specifications of
TDM traffic interfaces, as defined in [G823,G824]. For some
applications, more stringent jitter and wander tolerances MAY be
required.
Stein, et al. Expires March 25, 2006 [Page 23]
Internet-Draft TDMoIP Sept 2005
6.3 Quality of Service
TDMoIP does not provide mechanisms to ensure timely delivery or
provide other quality-of-service guarantees; hence it is required
that the lower-layer services do so. Layer 2 priority can be
bestowed upon a TDMoIP stream by using the VLAN priority field, MPLS
priority can be provided by using EXP bits, and layer 3 priority is
controllable by using TOS. Switches and routers which the TDMoIP
stream must traverse should be configured to respect these
priorities.
If the PSN is Diffserv-enabled then an EF-PHB (expedited forwarding)
class based PDB SHOULD be used, in order to provide a low latency and
minimal jitter service. It is suggested that the transport LSP be
somewhat overprovisioned.
If the PSN is Intserv enabled, then GS (Guaranteed Service) with the
appropriate bandwidth reservation SHOULD be used in order to provide
a bandwidth BW guarantee equal or greater than that of the aggregate
TDM traffic. The delay introduced by the PSN SHOULD be measured
prior to traffic flow, to ensure its compliance with latency
requirements.
7. Security Considerations
TDMoIP does not enhance or detract from the security performance of
the underlying PSN, rather it relies upon the PSN's mechanisms for
encryption, integrity, and authentication whenever required. The
level of security provided may be less than that of a native TDM
service.
TDMoIP does not provide protection against malicious users utilizing
snooping or packet injection during setup or operation. However,
random initialization of sequence numbers makes known-plaintext
attacks on link encryption methods more difficult.
PW labels SHOULD be selected in an unpredictable manner rather than
sequentially or otherwise in order to deter session hijacking. When
using L2TPv3, randomly selected cookies MAY be used to validate
circuit origin. Sequence numbers SHOULD be randomly initialized in
order to increase the difficulty of decrypting based on packet
headers.
8. IANA Considerations
When used with UDP/IP the destination port number MUST be set to
0x085E (2142), the user port number which has been assigned by IANA
to TDMoIP.
Stein, et al. Expires March 25, 2006 [Page 24]
Internet-Draft TDMoIP Sept 2005
When inband TDMoIP OAM is used (see Appendix D.2), a value will need
to be allocated by IANA from the PW Associated Channel Type registry
for inband TDMoIP OAM.
9. Trademarks
TDMoIP is a registered trademark of RAD Data Communications. RAD
Data Communications grants the IETF a perpetual license to reproduce
this trademark solely in connection with the reproduction,
distribution or publication of this contribution and derivative works
thereof, in accordance with RFC 3667.
Stein, et al. Expires March 25, 2006 [Page 25]
Internet-Draft TDMoIP Sept 2005
10. References
10.1 Normative References
[AAL1] ITU-T Recommendation I.363.1 (08/96) B-ISDN ATM Adaptation
Layer (AAL) specification: Type 1
[AAL2] ITU-T Recommendation I.363.2 (11/00) B-ISDN ATM Adaptation
Layer (AAL) specification: Type 2
[CES] ATM forum specification atm-vtoa-0078 (CES 2.0) Circuit
Emulation Service Interoperability Specification Ver. 2.0
[G704] ITU-T Recommendation G.704 (10/98) Synchronous frame
structures used at 1544, 6312, 2048, 8448 and 44736 kbit/s
hierarchical levels
[G751] ITU-T Recommendation G.751 (11/88) Digital multiplex
equipments operating at the third order bit rate of 34368 kbit/s
and the fourth order bit rate of 139264 kbit/s and using positive
justification
[G823] ITU-T Recommendation G.823 (03/00) The control of jitter and
wander within digital networks which are based on the 2048 Kbit/s
hierarchy
[G824] ITU-T Recommendation G.824 (03/00) The control of jitter and
wander within digital networks which are based on the 1544 Kbit/s
hierarchy
[G826] ITU-T Recommendation G.826 (13/02) End-to-end error
performance parameters and objectives for international, constant
bit-rate digital paths and connections
[IEEE802.1Q] IEEE 802.1Q, IEEE Standards for Local and Metropolitan
Area Networks -- Virtual Bridged Local Area Networks (2003)
[IEEE802.3] IEEE 802.3, IEEE Standard Local and Metropolitan Area
Networks - Carrier Sense Multiple Access with Collision Detection
(CSMA/CD) Access Method and Physical Layer Specifications (2002)
[IPv4] RFC 791 (STD0005) Internet Protocol (IP)
[LES] ATM forum specification atm-vmoa-0145 (LES) Voice and
Multimedia over ATM - Loop Emulation Service Using AAL2
Stein, et al. Expires March 25, 2006 [Page 26]
Internet-Draft TDMoIP Sept 2005
[L2TPv3] RFC 3931 Layer Two Tunneling Protocol - Version 3 (L2TPv3)
[MPLS] RFC 3032 MPLS Label Stack encoding
[RTP] RFC 3550 RTP: Transport Protocol for Real-Time Applications
[SAToP] draft-ietf-pwe3-satop-03.txt (09/05) Structure-Agnostic TDM
over Packet (SAToP), A. Vainshtein and Y. Stein, work in progress
[SSCS] ITU-T Recommendation I.366.2 (11/00) AAL type 2 service
specific convergence sublayer for narrow-band services
[UDP] RFC 768 (STD0006) User Datagram Protocol (UDP)
[VCCV] draft-ietf-pwe3-vccv-06.txt (08/05) Pseudo Wire Virtual
Circuit Connectivity Verification, T. Nadeau and R. Aggarwal, work
in progress
[Y1413] ITU-T Recommendation Y.1413 (03/04) TDM-MPLS network
interworking - User plane interworking
[Y1414] ITU-T Recommendation Y.1414 (07/04) Voice services - MPLS
network interworking
10.2 Informative References
[CESoPSN] draft-ietf-cesopsn-03.txt (07/05), TDM Circuit Emulation
Service over Packet Switched Network, A. Vainshtein et al, work in
progress
[CONNECT] RFC 2678 IPPM Metrics for Measuring Connectivity
[DELAY] RFC 2679 A One-way Delay Metric for IPPM
[ICMP] RFC 792 Internet Control Message Protocol. (09/81)
[IPPM] RFC 2330 Framework for IP Performance Metrics
[ISDN-PRI] ITU-T Recommendation Q.931 (05/98) ISDN user-network
interface layer 3 specification for basic call control
[LSP-PING] draft-ietf-mpls-lsp-ping-09.txt (05/05), Detecting MPLS
Data Plane Failures, K. Kompella and G. Swallow, work in progress
Stein, et al. Expires March 25, 2006 [Page 27]
Internet-Draft TDMoIP Sept 2005
[PWECW] draft-ietf-pwe3-cw-05.txt (07/05), PWE3 Control Word for use
over an MPLS PSN, Stewart Bryant et al, work in progress
[PWE3-ARCH] RFC 3985 Pseudo Wire Emulation Edge-to-Edge (PWE3)
Architecture
[SS7] ITU-T Recommendation Q.700 (03/93) Introduction to CCITT
Signalling System No. 7
[TDM-REQ] draft-ietf-pwe3-tdm-requirements-08.txt (04/05),
Requirements for Edge-to-Edge Emulation of TDM Circuits over
Packet Switching Networks, M. Riegel, work in progress
[TRAU] GSM 08.60 (10/01) Digital cellular telecommunications system
(Phase 2+); Inband control of remote transcoders and rate adaptors
for Enhanced Full Rate (EFR) and full rate traffic channels
11. Acknowledgments
The authors would like to thank Hugo Silberman, Shimon HaLevy, Tuvia
Segal, and Eitan Schwartz of RAD Data Communications for their
valuable contributions to the technology described herein.
Stein, et al. Expires March 25, 2006 [Page 28]
Internet-Draft TDMoIP Sept 2005
Authors' Addresses
Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5389
Email: yaakov_s@rad.com
Ronen Shashoua
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5447
Email: ronen_s@rad.com
Ron Insler
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719
ISRAEL
Phone: +972 3 645-5445
Email: ron_i@rad.com
Motty (Mordechai) Anavi
RAD Data Communications
900 Corporate Drive
Mahwah, NJ 07430
USA
Phone: +1 201 529-1100 Ext. 213
Email: motty@radusa.com
Stein, et al. Expires March 25, 2006 [Page 29]
Internet-Draft TDMoIP Sept 2005
Appendix A. Sequence Number Processing
The sequence number field in the control word enables detection of
lost and misordered packets. Here we give pseudocode for an example
algorithm in order to clarify the issues involved. These issues are
implementation specific and no single explanation can capture all the
possibilities.
In order to simplify the description modulo arithmetic is
consistently used in lieu of ad-hoc treatment of the cyclicity. All
differences between indexes are explicitly converted to the range
[-2^15 ... +2^15 - 1] to ensure that simple checking of the
difference's sign correctly predicts the packet arrival order.
Furthermore, we introduce the notion of a playout buffer in order to
unambiguously define packet lateness. When a packet arrives after
having previously having been assumed lost, the TDM-bound GW may
discard it, and continue to treat it as lost. Alternatively if the
filler data that had been inserted in its place has not yet been
played out, the option remains to insert the true data into the
playout buffer. Of course, the filler data may be generated upon
initial detection of a missing packet or upon playout. This
description is stated in terms of a packet-oriented playout buffer
rather than a TDM byte oriented one; however this is not a true
requirement for re-ordering implementations since the latter could be
used along with pointers to packet commencement points.
Having introduced the playout buffer we explicitly treat over-run and
under-run of this buffer. Over-run occurs when packets arrive so
quickly that they can not be stored for playout. This is usually an
indication of gross timing inaccuracy or misconfiguration, and we can
do little but discard such early packets. Under-run is usually a
sign of network starvation, resulting from congestion or network
failure.
The external variables used by the pseudocode are:
received: sequence number of packet received
played: sequence number of the packet being played out (Note 1)
over-run: is the playout buffer full? (Note 3)
under-run: has the playout buffer been exhausted? (Note 3)
The internal variables used by the pseudocode are:
expected: sequence number we expect to receive next
D: difference between expected and received (Note 2)
L: difference between sequence numbers of packet being played out
and that just received (Notes 1 and 2)
Stein, et al. Expires March 25, 2006 [Page 30]
Internet-Draft TDMoIP Sept 2005
In addition, the algorithm requires one parameter:
R: maximum lateness of packet recoverable (Note 1).
Note 1: this is only required for the optional re-ordering
Note 2: this number is always in the range -2^15 ... +2^15 - 1
Note 3: the playout buffer is emptied by the TDM playout process,
which runs asynchronously to the packet arrival processing,
and which is not herein specified
Sequence Number Processing Algorithm
Upon receipt of a packet
if received = expected
{ treat packet as in-order }
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else
calculate D = ( (expected-received) mod 2^16 ) - 2^15
if D > 0 then
{ packets expected, expected+1, ... received-1 are lost }
while not over-run
place filler (all-ones or interpolation) into playout buffer
if not over-run then
place packet contents into playout buffer
else
discard packet contents
set expected = (received + 1) mod 2^16
else { late packet arrived }
declare "received" to be a late packet
do NOT update "expected"
either
discard packet
or
if not under-run then
calculate L = ( (played-received) mod 2^16 ) - 2^15
if 0 < L <= R then
replace data from packet previously marked as lost
else
discard packet
Note: by choosing R=0 we always discard the late packet
Stein, et al. Expires March 25, 2006 [Page 31]
Internet-Draft TDMoIP Sept 2005
Appendix B. AAL1 Review
The first byte of the 48-byte AAL1 PDU always contains an error-
protected three-bit sequence number.
1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P| 47 bytes of payload
+-+-+-+-+-+-+-+-+-----------------------
C (1 bit) convergence sublayer indication, its use here is limited
to indication of the existence of a pointer (see below); C=0 means
no pointer, C=1 means a pointer is present.
SN (3 bits) The AAL1 sequence number increments from PDU to PDU.
CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN.
P (1 bit) even byte parity.
As can be readily inferred this byte can only take on eight different
values, and incrementing the sequence number forms an eight PDU
sequence number cycle, the importance of which will become clear
shortly.
The structure of the remaining 47 bytes in the AAL1 PDU depends on
the PDU type, of which there are three, corresponding to the three
types of AAL1 circuit emulation service defined in [CES]. These are
known as namely unstructured circuit emulation, structured circuit
emulation and structured circuit emulation with CAS.
The simplest PDU is the unstructured one, which is used for
transparent transfer of whole circuits (T1,E1,T3,E3). Although AAL1
provides no inherent advantage as compared to SAToP for unstructured
transport, in certain cases AAL1 may be required or desirable. For
example, when it is necessary to interwork with an existing AAL1-
based network, or when clock recovery based on AAL1-specific
mechanisms is favored.
For unstructured AAL1 the 47 bytes after the sequence number byte
contain the full 376 bits from the TDM bit stream. No frame
synchronization is supplied or implied, and framing is the sole
responsibility of the end-user equipment. Hence the unstructured
mode can be used to carry data, and for circuits with nonstandard
frame synchronization. For the T1 case the raw frame consists of 193
bits, and hence 1 183/193 T1 frames fit into each AAL1 PDU. The E1
frame consists of 256 bits, and so 1 15/32 E1 frames fit into each
PDU.
Stein, et al. Expires March 25, 2006 [Page 32]
Internet-Draft TDMoIP Sept 2005
When the TDM circuit is channelized according to [G704], and in
particular when it is desired to fractional E1 or T1, it is
advantageous to use one of the structured AAL1 circuit emulation
services. Structured AAL1 views the data not merely as a bit stream,
but as a bundle of channels. Furthermore, when CAS signaling is used
it can be formatted so that it can be readily detected and
manipulated.
In the structured circuit emulation mode without CAS, N bytes from
the N channels to be transported are first arranged in order of
channel number. Thus if channels 2, 3, 5, 7 and 11 are to be
transported the corresponding five bytes are placed in the PDU
immediately after the sequence number byte. This placement is
repeated until all 47 bytes in the PDU are taken;
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
the next PDU commences where the present PDU left off
byte 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
channel 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7
and so forth. The set of channels 2,3,5,7,11 is the basic structure
and the point where one structure ends and the next commences is the
structure boundary.
The problem with this arrangement is the lack of explicit indication
of the byte identities. As can be seen in the above example, each
AAL1 PDU starts with a different channel, so a single lost packet
will result in misidentifying channels from that point onwards,
without possibility of recovery. The solution to this deficiency is
the periodic introduction of a pointer to the next structure
boundary. This pointer need not be used too frequently, as the
channel identifications are uniquely inferable unless packets are
lost.
The particular method used in AAL1 is to insert a pointer once every
sequence number cycle of eight PDUs. The pointer is seven bits and
protected by an even parity MSB, and so occupies a single byte.
Since seven bits are sufficient to represent offsets larger than 47,
we can limit the placement of the pointer byte to PDUs with even
sequence number. Unlike most AAL1 PDUs that contain 47 TDM bytes,
PDUs that contain a pointer (P-format PDUs) have the following
format.
Stein, et al. Expires March 25, 2006 [Page 33]
Internet-Draft TDMoIP Sept 2005
0 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P|E| pointer | 46 bytes of payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
where
C (1 bit) convergence sublayer indication, C=1 for P-format PDUs.
SN (3 bits) is an even AAL1 sequence number.
CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN.
P (1 bit) even byte parity LSB for sequence number byte.
E (1 bit) even byte parity MSB for pointer byte.
pointer (7 bits) pointer to next structure boundary.
Since P-format PDUs have 46 bytes of payload and the next PDU has 47
bytes, viewed as a single entity the pointer needs to indicate one of
93 bytes. If P=0 it is understood that the structure commences with
the following byte (i.e. the first byte in the payload belongs to the
lowest numbered channel). P=93 means that the last byte of the
second PDU is the final byte of the structure, and the following PDU
commences with a new structure. The special value P=127 indicates
that there is no structure boundary to be indicated (needed when
extremely large structures are being transported).
The P-format PDU is always placed at the first possible position in
the sequence number cycle that a structure boundary occurs, and can
only occur once per cycle.
The only difference between the structured circuit emulation format
and structured circuit emulation with CAS is the definition of the
structure. Whereas in structured circuit emulation the structure is
composed of the N channels, in structured circuit emulation with CAS
the structure encompasses the superframe consisting of multiple
repetitions of the N channels and then the CAS signaling bits. The
CAS bits are tightly packed into bytes and the final byte is padded
with zeros if required.
For example, for E1 circuits the CAS signaling bits are updated once
per superframe of 16 frames. Hence the structure for N*64 derived
from an E1 with CAS signaling consists of 16 repetitions of N bytes,
followed by N sets of the four ABCD bits, and finally four zero bits
if N is odd. For example, the structure for channels 2,3 and 5 will
Stein, et al. Expires March 25, 2006 [Page 34]
Internet-Draft TDMoIP Sept 2005
be as follows
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 2 3 5
2 3 5 2 3 5 2 3 5 2 3 5 2 3 5 [ABCD2 ABCD3] [ABCD5 0000]
Similarly for T1 ESF circuits the superframe is 24 frames, and the
structure consists of 24 repetitions of N bytes, followed by the ABCD
bits as before. For the T1 case the signaling bits will in general
appear twice, in their regular (bit-robbed) positions and at the end
of the structure.
Stein, et al. Expires March 25, 2006 [Page 35]
Internet-Draft TDMoIP Sept 2005
Appendix C. AAL2 Review
The basic AAL2 PDU is :
| Byte 1 | Byte 2 | Byte 3 |
0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
| CID | LI | UUI | HEC | PAYLOAD
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
CID (8 bits) channel identifier is an identifier that must be unique
for the PW. The values 0-7 are reserved for special purposes,
(and if interworking with VoDSL is required, so are values 8
through 15 as specified in [LES]), thus leaving 248 (240) CIDs per
PW. The mapping of CID values to channels MAY be manually
configured manually or signaled.
LI (6 bits) length indicator is one less than the length of the
payload in bytes. Note that the payload is limited to 64 bytes.
UUI (5 bits) user-to-user indication is the higher layer
(application) identifier and counter. For voice data the UUI will
always be in the range 0-15, and SHOULD be incremented modulo 16
each time a channel buffer is sent. The receiver MAY monitor this
sequence. UUI is set to 24 for CAS signaling packets.
HEC (5 bits) the header error control
Payload - voice A block of length indicated by LI of voice samples
are placed as- is into the AAL2 packet.
Payload - CAS signaling For CAS signaling the payload is formatted as
an AAL2 "fully protected" (type 3) packet (see [AAL2]) in order to
ensure error protection. The signaling is sent with the same CID
as the corresponding voice channel. Signaling MUST be sent
whenever the state of the ABCD bits changes, and SHOULD be sent
with triple redundancy, i.e. sent three times spaced 5
milliseconds apart. In addition, the entire set of the signaling
bits SHOULD be sent periodically to ensure reliability.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | CRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CRC (cont) |
+-+-+-+-+-+-+-+-+
Stein, et al. Expires March 25, 2006 [Page 36]
Internet-Draft TDMoIP Sept 2005
RED (2 bits) is the triple redundancy counter. For the first packet
it takes the value 00, for the second 01 and for the third 10.
RED=11 means non-redundant information, and is used when triple
redundancy is not employed, and for periodic refresh messages.
Timestamp (14 bits) The timestamp is optional and in particular is
not needed if RTP is employed. If not used the timestamp MUST be
set to zero. When used with triple redundancy it MUST be the same
for all three redundant transmissions.
RES (4 bits) is reserved and MUST be set to zero.
ABCD (4 bits) are the CAS signaling bits.
type (6 bits) for CAS signaling this is 000011.
CRC-10 (10 bits) is a 10 bit CRC error detection code.
Stein, et al. Expires March 25, 2006 [Page 37]
Internet-Draft TDMoIP Sept 2005
Appendix D. Performance Monitoring Mechanisms
PWs require OAM mechanisms to monitor performance measures that
impact the emulated service. Performance measures, such as packet
loss ratio and packet delay variation, may be used to set various
parameters and thresholds; for TDMoIP PWs adaptive timing recovery
and packet loss concealment algorithms may benefit from such
information. In addition, OAM mechanisms may be used to collect
statistics relating to the underlying PSN [IPPM], and its suitability
for carrying TDM services.
TDMoIP GWs may benefit from knowledge of PSN performance metrics,
such as round trip time (RTT), packet delay variation (PDV) and
packet loss ratio (PLR). These measurements are conventionally
performed by a separate flow of packets designed for this purpose,
e.g. ICMP packets [ICMP] or MPLS LSP ping packets [LSP-PING] with
multiple timestamps. For AAL1 mode TDMoIP sends packets across the
PSN at a constant rate, and hence no additional OAM flow is required
for measurement of PDV or PLR. However, separate OAM flows are
required for RTT measurement, for AAL2 mode PWs, for measurement of
parameters at setup, for monitoring of inactive backup PWs, and for
low-rate monitoring of PSNs after PWs have been withdrawn due to
service failures.
If the underlying PSN has appropriate maintenance mechanisms that
provide connectivity verification, RTT, PDV, and PLR measurements
that correlate well with those of the PW, then these mechanisms
SHOULD be used. If such mechanisms are not available, either of two
similar OAM signaling mechanisms may be used. The first is internal
to the PW and based on inband VCCV [VCCV], and the second that runs
in a separate PW placed in the same tunnel. The latter is
particularly efficient when a large number of TDM PWs are placed in a
single PSN tunnel, and hence experience similar network impairments.
D.1 TDMoIP Connectivity Verification
In most conventional IP applications a server sends some finite
amount of information over the network after explicit request from a
client. With TDMoIP PWs the PSN-bound GW could send a continuous
stream of packets towards the destination without knowing whether the
TDM-bound GW is ready to accept them. For layer-2 networks this may
lead to flooding of the PSN with stray packets.
This problem may occur when a TDMoIP GW is first brought up, when the
TDM-bound GW fails or is disconnected from the PSN, or the PW is
broken. After an aging time the destination gateway disappears from
the routing tables, and intermediate switches may flood the network
with the TDMoIP packets in an attempt to find a new path.
Stein, et al. Expires March 25, 2006 [Page 38]
Internet-Draft TDMoIP Sept 2005
The solution to this problem is to significantly reduce the number of
TDMoIP packets transmitted per second when PW failure is detected,
and to return to full rate only when the PW is available. The
detection of failure and restoration is made possible by the periodic
exchange of one-way connectivity-verification messages, as defined in
[CONNECT].
Connectivity is tested by periodically sending OAM messages from the
source GW to the destination GW, and having the destination reply to
each message. The connectivity verification mechanism SHOULD be used
during setup and configuration. Without OAM signaling one must
ensure that the destination GW is ready to receive packets before
starting to send them. Since TDMoIP gateways operate full-duplex,
both would need to be set up and properly configured simultaneously
if flooding is to be avoided. When using connectivity verification,
a configured gateway may wait until it detects its peer before
transmitting at full rate. In addition, configuration errors may be
readily discovered by using the service specific field of the OAM PW
packets.
In addition to one way connectivity, OAM signaling mechanisms can be
used to request and report on various PSN metrics, such as one way
delay, round trip delay, packet delay variation, etc. They may also
be used for remote diagnostics, and for unsolicited reporting of
potential problems (e.g. dying gasp messages).
D.2 OAM Packet Format
When using inband performance monitoring, additional packets are sent
using the same PW label. These packets are identified by having
their first nibble equal to 0001, and must be separated from TDM data
packets before further processing of the control word.
The format of an inband OAM PW message packet is depicted in the
following figure. Note that the PSN-specific layers are identical to
those used to carry the TDMoIP data.
Stein, et al. Expires March 25, 2006 [Page 39]
Internet-Draft TDMoIP Sept 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN-specific layers (with same PW label as data) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 1|FMTID| RES | Channel Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Msg Type | OAM Msg Code | Service specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FMTID (3 bits) MUST be set to zero per [PWECW].
RES (9 bits) is reserved, and MUST be set to zero.
Channel Type (16 bits) MUST be set to the value allocated by IANA for
TDMoIP inband OAM.
The remaining fields will be described below.
When using a separate OAM PW, all OAM messages MUST use the PW label
preconfigured to indicate OAM (the default value is the highest label
available). All PSN layer parameters (for example, MPLS label, IP
addresses, TOS, EXP bits, and VLAN ID) MUST remain those of the PW
being investigated.
The format of an inband OAM PW message packet for UDP/IP PSNs is
based on [ICMP]. The PSN-specific layers are identical to those
defined in Section 3.1 with the PW label set to the value
preconfigured or assigned for PW OAM.
Stein, et al. Expires March 25, 2006 [Page 40]
Internet-Draft TDMoIP Sept 2005
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PSN-specific layers (with preconfigured PW label) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0 0 0 0|L|R| M |RES| Length | OAM Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Msg Type | OAM Msg Code | Service specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Forward PW label | Reverse PW label |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L, R, and M are identical to those of the PW being tested.
Length is the length in bytes of the OAM message packet.
OAM Sequence Number (16 bits) is used to uniquely identify the
message. Its value is unrelated to the sequence number of the
TDMoIP data packets for the PW in question. It is incremented in
query messages, and replicated without change in replies.
OAM Msg Type (8 bits) indicates the function of the message. At
present the following are defined:
0 for one way connectivity query message
8 for one way connectivity reply message.
OAM Msg Code (8 bits) is used to carry information related to the
message, and its interpretation depends on the message type. For
type 0 (connectivity query) messages the following codes are
defined:
0 validate connection.
1 do not validate connection
for type 8 (connectivity reply) messages the available codes are:
0 acknowledge valid query
1 invalid query (configuration mismatch).
Stein, et al. Expires March 25, 2006 [Page 41]
Internet-Draft TDMoIP Sept 2005
Service specific information (16 bits) is a field that can be used to
exchange configuration information between gateways. If it is not
used this field MUST contain zero. Its interpretation depends on
the payload type. At present the following is defined for AAL1
payloads.
0 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Number of TSs | Number of SFs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Number of TSs (8 bits) is the number of channels being transported,
e.g. 24 for full T1.
Number of SFs (8 bits) is the number of 48-byte AAL1 PDUs per packet,
e.g. 8 when packing 8 PDUs per packet.
Forward PW label (16 bits) is the PW label used for TDMoIP traffic
from the source to destination gateway.
Reverse PW label (16 bits) is the PW label used for TDMoIP traffic
from the destination to source gateway.
Source Transmit Timestamp (32 bits) represents the time the PSN-bound
GW transmitted the query message. This field and the following
ones only appear if delay is being measured. All time units are
derived from a clock of preconfigured frequency, the default being
100 microseconds.
Destination Receive Timestamp (32 bits) represents the time the
destination gateway received the query message.
Destination Transmit Timestamp (32 bits) represents the time the
destination gateway transmitted the reply message.
Stein, et al. Expires March 25, 2006 [Page 42]
Internet-Draft TDMoIP Sept 2005
Appendix E. Capabilities, Configuration and Statistics
Every TDMoIP GW will support some number of physical TDM connections,
certain types of PSN, and some subset of the modes defined above.
The following capabilities SHOULD be able to be queried by the
management system:
AAL1 capable
AAL2 capable (and AAL2 parameters, e.g. support for VAD and
compression)
HDLC capable
Supported PSN types (UDP/IPv4, UDP/IPv6, L2TPv3/IPv4, L2TPv3/IPv6,
MPLS, Ethernet)
OAM support (none, separate PW, VCCV) and capabilities (CV, delay
measurement, etc.)
maximum packet size supported.
For every TDM PW the following parameters MUST be provisioned or
signaled:
PW label (for UDP and Ethernet the label MUST be manually
configured)
TDM type (E1, T1, E3, T3, fractional E1, fractional T1)
for fractional links: number of timeslots
TDMoIP mode (AAL1, AAL2, HDLC)
for AAL1 mode:
AAL1 type (unstructured, structured, structured with CAS)
number of AAL1 PDUs per packet
for AAL2 mode:
CID mapping
creation time of full minicell (units of 125 microsecond)
Stein, et al. Expires March 25, 2006 [Page 43]
Internet-Draft TDMoIP Sept 2005
size of jitter buffer (in 32-bit words)
clock recovery method (local, loop-back timing, adaptive, common
clock)
use of RTP (if used: frequency of common clock, PT and SSRC
values).
During operation the following statistics and impairment indications
SHOULD be collected for each TDM PW, and can be queried by the
management system.
average round-trip delay
packet delay variation (maximum delay - minimum delay)
number of potentially lost packets
indication of misordered packets (succesfully reordered or
dropped)
for AAL1 mode PWs:
indication of malformed PDUs (incorrect CRC, bad C, P or E)
indication of cells with pointer mismatch
number of seconds with jitter buffer over-run events
number of seconds with jitter buffer under-run events
for AAL2 mode PWs:
number of malformed minicells (incorrect HEC)
indication of misordered minicells (unexpected UUI)
indication of stray minicells (CID unknown, illegal UUI)
indication of mis-sized minicells (unexpected LI)
for each CID: number of seconds with jitter buffer over-run
events
for HDLC mode PWs:
number of discarded frames from TDM (e.g. CRC error, illegal
packet size)
Stein, et al. Expires March 25, 2006 [Page 44]
Internet-Draft TDMoIP Sept 2005
number of seconds with jitter buffer over-run events.
During operation the following statistics MAY be collected for each
TDM PW.
number of packets sent to PSN
number of packets received from PSN
number of seconds during which packets were received with L flag
set
number of seconds during which packets were received with R flag
set.
Stein, et al. Expires March 25, 2006 [Page 45]
Internet-Draft TDMoIP Sept 2005
Intellectual Property Statement
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.
Disclaimer of Validity
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.
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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Stein, et al. Expires March 25, 2006 [Page 46]
