One document matched: draft-anavi-tdmoip-05.txt-68211.txt
Differences from 05.txt-04.txt
PWE3 Working Group Yaakov (Jonathan) Stein
Internet Draft Ronen Shaashoua
draft-anavi-tdmoip-05.txt Ron Insler
Expires: September 2003 Motty (Mordechai) Anavi
RAD Data Communications
March 2003
TDM over IP
draft-anavi-tdmoip-05.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
TDMoIP [PAGE 1]
TDM over IP March, 2003
Abstract
This document describes methods for transporting time division
multiplexed (TDM) digital voice and data signals over Pseudo-
wires. It is a revision of the document draft-anavi-tdmoip-04.
Conventions used in this document
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 RFC 2119.
Table of Contents
1. Introduction .................................................2
2. TDMoIP Encapsulation .........................................3
3. Encapsulation Details for Specific PSNs ......................6
4. TDMoIP Payload types ........................................10
5. Raw Payload (FORMID=1000) ...................................10
6. AAL1 Format Payload (FORMID=11XX) ...........................11
7. ATM PW Compatibility Mode (FORMID=0000) .....................14
8. AAL2 Format Payload (FORMID=1001) ...........................15
9. HDLC Format Payload (FORMID=1111) ...........................17
10. OAM Signaling ..............................................18
11. Implementation Issues ......................................21
12. Security Considerations ....................................23
13. IANA Considerations ........................................23
14. Normative References .......................................23
15. Informative References .....................................24
16. Acknowledgments ............................................25
17. Contact Information ........................................25
1. Introduction
Telephony traffic is conventionally carried over connection-
oriented synchronous or plesiochronous networks (which will be
loosely called TDM networks herein). With the proliferation of
packet-switched networks (PSNs), telephony carriers desire
integration of TDM services into a unified PSN infrastructure.
This integration requires emulation of TDM circuits within the
PSN, a function that can be carried out using Pseudo-Wires (PWs),
as described in the PWE3 requirements [PWE-REQ] and architecture
[PWE-ARCH] documents. This emulation must ensure QoS and voice
quality similar to those of existing TDM networks as well as
preserving signaling features.
Stein et al. [PAGE 2]
TDM over IP March, 2003
In this document we describe a protocol for tunneling TDM traffic
through PSNs using PWs. This protocol can support various TDM
traffic types, including n*64K, unstructured T1/E1, structured
T1/E1 with and without CAS signaling, T3/E3, and TDM in AAL1 and
AAL2 networks. The precise requirements of the emulation for each
of these types are described in the TDM requirements document
[TDM-REQ] and in section 11, below.
The protocol as herein described is agnostic to the underlying
PSN, which may be 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 will use the nomenclature TDMoIP for reasons of
consistency with previous versions of this draft.
2. TDMoIP Encapsulation
2.1 Layering Model
The protocol-layering model used by TDMoIP is shown in the figure,
where the order is that of the physical packet, so that higher
layers appear lower in the diagram.
+---------------------------+
| PSN-specific layers |
+---------------------------+
| RTP(optional) |
+---------------------------+
| control word |
+---------------------------+
| payload |
+---------------------------+
2.2 PSN-specific layers
The PSN-specific layers contain all necessary infrastructure, and
may consist of UDP/IP, MPLS, L2TPv3 over IP, or layer 2 Ethernet.
The PSN is assumed to be reliable enough and of sufficient
bandwidth to enable transport of the required TDM data.
TDMoIP edge devices may handle more than one circuit bundle at a
time. A circuit bundle is defined as a stream of bits that have
originated from a single physical interface or from interfaces
that share a common clock, which are transmitted from a single
TDMoIP source device to a single TDMoIP destination device. For
example, bundles may comprise some number of 64 Kbps timeslots
originating from a single E1, or an entire T3 or E3. Circuit
bundles are uni-direction streams, but are universally coupled
with bundles in the opposite direction to form a bi-directional
connection.
Stein et al. [PAGE 3]
TDM over IP March, 2003
If a TDMoIP edge device is required to handle multiple circuit
bundles, then it is the responsibility of the PSN-specific layers
to provide a circuit bundle identifier (CBID) in order to enable
differentiation between these circuits. These layers will be more
fully discussed in section 3.
2.3 RTP
If timing information needs to be explicitly transferred over the
PSN then RTP MUST be used for this purpose. When the TDMoIP edges
have sufficiently accurate local clocks or can derive a
sufficiently accurate timing source without explicit timestamps,
its use is optional. If RTP is used, the header of following
figure, as defined in [RTP], MUST appear.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTV|P|X| CC |M| PT | RTP sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
RTV (2 bits) the RTP Version number MUST be set to RTV=010
P (1 bit) the RTP padding indicator MUST be set to P=0
X (1 bit) the RTP extension MUST be set to X=0
CC (4 bits) the RTP CSRC count MUST be set to CC=0000
M (1 bit) the RTP marker indicator MUST be set to M=0
PT (7 bits) the RTP Payload Type identifies the RTP stream as
carrying a TDMoIP format payload, and MUST be allocated from the
range of reserved for dynamic values.
RTP Sequence Number (16 bits) is defined separately for each
circuit bundle and increments by one for each TDMoIP packet sent
for that circuit bundle. It MAY be used by the receiver to detect
packet loss and to restore packet sequence. The initial value of
the sequence number SHOULD be random (unpredictable) for security
purposes.
RTP Timestamp (32 bits) The RTP timestamp indicates the precise
sampling instant of the first octet in the TDM payload. It MUST be
derived from a clock whose resolution and accuracy are sufficient
for the required jitter and wander attenuation.
Stein et al. [PAGE 4]
TDM over IP March, 2003
SSRC Identifier (32 bits) the RTP synchronization source
identifier uniquely identifies the circuit bundle's timing source.
It is chosen randomly for independent timing sources as described
in [RTP].
RTP's main drawback is its large overhead (12 bytes). For this
reason TDMoIP allows the RTP header to be omitted when timing
information need not be explicitly transferred over the network.
2.4 TDMoIP Control Word
The 32-bit control word MUST appear in every TDMoIP packet. Its
format is given 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FORMID |L|R| Z |0 0| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FORMID Format identifier (4 bits)
The following values are presently defined:
1000 raw
1100 AAL1 unstructured
1101 AAL1 structured
1110 AAL1 structured w/ CAS
0000 ATM PW compatibility mode
1001 AAL2
1111 HDLC
The payload format for each of these cases will be described in
sections 5, 6, 7, 8 and 9 below.
L Local Loss of Sync failure (1 bit) The L bit being set indicates
that the source has detected or has been informed of a TDM
physical layer fault impacting the data to be transmitted. This
bit can be used to indicate Physical layer LOS that should trigger
AIS generation at the far end. When the L bit is set the contents
of the packet may not be meaningful, and the payload size MAY be
reduced in order to conserve bandwidth. Once set, if the TDM fault
is rectified the L bit MUST be cleared.
R Remote Receive failure (1 bit) The R bit being set indicates
that the source is not receiving packets at its TDMoIP receive
port, indicating failure of that direction of the bi-directional
connection. This indication can be used to signal congestion or
other network related faults. Receiving remote failure indication
MAY trigger fall-back mechanisms for congestion avoidance. The R
bit MUST be set after a preconfigured number of consecutive
packets are not received, and MUST be cleared once packets are
once again received.
Z (2 bits) These bits indicate an extended header format and MUST
be set to zero.
Stein et al. [PAGE 5]
TDM over IP March, 2003
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 SHOULD be set
to zero otherwise.
Sequence number (16 bits) The TDMoIP sequence number MUST be
present when the RTP header is not used and fulfills the same
function as the RTP sequence number. In addition, since the basic
clock rate for each circuit bundle is constant, the sequence
number may be used as an approximate timestamp. The initial value
of the sequence number SHOULD be random (unpredictable) for
security purposes, and the value is incremented modulo 2^16
separately for each circuit bundle. When both RTP and the control
word sequence numbers are used, they SHOULD be identical.
3. Encapsulation Details for Specific PSNs
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:
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | Circuit Bundle Number | Destination Port Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RTV|P|X| CC |M| PT | RTP Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SSRC identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FORMID |L|R| Z |0 0| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| TDMoIP Payload |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stein et al. [PAGE 6]
TDM over IP March, 2003
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 octets of header and data.
Identification (16 bits) is the IP fragmentation identification
field.
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 0x11 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.
VER (3 bits) is the TDMoIP version number. The original version
(VER=000) was experimental and should no longer be used. Presently
VER=001 when RTP is not used, and VER=011 when RTP is used.
Circuit Bundle Number (13 bits) This field is usually dedicated to
the Source Port Number, but here identifies the unique data stream
emanating from a given trunk and sharing a common destination.
This nonstandard use of a UDP port number is similar to RTP/RTCP's
use of port numbers to uniquely identify sessions, and the common
practice (sanctioned in H.225) of randomly allocating port numbers
for VoIP sessions. Here placing the circuit bundle identifier in
the UDP header rather than the application area enables fast
switching. The available circuit bundle numbers are 1-8063; 0 is
invalid; 8191 (1FFF) is used for OAM control messages (see section
10); and the 127 ports 8064-8190 are reserved.
Stein et al. [PAGE 7]
TDM over IP March, 2003
Destination Port Number (16 bits) MUST be set to 0x085E (2142),
the user port number which has been assigned to TDMoIP by the
Internet Assigned Numbers Authority (IANA).
UDP Length (16 bits) is the length in octets 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
The MPLS header as described in [MPLS] is prefixed to the TDMoIP
data. The packet structure (as seen at the edges) 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Outer Label | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Inner Label = CBID | EXP |S| TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FORMID |L|R| Z |0 0| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PAYLOAD |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first two rows depicted above are the MPLS header; the third
is the TDMoIP control word.
Outer Label (20 bits) is the MPLS label which identifies the MPLS
LSP used to tunnel the TDM packets through the MPLS network. It is
also known as the tunnel label or the transport label. The label
number can be assigned either by manual provisioning or via the
MPLS control protocol. While transiting the MPLS network there can
be zero, one or more outer label rows. For label stack usage see
[MPLS].
EXP (3 bits) experimental field
S (1 bit) stacking bit where 1 indicates stack bottom
S=0 for all outer labels
TTL (8 bits) MPLS Time to live
Inner Label (20 bits) the MPLS inner label (also known as the PW
label or the interworking label), contains the circuit bundle
identifier used to multiplex multiple circuit bundles within the
same tunnel. Valid values are as in subsection 3.1 supra. Note
that the inner label is always be at the bottom of the MPLS label
stack, and hence its stacking bit is set.
Stein et al. [PAGE 8]
TDM over IP March, 2003
3.3 L2TPv3
If L2TP is used over IPv4 without UDP the L2TPv3 header defined in
[L2TPv3] is prefixed to the TDMoIP data.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Session ID = CBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 1 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| cookie 2 (optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FORMID |L|R| Z |0 0| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| PAYLOAD |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Session ID (32 bits) is the locally significant L2TP session
identifier, and contains the circuit bundle identifier used to
multiplex multiple circuit bundles within the same tunnel. Valid
values are as in subsection 3.1 supra.
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 circuit bundle.
3.4 Ethernet
The TDMoIP packet described in the previous subsections will
frequenctly be further encapsulated in an Ethernet frame by
prefixing the Ethernet preamble, destination and source MAC
addresses, optional VLAN header, etc. and appending the four octet
frame check sequence after the TDMoIP frame.
TDMoIP implementations MUST be able to receive both industry
standard (DIX) Ethernet and IEEE 802.3 CSMA/CD 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, zero 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 non-RTP AAL2 adapted E1 trunk with 31 channels is
8*4 + 31*47 = 1489 octets. This falls below the maximal permitted
payload size of 1500 bytes.
The direct use of layer 2 Ethernet frames without IP or MPLS
layers is for further study.
Stein et al. [PAGE 9]
TDM over IP March, 2003
4. TDMoIP Payload types
TDMoIP is a trunking application, i.e. it transports entire trunks
containing multiple voice and/or data streams. Trunking can be
carried out at two levels - circuit emulation and loop emulation.
In circuit emulation the entire TDM trunk is transferred across
the network as a whole without separation into individual
timeslots, while in loop emulation the individual timeslots are
identified and transported, albeit while preserving the trunk
integrity.
At present we define five different payload types, namely raw,
AAL1, ATM-PW compatibility mode, AAL2, and HDLC. Raw encapsulation
is only advisable for high quality networks carrying unstructured
TDM traffic. AAL1 is used for circuit emulation, while AAL2 is
used for loop emulation. AAL1 is thus best for unstructured
trunks, or for structured trunks with relatively constant usage.
AAL1 also must be used for structured transport when some of the
timeslots carry data. AAL2 is used to conserve bandwidth for
structured voice trunks in which usage is highly variable. The
HDLC mode is mainly for efficient transport of trunk associated
CCS signaling.
The AAL family of protocols is a natural choice for trunking
applications. 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 bandwidth data streams over a packet network.
In addition, since the AAL mechanisms are extensively used within
and on the edge of the telephony system, they were specifically
designed for audio, non-audio data and telephony signaling.
Finally, simple service interworking with legacy TDM networks is a
major design goal of TDMoIP. Hence, payload types were chosen in
order to simplify interworking with the existing infrastructure,
including AAL1 and AAL2 networks.
5. Raw Payload (FORMID=1000)
For transport of unstructured TDM over networks where the packet
delay variation and packet loss are expected to be very low, the
payload can be encapsulated without adaptation. Arbitrary constant
length payloads MAY be placed as-is in the payload field, with no
bit or byte alignment implied.
By constraining the payload size to be a constant for a given
flow, a certain resilience to packet loss is attained. When a
packet is determined to have been lost, the egress edge device MAY
send the proper number of a preconfigured byte to the TDM
interface. This ensures that the TDM timing will be maintained,
although the TDM data will be corrupted.
Stein et al. [PAGE 10]
TDM over IP March, 2003
6. AAL1 Format Payload (FORMID=11XX)
For the prevalent case for which the timeslot allocation is static
and no activity detection is performed, the payload can be
efficiently encoded using constant bit rate AAL1 adaptation. The
AAL1 format is described in [AAL1] and its use for circuit
emulation over ATM in [CES]. We will herein briefly describe the
use of AAL1 in the context of TDMoIP; the reader will find the
full description in the normative references.
In AAL1 mode the TDMoIP payload consists of between one and thirty
48-octet subframes. The number of subframes, which can be inferred
by the receiving side from the total packet length as specified in
the PSN header, is pre-configured and typically chosen according
to latency and bandwidth constraints. Using a single subframe
reduces latency to a minimum, but incurs the highest overhead,
while using, for example, eight subframes reduces the overhead
percentage while increasing the latency by a factor of eight.
+-------------+-----------------+
|control word |48-octet subframe|
+-------------+-----------------+
Single TDMoIP-AAL1 subframe per TDMoIP frame
+-------------+-----------------+ +-----------------+
|control word |48-octet subframe|---|48-octet subframe|
+-------------+-----------------+ +-----------------+
Multiple TDMoIP-AAL1 subframes per TDMoIP frame
The first octet of each 48-octet AAL1 subframe consists of an
error protected three-bit sequence number.
1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+-----------------------
|C| SN | CRC |P| 47 octets of payload
+-+-+-+-+-+-+-+-+-----------------------
where
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 subframe to
subframe.
CRC (3 bits) is a 3 bit error cyclic redundancy code on C and SN
P (1 bit) even byte parity
Stein et al. [PAGE 11]
TDM over IP March, 2003
As can be readily inferred this octet can only take on eight
different values, and incrementing the sequence number forms an
eight subframe sequence number cycle, the importance of which will
become clear shortly.
The structure of the remaining 47 octets in the TDMoIP-AAL1
subframe depends on the subframe 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 subframe is the unstructured one which is used for
transparent transfer of whole trunks (T1,E1,T3,E3). The 47 octets
after the sequence number octet contain 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 for leased lines which
carry data rather than N*64 Kbps timeslots, and even for trunks
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 TDMoIP-AAL1 subframe. The E1 frame consists of 256 bits, and
so 1 15/32 E1 frames fit into each subframe.
When the TDM trunk is segmented into timeslots according to
[G704], and it is desired to transport N*64 Kbps circuit where N
is only a fraction of the full 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 circuit
bundle of timeslots. Furthermore, when CAS signaling is used it
can be formatted such that it can be readily detected and
manipulated.
In the structured circuit emulation mode without CAS, N octets
from the N timeslots to be transported are first arranged in order
of timeslot number. Thus if timeslots 2, 3, 5, 7 and 11 are to be
transported the corresponding five octets are placed in the
subframe immediately after the sequence number octet. This
placement is repeated until all 47 octets in the subframe are
taken;
octet 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
timeslot 2 3 5 7 11 2 3 5 7 11 --- 2 3 5 7 11 2 3
the next subframe commences where the present subframe left off
octet 1 2 3 4 5 6 7 8 9 10 --- 41 42 43 44 45 46 47
timeslot 5 7 11 2 3 5 7 11 2 3 --- 5 7 11 2 3 5 7
and so forth. The set of timeslots 2,3,5,7,11 is called a
structure and the point where one structure ends and the next
commences is a structure boundary.
Stein et al. [PAGE 12]
TDM over IP March, 2003
The problem with this arrangement is the lack of explicit
indication of the octet identities. As can be seen in the above
example, each TDMoIP-AAL1 subframe starts with a different
timeslot, so a single lost packet will result in misidentifying
timeslots 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 timeslot
identification are uniquely inferable unless packets are lost.
The particular method used in AAL1 is to insert a pointer once
every sequence number cycle of length eight subframes. The pointer
is seven bits and protected by an even parity MSB, and so occupies
a single octet. Since seven bits are sufficient to represent
offsets larger than 47, we can limit the placement of the pointer
octet to subframes with even sequence number. Unlike usual TDMoIP-
AAL1 subframes with 47 octets available for payload, subframes
which contain a pointer, called P-format subframes, have the
following format.
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 octets of payload
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
where
C (1 bit) convergence sublayer indication, C=1 for P-format
subframes
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 octet
E (1 bit) even byte parity MSB for pointer octet
pointer (7 bits) pointer to next structure boundary
Since P-format subframes have 46 octets of payload and the next
subframe has 47 octets, viewed as a single entity the pointer
needs to indicate one of 93 octets. If P=0 it is understood that
the structure commences with the following octet (i.e. the first
octet in the payload belongs to the lowest numbered timeslot).
P=93 means that the last octet of the second subframe is the final
octet of the structure, and the following subframe 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).
Stein et al. [PAGE 13]
TDM over IP March, 2003
The P-format subframe 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 timeslots, in structured circuit
emulation with CAS the structure encompasses the superframe
consisting of multiple repetitions of the N timeslots and then the
CAS signaling bits. The CAS bits are tightly packed into octets
and the final octet is padded with zeros if required.
For example, for E1 trunks 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
octets, followed by N sets of the four ABCD bits, and finally four
zero bits if N is odd. For example, the structure for timeslots
2,3 and 5 will 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 trunks the superframe is 24 frames, and the
structure consists of 24 repetitions of N octets, 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.
7. ATM PW Compatibility Mode (FORMID=0000)
Since TDM traffic can be carried over ATM circuit emulation
services using AAL1, the protocols described in [ATM-ENCAP] may be
used to indirectly transport TDM over pseudo-wires, see [DAVARI].
In such a case the TDM is first converted into an AAL1 ATM flow
according to [AAL1,CES], and thereafter this ATM flow is
encapsulated as described in [ATM-ENCAP].
The TDMoIP control word with an all zero FORMID is compatible with
the control word of [ATM-ENCAP] for the mandatory N:1 mode.
The N:1 mode concatenates ATM cells including their cell headers,
with the exception of the HEC. Hence, a valid and locally unique
VPI/VCI must be allocated to the TDM bundle before this mode can
be utilized.
The format of the control word and payload are as follows:
Stein et al. [PAGE 14]
TDM over IP March, 2003
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|0 0|0 0| Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM AAL1 Payload (48 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VPI | VCI | PTI |C|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ATM AAL1 Payload (48 bytes) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
L and R bits are described in section 2.4 above
VPI (12 bits), VCI (16 bits) are the ATM labels taken from the ATM
cell header
PTI (3 bits) is the ATM payload type identifier copied from the
ATM header and indicates congestion as well as differentiating
between cells containing user data and those used for maintenance
C (1 bit) is the cell loss priority field copied from the ATM
header, with C=1 indicating lower priority.
When using N:1 mode with N greater than one, MPLS OAM signaling
MUST be employed to signal local and remote defects.
While ATM PW compatibility mode enables utilization of network
devices designed according to [ATM-ENCAP] and facilitates service
interworking with existing ATM circuit emulation systems, it has
higher overhead (an additional 4 bytes per 48 byte cell) and its
use impedes exploitation of some features of the intrinsic AAL1
mode. For example, due to the separation of the TDM processing
from the edge devices, access to timing related information may be
lost, resulting in jitter and wander attenuation inferior to that
obtainable via the intrinsic AAL1 mode. Packet interpolation (see
section 11.3, infra) and TDM alarm handling (see section 10,
infra) may also suffer as compared with FORMID=11XX modes.
8. AAL2 Format Payload (FORMID=1001)
When timeslots are dynamically allocated, or silence can be
detected for bandwidth conservation, or congestion avoidance
mechanisms are required (see [TDMoIP-LE]), the payload can be
efficiently encoded using variable bit rate AAL2 adaptation.
The variable bit rate AAL2 format is described in [AAL2] and its
use for loop emulation over ATM is explained in [SSCS,LES].
Stein et al. [PAGE 15]
TDM over IP March, 2003
For TDMoIP the AAL2 streams are not be segmented into ATM cells,
rather the AAL2 payloads belonging to all timeslots are
concatenated, and a single packet sent over the network.
The basic AAL2-CPS packet is :
| Octet 1 | Octet 2 | Octet 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 a unique identifier for the
bundle. The values below 8 are reserved and so there are 248
possible channels. The mapping of CID values to trunk timeslots is
outside the scope of the TDMoIP protocol and must be configured
during installation or via network management.
LI (6 bits) length indicator is one less than the length of the
payload in octets. (Note that the payload is limited to 64
octets.)
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 a type 3 packet (in
the notation of [AAL2]) in order to ensure error protection. The
signaling is sent with the same CID as the corresponding voice
channel. Signaling is sent whenever the state of the ABCD bits
changes, and is sent with triple redundancy, i.e. sent three times
spaced 5 milliseconds apart. In addition, the entire set of the
signaling bits is sent periodically to ensure reliability.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|RED| timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RES | ABCD | type | CRC
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
CRC (cont) | PAD |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Stein et al. [PAGE 16]
TDM over IP March, 2003
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 for
periodic refresh of the CAS information.
Timestamp (14 bits)
The timestamp is 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
PAD (8 bits) is set to zero.
[PWE-ARCH] denotes as Native Service Processing (NSP) functions
all processing of the TDM data before its use as payload. As
discussed in [TDMoIP-LE] arbitrary NSP functions MAY be performed
before the timeslot is placed in the AAL2 loop emulation payload.
This includes testing for on-hook/off-hook status, voice activity
detection, speech compression, fax/modem relay, etc.
9. HDLC Format Payload (FORMID=1111)
The motivation for handling HDLC in TDMoIP is to efficiently
transport CCS (common channel signaling such as SS7) which is
embedded in the TDM stream. This mechanism is not intended for
general HDLC payloads.
The HDLC format is intended to operate in port mode, transparently
passing all HDLC data and control messages over the PW.
In order to transport HDLC the sender 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 bit unstuffing has been performed. When an TDMoIP-
HDLC frame is received its FCS is calculated, and the original
HDLC frame reconstituted.
This format assumes that the HDLC messages are shorter than the
maximum packet size and hence fragmentation is never required.
Stein et al. [PAGE 17]
TDM over IP March, 2003
10. OAM Signaling
Since the TDMoIP PW is not absolutely reliable, it requires a
signaling mechanism to provide feedback regarding problems in the
communications environment. In addition, such signaling can be
used to collect statistics relating to the performance of the
underlying PSN [IPPM].
If the underlying PSN has adequate signaling mechanisms then these
are to be used. If not, the ICMP-like procedures detailed below
SHOULD be followed.
All TDMoIP OAM signaling messages MUST use CBID 8191 (1FFF). All
PSN layer parameters (for example, IP addresses, TOS, EXP bits,
and VLAN ID) MUST remain those of the circuit bundle being
investigated.
10.1 Connectivity-Check Messages
In most conventional IP applications a server sends some finite
amount of information over the network upon explicit request from
a client. With TDMoIP the source sends a continuous stream of
packets towards the destination without knowing whether the
destination device is ready to accept them, leading to flooding of
the PSN.
The problem may occur when an edge device fails or is disconnected
from the PSN, or the PW is broken. After an aging time the
destination edge disappears from the routing tables, and
intermediate routers may flood the network with the TDMoIP packets
in an attempt to find a new path.
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 restored.
The detection of failure and restoration is made possible by the
periodic exchange of one-way connectivity-check messages, as
defined in [CONNECT].
Connectivity is tested by periodically sending OAM messages from
the source edge to the destination edge, and having the
destination reply to each message. The format of connectivity-
check messages is given in subsection 10.3 infra.
The connectivity check mechanism can also be useful during setup
and configuration. Without OAM signaling one must ensure that the
destination edge is ready to receive packets before starting to
send them. Since TDMoIP edge devices usually operate full-duplex,
both edges must be set up and properly configured simultaneously
if flooding is to be avoided. By using the connectivity mechanism
a configured edge device waits until it can detect its destination
before transmitting at full rate. In addition, errors in
configuration can be readily discovered by using the service
specific field.
Stein et al. [PAGE 18]
TDM over IP March, 2003
10.2 Performance Measurements
In addition to one way connectivity, the OAM signaling mechanism
can be used to request and report on various PSN metrics, such as
one way delay, round trip delay, packet delay variation, etc. It
can also be used for remote diagnostics, and for unsolicited
reporting of potential problems (e.g. dying gasp messages).
10.3 The format of an OAM message packet is depicted in the
following figure. Note that PSN-specific layers are identical to
those used to carry the TDMoIP data, with the exception that their
CBID = 1FFF instead of the usual circuit bundle identifier.
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 CBID=1FFF) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|FORMID |L|R| Z | Length | OAM Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OAM Msg Type | OAM Msg Code | Service specific information |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source CBID | Destination CBID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Receive Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Transmit Timestamp |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
FORMID and L, R, and Z are identical to those used for the circuit
bundle 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 circuit bundle 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.
Stein et al. [PAGE 19]
TDM over IP March, 2003
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).
Service specific information (16 bits) is a field that can be used
to exchange configuration information between edge devices. If it
is not used this field MUST contain zero. Its interpretation
depends on the FORMID field. 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 timeslots being
transported, e.g. 24 for full T1.
Number of SFs (8 bits) is the number of 48-octet AAL1 subframes
per packet, e.g. 8 when packing 8 subframes per packet.
Source CBID (16 bits) uniquely identifies the circuit bundle as
labeled by the source edge.
Destination CBID (16 bits) uniquely identifies the circuit bundle
as labeled by the destination edge.
Source Transmit Timestamp (32 bits) represents the time the source
edge transmitted the query message in units of 100 microseconds.
This field and the following ones only appear if delay is being
measured.
Destination Receive Timestamp (32 bits) represents the time the
destination edge received the query message in units of 100
microseconds
Destination Transmit Timestamp (32 bits) represents the time the
destination edge transmitted the reply message in units of 100
microseconds.
Stein et al. [PAGE 20]
TDM over IP March, 2003
11. 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.
11.1 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.
11.2 Timing
TDM networks are inherently synchronous; somewhere in the network
there will always be at least one extremely accurate primary
reference clock, with long-term accuracy of one part in 10E-11.
This node, whose accuracy is called "stratum 1", provides
reference timing to secondary nodes with lower "stratum 2"
accuracy, and these in turn provide reference clock to "stratum 3"
nodes. This hierarchy of time synchronization is essential for the
proper functioning of the network as a whole; for details see
[G823,G824]. The use of time standards less accurate than stratum
4 is NOT RECOMMENDED as it may result in service impairments.
Packets in IP networks reach their destination with delay that has
a random component, known as jitter. When emulating TDM on a PSN,
it is possible to overcome this randomness by using a "jitter
buffer" on all incoming data, assuming the proper time reference
is available. The problem is that the original TDM time reference
information is not disseminated through the PSN.
In broadest terms there are two methods of overcoming this
difficulty; in one the timing information is provided by some
means independent of the PSN, while in the other the timing must
be transferred over the PSN.
For example, if the entire TDM infrastructure (or at least major
portions of it) is replaced by TDMoIP timing information MUST be
delivered over the IP network, and the reconstructed TDM stream
SHOULD conform to ITU-T recommendations [G823] for E1 and [G824]
for T1 trunks.
However, TDMoIP is frequently used in a "toll-bypass" scenario,
where an IP link connects two existing TDM networks. In such a
case both TDMoIP devices MUST receive accurate timing from the TDM
networks to which they connect, and MUST use this local timing
when outputting to the TDM network. There is no need to carry
timing over the IP network and the overhead associated with RTP
can be avoided.
Stein et al. [PAGE 21]
TDM over IP March, 2003
11.3 Jitter and Packet Loss
In order to compensate for packet delay variation that exists in
any IP network a jitter buffer MUST be provided. The length of
this buffer SHOULD be configurable and MAY be dynamic (i.e. grow
and shrink in length according to the statistics of the delay
variation).
In order to handle (infrequent) packet loss and misordering a
packet order integrity mechanism MUST be provided. This mechanism
MUST track the serial numbers of packets in the jitter buffer and
MUST take appropriate action when faults are detected. When
missing packet(s) are detected the mechanism MUST output
interpolation packet(s) in order to retain TDM timing. Packets
with incorrect serial numbers or other detectable header errors
MAY be discarded. Packets arriving in incorrect order SHOULD be
swapped. Whenever possible, interpolation packets SHOULD ensure
that proper synchronization bits are sent to the TDM network.
While the insertion of arbitrary interpolation packets may be
sufficient to maintain the TDM timing, for voice traffic packet
loss can cause in gaps or artifacts that result in choppy,
annoying or even unintelligible speech, see [TDM-PLC]. 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 estimating the missing sample
values.
11.4 Overhead vs. Latency Trade-off
TDMoIP is designed to be parsimonious in bandwidth. To assist in
achieving this goal we allow merging multiple subframes into a
single packet in order to incur a single header. For example, for
AAL1 payloads, there are N subframes per packet, where N is a
configurable parameter. While higher values of N reduce overhead,
they increase the amount of time that passes between ingress of a
TDM sample and its transmission over the PSN.
This buffering delay must be added to the network propagation
delay and all other delays the packet experiences. Since the
amount of latency that can be considered acceptable is dependent
upon the application, it is essential that there be a method for
tuning this trade-off between efficiency and latency.
Stein et al. [PAGE 22]
TDM over IP March, 2003
12. 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.
TDMoIP does not provide protection against malicious users
utilizing snooping or packet injection during setup or operation.
Circuit bundle identifiers SHOULD be selected in an unpredictable
manner rather than sequentially or otherwise in order to deter
session hijacking. When using L2TP randomly selected cookies MAY
be used to validate circuit bundle origin. Sequence numbers SHOULD
be randomly initialized in order to increase the difficulty of
decrypting based on packet headers.
13. 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 the
to TDMoIP.
The format identifiers (FORMID) will need to be standardized.
14. Normative References
[UDP] RFC 768 (STD0006) User Datagram Protocol (UDP)
[IPv4] RFC 791 (STD0005) Internet Protocol (IP)
[NTP] RFC 1305 Network Time Protocol (NTP) (Version 3)
[RTP] RFC 1889 RTP: Transport Protocol for Real-Time Applications
[IPPM] RFC 2330 Framework for IP Performance Metrics
[CONNECT] RFC 2678 IPPM Metrics for Measuring Connectivity
[DELAY] RFC 2679 A One-way Delay Metric for IPPM
[MPLS] RFC 3032 MPLS Label Stack encoding
[L2TPv3] draft-ietf-l2tpext-l2tp-base-06.txt (01/03)
Layer Two Tunneling Protocol (L2TPv3), J. Lau et al., work in
progress
[G704] ITU-T Recommendation G.704 (10/98)
Synchronous frame structures used at 1544, 6312, 2048, 8448 and
44736 Kbit/s hierarchical levels
Stein et al. [PAGE 23]
TDM over IP March, 2003
[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
[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
[SSCS] ITU-T Recommendation I.366.2 (02/99)
AAL Type 2 service specific convergence sublayer for trunking
[CES] ATM forum specification atm-vtoa-0078 (CES 2.0)
Circuit Emulation Service Interoperability Specification Ver. 2.0
[LES] ATM forum specification atm-vmoa-0145 (LES)
Voice and Multimedia over ATM - Loop Emulation Service Using AAL2
[ATM-ENCAP] draft ietf
-pwe3-atm-encap-01.txt (02/03)
Encapsulation Methods for Transport of ATM Cells/Frame Over IP and
MPLS Networks, L. Martini et al., work in progress
15. Informative References
[DAVARI] draft-davari-pwe3-aal12-over-psn-01.txt (02/03)
Transport of ATM AAL1 frames over PSN, S. Davari, work in progress
[TDM-REQ] draft-riegel-pwe3-tdm-requirements-01.txt (02/03),
Requirements for Edge-to-Edge Emulation of TDM Circuits over
Packet Switching Networks, M. Riegel et al., work in progress
[PWE3-REQ] draft-ietf-pwe3-requirements-04.txt XiPeng Xiao et al,
Requirements for Pseudo Wire Emulation Edge-to-Edge (PWE3), Work
in progress, December 2002
[PWE3-ARCH] draft-ietf pwe3-
arch-02.txt Stewart Bryant et al,
PWE3 Architecture, Work in progress, November 2002
[TDM-PLC] draft-stein-pwe3-tdm-packetloss-00.txt (09/02),
The Effect of Packet Loss on Voice Quality for TDM over
Pseudowires, Y(J) Stein and I. Druker, work in progress
[TDMoIP-LE] draft-stein-pwe3-tdmoiple-00.txt (02/03),
TDMoIP using Loop Emulation, Y(J) Stein et al., work in progress
Stein et al. [PAGE 24]
TDM over IP March, 2003
16. Acknowledgments
The authors would like to thank Hugo Silberman, Shimon HaLevy,
Tuvia Segal, Eyal Ben Saadon, and Eitan Schwartz of RAD Data
Communications for their valuable contributions to the technology
described herein.
17. Contact Information
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. [PAGE 25]
TDM over IP March, 2003
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
This document and translations of it may be copied and furnished
to others, and derivative works that comment on or otherwise
explain it or assist in its implementation may be prepared,
copied, published and distributed, in whole or in part, without
restriction of any kind, provided that the above copyright notice
and this paragraph are included on all such copies and derivative
works. However, this document itself may not be modified in any
way, such as by removing the copyright notice or references to the
Internet Society or other Internet organizations, except as needed
for the purpose of developing Internet standards in which case the
procedures for copyrights defined in the Internet Standards
process must be followed, or as required to translate it into
languages other than English.
The limited permissions granted above are perpetual and will not
be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on
an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIMS 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."
Stein et al. [PAGE 26]
| PAFTECH AB 2003-2026 | 2026-04-21 02:06:05 |