3. The CE-bound IWF MAY use the received value to detect malformed
packets.
The sequence number MUST be the same as the sequence number in the
SAToP control word.
The RTP timestamps are used for carrying timing information over the
network. Their values are generated in accordance with the rules
established in [RFC3550].
The frequency of the clock used for generating timestamps MUST be an
integer multiple of 8 kHz. All implementations of SAToP MUST support
the 8 kHz clock. Other multiples of 8 kHz MAY be used.
The SSRC (synchronization source) value in the RTP header MAY be used
for detection of misconnections, i.e., incorrect interconnection of
attachment circuits.
Timestamp generation MAY be used in the following modes:
1. Absolute mode: The PSN-bound IWF sets timestamps using the
clock recovered from the incoming TDM attachment circuit. As a
consequence, the timestamps are closely correlated with the
sequence numbers. All SAToP implementations that support usage
of the RTP header MUST support this mode.
2. Differential mode: Both IWFs have access to a common high-
quality timing source, and this source is used for timestamp
generation. Support of this mode is OPTIONAL.
Usage of the fixed RTP header in a SAToP PW and all the options
associated with its usage (the timestamping clock frequency, the
timestamping mode, selected PT and SSRC values) MUST be agreed upon
between the two SAToP IWFs during PW setup as described in
[TDM-CONTROL]. Other, RTP-specific methods (e.g., see [RFC3551])
MUST NOT be used.
5. SAToP Payload Layer
5.1. General Payloads
In order to facilitate handling of packet loss in the PSN, all
packets belonging to a given SAToP PW are REQUIRED to carry a fixed
number of bytes filled with TDM data received from the attachment
circuit. The packet payload size MUST be defined during the PW
setup, MUST be the same for both directions of the PW, and MUST
remain unchanged for the lifetime of the PW.
The CE-bound and PSN-bound IWFs MUST agree on SAToP packet payload
size during PW setup (default payload size values defined below
guarantee that such an agreement is always possible). The SAToP
packet payload size can be exchanged over the PWE3 control protocol
([TDM-CONTROL]) by using the Circuit Emulation over Packet (CEP)/TDM
Payload Bytes sub-TLV of the Interface Parameters TLV ([RFC4446]).
SAToP uses the following ordering for packetization of the TDM data:
o The order of the payload bytes corresponds to their order on
the attachment circuit.
o Consecutive bits coming from the attachment circuit fill each
payload byte starting from most significant bit to least
significant.
All SAToP implementations MUST be capable of supporting the following
payload sizes:
o E1 - 256 bytes
o T1 - 192 bytes
o E3 and T3 - 1024 bytes.
Notes:
1. Whatever the selected payload size, SAToP does not assume
alignment to any underlying structure imposed by TDM framing
(byte, frame, or multiframe alignment).
2. When the L bit in the SAToP control word is set, SAToP packets
MAY omit invalid TDM data in order to conserve PSN bandwidth.
3. Payload sizes that are multiples of 47 bytes MAY be used in
conjunction with unstructured ATM-CES [ATM-CES].
5.2. Octet-Aligned T1
An unstructured T1 attachment circuit is sometimes provided already
padded to an integer number of bytes, as described in Annex B of
[G.802]. This occurs when the T1 is de-mapped from a SONET/SDH
virtual tributary/container, or when it is de-framed by a dual-mode
E1/T1 framer.
In order to facilitate operation in such cases, SAToP defines a
special "octet-aligned T1" transport mode. In this mode, the SAToP
payload consists of a number of 25-byte subframes, each subframe
carrying 193 bits of TDM data and 7 bits of padding. This mode is
depicted in Figure 4 below.
| 1 | 2 | ... | 25 |
|0 1 2 3 4 5 6 7|0 1 2 3 4 5 6 7| ... |0 1 2 3 4 5 6 7|
|=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
| TDM Data | padding |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ................................. |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TDM Data | padding |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
Figure 4. SAToP Payload Format for Octet-Aligned T1 Transport
Notes:
1. No alignment with the framing structure that may be imposed on the
T1 bit-stream is implied.
2. An additional advantage of the octet-aligned T1 transport mode is
the ability to select the SAToP packetization latency as an
arbitrary integer multiple of 125 microseconds.
Support of the octet-aligned T1 transport mode is OPTIONAL. An
octet-aligned T1 SAToP PW is not interoperable with a T1 SAToP PW
that carries a non-aligned bit-stream, as described in the previous
section.
Implementations supporting octet-aligned T1 transport mode MUST be
capable of supporting a payload size of 200 bytes (i.e., a payload of
eight 25-byte subframes) corresponding to precisely 1 millisecond of
TDM data.
6. SAToP Operation
6.1. Common Considerations
Edge-to-edge emulation of a TDM service using SAToP is only possible
when the two PW attachment circuits are of the same type (T1, E1, T3,
E3). The service type is exchanged at PW setup as described in
[RFC4447].
6.2. IWF Operation
6.2.1. PSN-Bound Direction
Once the PW is set up, the PSN-bound SAToP IWF operates as follows:
TDM data is packetized using the configured number of payload bytes
per packet.
Sequence numbers, flags, and timestamps (if the RTP header is used)
are inserted in the SAToP headers.
SAToP, PW demultiplexing layer, and PSN headers are prepended to the
packetized service data.
The resulting packets are transmitted over the PSN.
6.2.2. CE-Bound Direction
The CE-bound SAToP IWF SHOULD include a jitter buffer where the
payload of the received SAToP packets is stored prior to play-out to
the local TDM attachment circuit. The size of this buffer SHOULD be
locally configurable to allow accommodation to the PSN-specific
packet delay variation.
The CE-bound SAToP IWF SHOULD use the sequence number in the control
word for detection of lost and misordered packets. If the RTP header
is used, the RTP sequence numbers MAY be used for the same purposes.
Note: With SAToP, a valid sequence number can be always found in bits
16 - 31 of the first 32-bit word immediately following the PW
demultiplexing header regardless of the specific PSN type,
multiplexing method, usage or non-usage of the RTP header, etc. This
approach simplifies implementations supporting multiple encapsulation
types as well as implementation of multi-segment (MS) PWs using
different encapsulation types in different segments.
The CE-bound SAToP IWF MAY reorder misordered packets. Misordered
packets that cannot be reordered MUST be discarded and treated as
lost.
The payload of the received SAToP packets marked with the L bit set
SHOULD be replaced by the equivalent amount of the "all ones" pattern
even if it has not been omitted.
The payload of each lost SAToP packet MUST be replaced with the
equivalent amount of the replacement data. The contents of the
replacement data are implementation-specific and MAY be locally
configurable. By default, all SAToP implementations MUST support
generation of the "all ones" pattern as the replacement data. Before
a PW has been set up and after a PW has been torn down, the IWF MUST
play out the "all ones" pattern to its TDM attachment circuit.
Once the PW has been set up, the CE-bound IWF begins to receive SAToP
packets and to store their payload in the jitter buffer but continues
to play out the "all ones" pattern to its TDM attachment circuit.
This intermediate state persists until a preconfigured amount of TDM
data (usually half of the jitter buffer) has been received in
consecutive SAToP packets or until a preconfigured intermediate state
timer (started when the PW setup is completed) expires.
Once the preconfigured amount of the TDM data has been received, the
CE-bound SAToP IWF enters its normal operation state where it
continues to receive SAToP packets and to store their payload in the
jitter buffer while playing out the contents of the jitter buffer in
accordance with the required clock. In this state, the CE-bound IWF
performs clock recovery, MAY monitor PW defects, and MAY collect PW
performance monitoring data.
If the CE-bound SAToP IWF detects loss of a preconfigured number of
consecutive packets or if the intermediate state timer expires before
the required amount of TDM data has been received, it enters its
packet loss state. While in this state, the local PSN-bound SAToP
IWF SHOULD mark every packet it transmits with the R bit set. The
CE-bound SAToP IWF leaves this state and transitions to the normal
one once a preconfigured number of consecutive valid SAToP packets
have been received. (Successfully reordered packets contribute to
the count of consecutive packets.)
The CE-bound SAToP IWF MUST provide an indication of TDM data
validity to the CE. This can be done by transporting or by
generating the native AIS indication. As mentioned above, T3 AIS
cannot be detected or generated by structure-agnostic means, and
hence a structure-aware NSP MUST be used when generating a valid AIS
pattern.
6.3. SAToP Defects
In addition to the packet loss state of the CE-bound SAToP IWF
defined above, it MAY detect the following defects:
o Stray packets
o Malformed packets
o Excessive packet loss rate
o Buffer overrun
o Remote packet loss
Corresponding to each defect is a defect state of the IWF, a
detection criterion that triggers transition from the normal
operation state to the appropriate defect state, and an alarm that
MAY be reported to the management system and thereafter cleared.
Alarms are only reported when the defect state persists for a
preconfigured amount of time (typically 2.5 seconds) and MUST be
cleared after the corresponding defect is undetected for a second
preconfigured amount of time (typically 10 seconds). The trigger and
release times for the various alarms may be independent.
Stray packets MAY be detected by the PSN and PW demultiplexing
layers. When RTP is used, the SSRC field in the RTP header MAY be
used for this purpose as well. Stray packets MUST be discarded by
the CE-bound IWF, and their detection MUST NOT affect mechanisms for
detection of packet loss.
Malformed packets are detected by mismatch between the expected
packet size (taking the value of the L bit into account) and the
actual packet size inferred from the PSN and PW demultiplexing
layers. When RTP is used, lack of correspondence between the PT
value and that allocated for this direction of the PW MAY also be
used for this purpose. Malformed in-order packets MUST be discarded
by the CE-bound IWF and replacement data generated as with lost
packets.
Excessive packet loss rate is detected by computing the average
packet loss rate over a configurable amount of times and comparing it
with a preconfigured threshold.
Buffer overrun is detected in the normal operation state when the
jitter buffer of the CE-bound IWF cannot accommodate newly arrived
SAToP packets.
Remote packet loss is indicated by reception of packets with their R
bit set.
6.4. SAToP PW Performance Monitoring
Performance monitoring (PM) parameters are routinely collected for
TDM services and provide an important maintenance mechanism in TDM
networks. The ability to collect compatible PM parameters for SAToP
PWs enhances their maintenance capabilities.
Collection of the SAToP PW performance monitoring parameters is
OPTIONAL and, if implemented, is only performed after the CE-bound
IWF has exited its intermediate state.
SAToP defines error events, errored blocks, and defects as follows:
o A SAToP error event is defined as insertion of a single
replacement packet into the jitter buffer (replacement of
payload of SAToP packets with the L bit set is not considered
insertion of a replacement packet).
o A SAToP errored data block is defined as a block of data played
out to the TDM attachment circuit and of a size defined in
accordance with the [G.826] rules for the corresponding TDM
service that has experienced at least one SAToP error event.
o A SAToP defect is defined as the packet loss state of the
CE-bound SAToP IWF.
The SAToP PW PM parameters (Errored, Severely Errored, and
Unavailable Seconds) are derived from these definitions in accordance
with [G.826].
7. Quality of Service (QoS) Issues
SAToP SHOULD employ existing QoS capabilities of the underlying PSN.
If the PSN providing connectivity between PE devices is Diffserv-
enabled and provides a PDB [RFC3086] that guarantees low jitter and
low loss, the SAToP PW SHOULD use this PDB in compliance with the
admission and allocation rules the PSN has put in place for that PDB
(e.g., marking packets as directed by the PSN).
If the PSN is Intserv-enabled, then GS (Guaranteed Service) [RFC2212]
with the appropriate bandwidth reservation SHOULD be used in order to
provide a bandwidth guarantee equal or greater than that of the
aggregate TDM traffic.
8. Congestion Control
As explained in [RFC3985], the PSN carrying the PW may be subject to
congestion. SAToP PWs represent inelastic constant bit-rate (CBR)
flows and cannot respond to congestion in a TCP-friendly manner
prescribed by [RFC2914], although the percentage of total bandwidth
they consume remains constant.
Unless appropriate precautions are taken, undiminished demand of
bandwidth by SAToP PWs can contribute to network congestion that may
impact network control protocols.
Whenever possible, SAToP PWs SHOULD be carried across traffic-
engineered PSNs that provide either bandwidth reservation and
admission control or forwarding prioritization and boundary traffic
conditioning mechanisms. IntServ-enabled domains supporting
Guaranteed Service (GS) [RFC2212] and DiffServ-enabled domains
[RFC2475] supporting Expedited Forwarding (EF) [RFC3246] provide
examples of such PSNs. Such mechanisms will negate, to some degree,
the effect of the SAToP PWs on the neighboring streams. In order to
facilitate boundary traffic conditioning of SAToP traffic over IP
PSNs, the SAToP IP packets SHOULD NOT use the DiffServ Code Point
(DSCP) value reserved for the Default Per-Hop Behavior (PHB)
[RFC2474].
If SAToP PWs run over a PSN providing best-effort service, they
SHOULD monitor packet loss in order to detect "severe congestion".
If such a condition is detected, a SAToP PW SHOULD shut down bi-
directionally for some period of time as described in Section 6.5 of
[RFC3985].
Note that:
1. The SAToP IWF can inherently provide packet loss measurement since
the expected rate of arrival of SAToP packets is fixed and known
2. The results of the SAToP packet loss measurement may not be a
reliable indication of presence or absence of severe congestion if
the PSN provides enhanced delivery. For example:
a) If SAToP traffic takes precedence over non-SAToP traffic,
severe congestion can develop without significant SAToP packet
loss.
b) If non-SAToP traffic takes precedence over SAToP traffic, SAToP
may experience substantial packet loss due to a short-term
burst of high-priority traffic.
3. The TDM services emulated by the SAToP PWs have high availability
objectives (see [G.826]) that MUST be taken into account when
deciding on temporary shutdown of SAToP PWs.
This specification does not define the exact criteria for detecting
"severe congestion" using the SAToP packet loss rate or the specific
methods for bi-directional shutdown the SAToP PWs (when such severe
congestion has been detected) and their subsequent re-start after a
suitable delay. This is left for further study. However, the
following considerations may be used as guidelines for implementing
the SAToP severe congestion shutdown mechanism:
1. SAToP Performance Monitoring techniques (see Section 6.4) provide
entry and exit criteria for the SAToP PW "Unavailable" state that
make it closely correlated with the "Unavailable" state of the
emulated TDM circuit as specified in [G.826]. Using the same
criteria for "severe congestion" detection may decrease the risk
of shutting down the SAToP PW while the emulated TDM circuit is
still considered available by the CE.
2. If the SAToP PW has been set up using either PWE3 control protocol
[RFC4447] or L2TPv3 [RFC3931], the regular PW teardown procedures
of these protocols SHOULD be used.
3. If one of the SAToP PW end points stops transmission of packets
for a sufficiently long period, its peer (observing 100% packet
loss) will necessarily detect "severe congestion" and also stop
transmission, thus achieving bi-directional PW shutdown.
9. Security Considerations
SAToP does not enhance or detract from the security performance of
the underlying PSN; rather, it relies upon the PSN mechanisms for
encryption, integrity, and authentication whenever required.
SAToP PWs share susceptibility to a number of pseudowire-layer
attacks and will use whatever mechanisms for confidentiality,
integrity, and authentication are developed for general PWs. These
methods are beyond the scope of this document.
Although SAToP PWs MAY employ an RTP header when explicit transfer of
timing information is required, SRTP (see [RFC3711]) mechanisms are
NOT RECOMMENDED as a substitute for PW layer security.
Misconnection detection capabilities of SAToP increase its resilience
to misconfiguration and some types of denial-of-service (DoS)
attacks.
Random initialization of sequence numbers, in both the control word
and the optional RTP header, makes known-plaintext attacks on
encrypted SAToP PWs more difficult. Encryption of PWs is beyond the
scope of this document.
10. Applicability Statement
SAToP is an encapsulation layer intended for carrying TDM circuits
(E1/T1/E3/T3) over PSN in a structure-agnostic fashion.
SAToP fully complies with the principle of minimal intervention, thus
minimizing overhead and computational power required for
encapsulation.
SAToP provides sequencing and synchronization functions needed for
emulation of TDM bit-streams, including detection of lost or
misordered packets and appropriate compensation.
TDM bit-streams carried over SAToP PWs may experience delays
exceeding those typical of native TDM networks. These delays include
the SAToP packetization delay, edge-to-edge delay of the underlying
PSN, and the delay added by the jitter buffer. It is recommended to
estimate both delay and delay variation prior to setup of a SAToP PW.
SAToP carries TDM streams over PSN in their entirety, including any
TDM signaling contained within the data. Consequently, the emulated
TDM services are sensitive to the PSN packet loss. Appropriate
generation of replacement data can be used to prevent shutting down
the CE TDM interface due to occasional packet loss. Other effects of
packet loss on this interface (e.g., errored blocks) cannot be
prevented.
Note: Structure-aware TDM emulation (see [CESoPSN] or [TDMoIP])
completely hides effects of the PSN packet loss on the CE TDM
interface (because framing and Cyclic Redundancy Checks (CRCs) are
generated locally) and allows usage of application-specific packet
loss concealment methods to minimize effects on the applications
using the emulated TDM service.
SAToP can be used in conjunction with various network synchronization
scenarios (see [RFC4197]) and clock recovery techniques. The quality
of the TDM clock recovered by the SAToP IWF may be implementation-
specific. The quality may be improved by using RTP if a common clock
is available at both ends of the SAToP PW.
SAToP provides for effective fault isolation by carrying the local
attachment circuit failure indications.
The option not to carry invalid TDM data enables PSN bandwidth
conservation.
SAToP allows collection of TDM-like faults and performance monitoring
parameters and hence emulates ’classic’ carrier services of TDM.
SAToP provides for a carrier-independent ability to detect
misconnections and malformed packets. This feature increases
resilience of the emulated service to misconfiguration and DoS
attacks.
Being a constant bit rate (CBR) service, SAToP cannot provide TCP-
friendly behavior under network congestion.
Faithfulness of a SAToP PW may be increased by exploiting QoS
features of the underlying PSN.
SAToP does not provide any mechanisms for protection against PSN
outages, and hence its resilience to such outages is limited.
However, lost-packet replacement and packet reordering mechanisms
increase resilience of the emulated service to fast PSN rerouting
events.
11. IANA Considerations
Allocation of PW Types for the corresponding SAToP PWs is defined in
[RFC4446].
12. Acknowledgements
We acknowledge the work of Gil Biran and Hugo Silberman who
implemented TDM transport over IP in 1998.
We would like to thank Alik Shimelmits for many productive
discussions and Ron Insler for his assistance in deploying TDM over
PSN.
We express deep gratitude to Stephen Casner who has reviewed in
detail one of the predecessors of this document and provided valuable
feedback regarding various aspects of RTP usage, and to Kathleen
Nichols who has provided the current text of the QoS section
considering Diffserv-enabled PSN.
We thank William Bartholomay, Robert Biksner, Stewart Bryant, Rao
Cherukuri, Ron Cohen, Alex Conta, Shahram Davari, Tom Johnson, Sim
Narasimha, Yaron Raz, and Maximilian Riegel for their valuable
feedback.
13. Co-Authors
The following are co-authors of this document:
Motty Anavi RAD Data Communications
Tim Frost Zarlink Semiconductors
Eduard Metz TNO Telecom
Prayson Pate Overture Networks
Akiva Sadovski
Israel Sasson Axerra Networks
Ronen Shashoua RAD Data Communications
14. Normative References
[G.702] ITU-T Recommendation G.702 (11/88) - Digital Hierarchy
Bit Rates.
[G.703] ITU-T Recommendation G.703 (10/98) -
Physical/Electrical Characteristics of Hierarchical
Digital Interfaces.
[G.704] ITU-T Recommendation G.704 (10/98) - Synchronous frame
structures used at 1544, 6312, 2048, 8448 and 44 736
Kbit/s hierarchical levels.
[G.707] ITU-T Recommendation G.707 (03/96) - Network Node
Interface for the Synchronous Digital Hierarchy (SDH).
[G.775] ITU-T Recommendation G.775 (10/98) - Loss of Signal
(LOS), Alarm Indication Signal (AIS) and Remote Defect
Indication (RDI) Defect Detection and Clearance