TDM over IPRAD Data Communications24 Raoul Wallenberg St., Bldg CTel Aviv69719ISRAEL+972 3 645-5389yaakov_s@rad.comRAD Data Communications24 Raoul Wallenberg St., Bldg CTel Aviv69719ISRAEL+972 3 645-5447ronen_s@rad.comRAD Data Communications24 Raoul Wallenberg St., Bldg CTel Aviv69719ISRAEL+972 3 645-5445ron_i@rad.comRAD Data Communications900 Corporate DriveMahwahNJ07430USA+1 201 529-1100 Ext. 213motty@radusa.com
Internet
PWE3TDMpseudowireInternet-Draft
This document describes methods for structure-aware transport of TDM
traffic over packet switched networks using pseudowires.
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.
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], usually 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 a 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 impossible 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 may not 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 in addition to FAS it can contain maintenance information.
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 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 )
and structure-reassembly (see ) 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 .
Despite its name, the TDMoIP(R) protocol herein described tolerates
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 .
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.
The overall format of TDMoIP packets is shown in the following figure.
+---------------------+
| PSN Headers |
+---------------------+
| TDMoIP Control Word |
+---------------------+
| Adapted Payload |
+---------------------+
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 provide a mechanism for explicit transfer of
timing information in the packet.
If RTP is used, the fixed RTP header described in [RTP],
MUST immediately precede the control word for IP PSNs
(UDP/IP and L2TPv3),
and MUST immediately follow it for MPLS and Ethernet.
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 ).
In general the timestamp will measure 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
(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 .
(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 .
(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 .
(2 bits)
These bits are reserved and MUST be set to zero.
(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.
(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 .
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 ),
and the resulting adapted payload is placed into the packet.
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].
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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.
(4 bits) is the IP version number, e.g. for IPv4 IPVER=4. (4 bits) is the length in 32-bit words of the IP header, IHL=5. (8 bits) is the IP type of service. (16 bits) is the length in bytes of header and data. (16 bits) is the IP fragmentation
identification field. (3 bits) are the IP control flags and MUST be set to
Flags=010 to avoid fragmentation. (13 bits) indicates where in the datagram the
fragment belongs and is not used for TDMoIP. (8 bits) is the IP time to live field. Datagrams with
zero in this field are to be discarded. (8 bits) MUST be set to 11 hex = 17 dec to signify UDP. (16 bits) is a checksum for the IP header. (32 bits) is the IP address of the source. (32 bits) is the IP address of the destination. (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 ),
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. (16 bits) is the length in bytes of UDP header and data. (16 bits) is the checksum of UDP/IP header and data.
If not computed it must be set to zero.
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 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.
(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]. (3 bits) experimental field, may be used
to carry DiffServ classification for tunnel labels. (1 bit) the stacking bit indicates MPLS stack bottom.
S=0 for all tunnel labels, and S=1 for the PW label. (8 bits) MPLS Time to live. Should be set to 2 for the 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 ),
one PW label (default FFFFF hex = 1048575 dec) MUST be reserved for the OAM PW.
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Rows 6 through 8 are the L2TPv3 header.
Fields not previously described will now be explained.
the IP protocol field must be set
to 73 hex = 115 dec,
the user port number that has been assigned to L2TP by IANA. (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 ),
one PW label (default FFFFFFFF hex) MUST be reserved for the OAM PW. (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.
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.
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:
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.
(48 bits) is the globally unique
address of a single station that is to receive the packet.
The format is defined in [IEEE802.3]. (48 bits) is the globally unique
address of the station that originated the packet.
The format is defined in [IEEE802.3]. (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. (3 bits) is the VLAN priority, see [IEEE802.1Q]. (1 bit) the "canonical format indicator" being set,
indicates that route descriptors appear; see [IEEE802.1Q]. (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. (16 bits) is the protocol identifier,
as allocated by the IEEE. (20 bits) This label MUST be manually configured.
When using a separate OAM PW (see ),
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. (32 bits) is a CRC error detection field,
calculated per [IEEE802.3].
As discussed at the end of ,
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 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.
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 .
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
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.
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
.
In this section we describe the use of AAL2 in the context of TDMoIP.
+-------------+----------------+ +----------------+
|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 MUST be set to zero.
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.
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.
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, structure-aware mechanisms for which the
PSN-bound GW may remove TDM structure overhead
carrying defect indications,
will require explicit signaling of TDM defect conditions.
We saw in 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 .
+---+ +-----+ +------+ +-----+ +------+ +-----+ +---+
|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.
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, structure-aware transport of channelized TDM MAY
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" 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 , 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
TDMoIP OAM as described in
until connectivity is restored.
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.
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 .
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, 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 properly estimating the missing
speech sample values.
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 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.
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 MPLS network 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 MPLS network SHOULD be measured prior to traffic flow,
to ensure its compliance with latency requirements.
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.
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.
When inband TDMoIP OAM is used (see ),
a value will need to be allocated by IANA from the
PW Associated Channel Type registry for inband TDMoIP OAM.
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.
ITU-T Recommendation I.363.1 (08/96)
B-ISDN ATM Adaptation Layer (AAL) specification: Type 1 ITU-T Recommendation I.363.2 (11/00)
B-ISDN ATM Adaptation Layer (AAL) specification: Type 2 ATM forum specification atm-vtoa-0078 (CES 2.0)
Circuit Emulation Service Interoperability Specification Ver. 2.0 ITU-T Recommendation G.704 (10/98)
Synchronous frame structures used at 1544, 6312, 2048, 8448 and
44736 kbit/s hierarchical levels 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 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 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 ITU-T Recommendation G.826 (13/02)
End-to-end error performance parameters and objectives
for international, constant bit-rate digital paths and connections IEEE 802.1Q,
IEEE Standards for Local and Metropolitan Area Networks —
Virtual Bridged Local Area Networks (2003) 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) RFC 791 (STD0005) Internet Protocol (IP) ATM forum specification atm-vmoa-0145 (LES)
Voice and Multimedia over ATM - Loop Emulation Service Using AAL2 draft-ietf-l2tpext-l2tp-base-10.txt (08/03)
Layer Two Tunneling Protocol (L2TPv3), J. Lau et al.,
work in progress RFC 3032 MPLS Label Stack encoding RFC 3550 RTP: Transport Protocol for Real-Time Applications draft-ietf-pwe3-satop-00.txt (09/03)
Structure-Agnostic TDM over Packet (SAToP), A. Vainshtein and Y. Stein,
work in progress ITU-T Recommendation I.366.2 (11/00)
AAL type 2 service specific convergence sublayer for narrow-band services RFC 768 (STD0006) User Datagram Protocol (UDP) draft-ietf-pwe3-vccv-04.txt (02/05)
Pseudo Wire Virtual Circuit Connectivity Verification,
T. Nadeau and R. Aggarwal, work in progress ITU-T Recommendation Y.1413 (03/04)
TDM-MPLS network interworking - User plane interworking ITU-T Recommendation Y.1414 (07/04)
Voice services - MPLS network interworking draft-ietf-cesopsn-02.txt (01/05),
TDM Circuit Emulation Service over Packet Switched Network,
A. Vainshtein et al, work in progress RFC 2678 IPPM Metrics for Measuring Connectivity RFC 2679 A One-way Delay Metric for IPPM RFC 792 Internet Control Message Protocol. (09/81) RFC 2330 Framework for IP Performance Metrics ITU-T Recommendation Q.931 (05/98)
ISDN user-network interface layer 3 specification
for basic call control draft-ietf-mpls-lsp-ping-07.txt (10/04),
Detecting MPLS Data Plane Failures, K. Kompella et al,
work in progress draft-ietf-pwe3-cw-01.txt (12/04),
PWE3 Control Word for use over an MPLS PSN, Stewart Bryant et al,
work in progress draft-ietf-pwe3-arch-07.txt (3/04),
PWE3 Architecture, Stewart Bryant et al, work in progress ITU-T Recommendation Q.700 (03/93)
Introduction to CCITT Signalling System No. 7 draft-stein-pwe3-tdm-packetloss-01.txt (10/03),
The Effect of Packet Loss on Voice Quality for TDM over
Pseudowires, Y(J) Stein and I. Druker, work in progress draft-ietf-pwe3-tdm-requirements-05.txt (4/04),
Requirements for Edge-to-Edge Emulation of TDM Circuits over
Packet Switching Networks, M. Riegel et al., work in progress 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
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.
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:
The internal variables used by the pseudocode are:
In addition, the algorithm requires one parameter:
Sequence Number Processing Algorithm
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
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
calculate L = ( (played-received) mod 2^16 ) - 2^15
if 0 < L <= R
replace packet previously marked as lost with actual data
else
discard packet
Note: by choosing R=0 we always discard the late packet
]]>
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
+-+-+-+-+-+-+-+-+-----------------------
(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. (3 bits) The AAL1 sequence number increments from PDU to PDU. (3 bits) is a 3 bit error cyclic redundancy code on C and SN. (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 5/8 E1 frames fit into each PDU.
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.
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 (1 bit) convergence sublayer indication, C=1 for P-format PDUs. (3 bits) is an even AAL1 sequence number. (3 bits) is a 3 bit error cyclic redundancy code on C and SN. (1 bit) even byte parity LSB for sequence number byte. (1 bit) even byte parity MSB for pointer byte. (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 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.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
(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. (6 bits) length indicator is one less than the length of the
payload in bytes. Note that the payload is limited to 64 bytes. (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. (5 bits) the header error control
A block of length indicated by LI of voice samples are placed as-
is into the AAL2 packet.
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) |
+-+-+-+-+-+-+-+-+
(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. (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.
(4 bits) is reserved and MUST be set to zero. (4 bits) are the CAS signaling bits. (6 bits) for CAS signaling this is 000011. (10 bits) is a 10 bit CRC error detection code.
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.
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.
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).
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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(3 bits) MUST be set to zero per [PWECW]. (9 bits) is reserved, and MUST be set to zero. (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
with the PW label set to the
value preconfigured or assigned for PW OAM.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
are identical to those of the PW
being tested. is the length in bytes of the OAM message packet. (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. (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.
(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).
(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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
(8 bits) is the number of channels being
transported, e.g. 24 for full T1. (8 bits) is the number of 48-byte AAL1 PDUs
per packet, e.g. 8 when packing 8 PDUs per packet. (16 bits) is the PW label used for TDMoIP
traffic from the source to destination gateway. (16 bits) is the PW label used for TDMoIP
traffic from the destination to source gateway. (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.
(32 bits) represents the time the
destination gateway received the query message. (32 bits) represents the time the
destination gateway transmitted the reply message.
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) 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) 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.