[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02 03 04 05 RFC 4553

    Network Working Group               A. Vainshtein (Axerra Networks)
                                   Y(J) Stein (RAD Data Communications)
    Internet Draft                                              Editors

    Expiration Date:
    March 2006

                                                         September 2005

               Structure-Agnostic TDM over Packet (SAToP)

                      draft-ietf-pwe3-satop-03.txt

Status of this Memo

By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware have
been or will be disclosed, and any of which he or she becomes aware
will be disclosed, in accordance with Section 6 of BCP 79.

Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups.  Note that other
groups may also distribute working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time.  It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

Abstract

This document describes a pseudowire encapsulation for TDM (T1, E1, T3,
E3) bit-streams that disregards any structure that may be imposed on
these streams, in particular the structure imposed by the standard TDM
framing.

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


   Vainshtein & Stein        Standards Track                   [Page 1]

   Structure-Agnostic TDM over Packet                  September 2005


TABLE OF CONTENTS

1. Introduction......................................................2
2. Terminology and Reference Models..................................3
  2.1. Terminology...................................................3
  2.2. Reference Models..............................................3
3. Emulated Services.................................................4
4. SAToP Encapsulation Layer.........................................4
  4.1. SAToP Packet Format...........................................4
  4.2. PSN and Multiplexing Layer Headers............................5
  4.3. SAToP Header..................................................5
    4.3.1. Usage and Structure of the Control Word...................7
    4.3.2. Usage of RTP Header.......................................8
5. SAToP Payload Layer...............................................9
  5.1. General Payloads..............................................9
  5.2. Octet-aligned T1.............................................10
6. SAToP Operation..................................................11
  6.1. Common Considerations........................................11
  6.2. IWF operation................................................11
    6.2.1. PSN-bound Direction......................................11
    6.2.2. CE-bound Direction.......................................11
  6.3. SAToP Defects................................................12
  6.4. SAToP PW Performance Monitoring..............................13
7. QoS Issues.......................................................14
8. Congestion Control...............................................14
9. Security Considerations..........................................14
10. Applicability Statement.........................................14
11. IANA Considerations.............................................16
12. Disclaimer of Validity..........................................16
13. NORMATIVE REFERENCES............................................16
14. INFORMATIONAL REFERENCES........................................18
Annex A. Old Mode of SATOP Encapsulation over L2TPv3................18


1. Introduction

This document describes a method for encapsulating TDM bit-streams (T1,
E1, T3, E3) as pseudo-wires over packet-switching networks (PSN). It
addresses only structure-agnostic transport, i.e., the protocol
completely disregards any structure that may possibly be imposed on
these signals, in particular the structure imposed by standard TDM
framing [G.704]. This emulation is referred to as "emulation of
unstructured TDM circuits" in [PWE3-TDM-REQ] and suits applications
where the PEs have no need to interpret TDM data or to participate in
the TDM signaling.

The SAToP solution presented in this document conforms to the PWE3
architecture described in [PWE3-ARCH] and satisfies both the relevant
general requirements put forward in [PWE3-REQ] and specific
requirements for unstructured TDM signals presented in [PWE3-TDM-REQ].



   Vainshtein & Stein        Expires   March 2006              [Page 2]

   Structure-Agnostic TDM over Packet                  September 2005

As for all PWs, SAToP PWs may be manually configured or setup using the
PWE3 control protocol. Extensions to the PWE3 control protocol required
for setup and maintenance of SAToP pseudo-wires and allocations of code
points used for this purpose are described in separate documents
([PWE3-TDM-CONTROL] and [PWE3-IANA] respectively).

2. Terminology and Reference Models

   2.1. Terminology

"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",    "SHOULD",
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are
to be interpreted as described in [RFC2119].

The following acronyms used in this document are defined in [PWE3-ARCH]
and [PWE3-TDM-REQ]:

ATM          Asynchronous Transfer Mode
CE           Customer Edge
CES          Circuit Emulation Service
NSP          Native Service Processing
PE           Provider Edge
PDH          Plesiochronous Digital Hierarchy
PW           Pseudo-Wire
SDH          Synchronous Digital Hierarchy
SONET        Synchronous Optical Network
TDM          Time Domain Multiplexing

In addition, the following TDM-specific terms are needed:

     o  Loss of Signal (LOS) - a condition of the TDM attachment
         circuit wherein the incoming signal cannot be detected.
         Criteria for entering and leaving the LOS condition can be
         found in [G.775]
     o  Alarm Indication Signal (AIS) - a special bit pattern (e.g. as
         described in [G.775]) in the TDM bit stream that indicates
         presence of an upstream circuit outage. For E1, T1 and E3
         circuits the AIS pattern is a sequence of binary "1" values of
         appropriate duration (the "all ones" pattern) and hence it can
         be detected and generated by structure-agnostic means. The T3
         AIS pattern requires T3 framing (see [G.704], Section
         2.5.3.6.1) and hence can only be handled by a structure-aware
         NSP.

We also use the term Interworking Function (IWF) to describe the
functional block that segments and encapsulates TDM into SAToP packets
and in the reverse direction decapsulates SAToP packets and
reconstitutes TDM.

   2.2. Reference Models

The generic models defined in Sections 4.1, 4.2 and 4.4 of [PWE3-ARCH]
fully apply to SAToP.

   Vainshtein & Stein        Expires   March 2006              [Page 3]

   Structure-Agnostic TDM over Packet                  September 2005


The native service addressed in this document is a special case of the
bit stream payload type defined in Section 3.3.3 of [PWE3-ARCH].


The Network Synchronization reference model and deployment scenarios
for emulation of TDM services are described in [PWE3-TDM-REQ], Section
4.2.

3. Emulated Services

This specification describes edge-to-edge emulation of the following
TDM services described in [G.702]:

     1. E1 (2048 kbit/s)
     2. T1 (1544 kbit/s) This service is also known as DS1
     3. E3 (34368 kbit/s)
     4. T3 (44736 kbit/s) This service is also known as DS3.

The protocol used for emulation of these services does not depend on
the method in which attachment circuits are delivered to the PEs. For
example, a T1 attachment circuit is treated in the same way regardless
of whether it is delivered to the PE on copper [G.703], multiplexed in
a T3 circuit [T.107], mapped into a virtual tributary of a SONET/SDH
circuit [G.707] or carried over an ATM network using unstructured ATM
Circuit Emulation Service (CES) [ATM-CES]. Termination of any specific
"carrier layers" used between the PE and CE is performed by an
appropriate NSP.

4. SAToP Encapsulation Layer
   4.1. SAToP Packet Format

The basic format of SAToP packets is shown in Fig. 1 below.

   Vainshtein & Stein        Expires   March 2006              [Page 4]

   Structure-Agnostic TDM over Packet                  September 2005


 0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ...                                 |
|              PSN and multiplexing layer headers               |
|                           ...                                 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                         ...                                   |
+--                                                           --+
|                   SAToP Encapsulation Header                  |
+--                                                           --+
|                         ...                                   |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+

|                   Packetized TDM data (Payload)               |
|                            ...                                |
|                            ...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

           Figure 1. Basic SAToP Packet Format

   4.2. PSN and Multiplexing Layer Headers

Both UDP and L2TPv3 can provide the multiplexing mechanisms for SAToP
PWs over an IPv4/IPv6 PSN. The PW label provides the multiplexing
mechanism over an MPLS PSN as described in Section 5.4.2 of [PWE3-
ARCH].

The total size of a SAToP packet for a specific PW MUST NOT exceed path
MTU between the pair of PEs terminating this PW. SAToP implementations
using IPv4 PSN MUST mark the IPv4 datagrams they generate as "Don't
Fragment" [RFC791].


   4.3. SAToP Header

The SAToP header MUST contain the SAToP Control Word (4 bytes) and MAY
also contain a fixed RTP header [RFC3550]. If the RTP header is
included in the SAToP header, it MUST immediately follow the SAToP
control word in all cases except UDP demultiplexing, where it
MUST precede it (see Fig. 2a,  Fig. 2b and Fig. 2c below).

Note: Such an arrangement complies with the traditional usage of RTP
for the IPv4/IPv6 PSN with UDP demultiplexing while making SAToP PWs
ECMP-safe for the MPLS PSN by providing for PW-IP packet
discrimination(see [PWE3-ARCH], Section 5.4.3) and facilitating
smoothless stitching of L2TPv3-based and MPLS-based segments of SAToP
PWs (see [PWE3-MS]).

























   Vainshtein & Stein        Expires   March 2006              [Page 5]

   Structure-Agnostic TDM over Packet                  September 2005

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ...                                 |
|          IPv4/IPv6 and UDP (demultiplexing layer) headers     |
|                           ...                                 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                       OPTIONAL                                |
+--                                                           --+
|                                                               |
+--                                                           --+
|                 Fixed RTP Header (see [RFC3550])              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                  SAToP Control Word                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                   Packetized TDM data (Payload)               |
|                            ...                                |
|                            ...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 2a. SAToP Packet Format for an IPv4/IPv6 PSN with
                UDP DeMultiplexing


0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ...                                 |
|         IPv4/IPv6 and L2TPv3 (demultiplexing layer) headers   |
|                           ...                                 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                  SAToP Control Word                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                       OPTIONAL                                |
+--                                                           --+
|                                                               |
+--                                                           --+
|                 Fixed RTP Header (see [RFC3550])              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                   Packetized TDM data (Payload)               |
|                            ...                                |
|                            ...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

     Figure 2b. SAToP Packet Format for an IPv4/IPv6 PSN with
                L2TPv3 DeMultiplexing








   Vainshtein & Stein        Expires   March 2006              [Page 6]

   Structure-Agnostic TDM over Packet                  September 2005

0               1               2               3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           ...                                 |
|              MPLS Label Stack                                 |
|                           ...                                 |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                  SAToP Control Word                           |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                       OPTIONAL                                |
+--                                                           --+
|                                                               |
+--                                                           --+
|                 Fixed RTP Header (see [RFC3550])              |
+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
|                   Packetized TDM data (Payload)               |
|                            ...                                |
|                            ...                                |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  Figure 2c. SAToP Packet Format for an MPLS PSN


     4.3.1. Usage and Structure of the Control Word

Usage of the SAToP control word allows:

     1. Detection of packet loss or mis-ordering
     2. Differentiation between the PSN and attachment circuit
         problems as causes for the outage of the emulated service
     3. PSN bandwidth conservation by not transferring invalid data
         (AIS)
     4. Signaling of faults detected at the PW egress to the PW
         ingress.

The structure of the SAToP Control Word is shown in Fig. 3 below.

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|0|0|0|L|R|RSV|FRG|   LEN     |       Sequence number         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 3. Structure of the SAToP Control Word

Bits 0 to 3 MUST be set to 0 as described in [PWE3-ARCH], Section 5.4.4

L - if set, indicates that TDM data carried in the payload is invalid
    due an attachment circuit fault.  When the L bit is set the payload
    MAY be omitted in order to conserve bandwidth. The CE-bound IWF
    MUST play out an appropriate amount of filler data regardless of
    the payload size. Once set, if the fault is rectified the L bit
    MUST be cleared.

   Vainshtein & Stein        Expires   March 2006              [Page 7]

   Structure-Agnostic TDM over Packet                  September 2005


Note: This document does not specify which TDM fault conditions are
treated as invalidating the data carried in the SAToP packets. Possible
examples include, but are not limited to LOS and AIS.

R - if set by the PSN-bound IWF, indicates that its local CE-bound IWF
    is in the packet loss state, i.e. has lost a preconfigured number
    of consecutive packets. The R bit MUST be cleared by the PSN-bound
    IWF once its local CE-bound IWF has exited the packet loss state,
    i.e. has received a preconfigured number of consecutive packets.

RSV (reserved) and FRG (fragmentation) bits (6 to 10) - MUST be set to
0 by the PSN-bound IWF and MUST be ignored by the CE-bound IWF.

LEN (bits (10 to 15) MAY be used to carry the length of the SAToP
packet (defined as the size of the SAToP header + the payload size) if
it is less than 64 bytes, and MUST be set to zero otherwise. When the
LEN field is set to 0, the preconfigured size of the SAToP packet
payload MUST be assumed, and if the actual packet size is inconsistent
with this length, the packet MUST be considered to be malformed.

Sequence number provides the common PW sequencing function and allows
detection of lost packets. It MUST be generated in accordance with the
rules defined in [RFC3550], Section 5 for the RTP sequence number.

VCCV packets (see [PWE3-VCCV]) in SAToP PWs MUST be discriminated by
setting the first nibble of the control word to '0001' regardless of
the PSN type and demultiplexing layer.

     4.3.2. Usage of RTP Header

When RTP is used, SAToP requires the fields of the fixed RTP header
(see [RFC3550], Section 5.1) with P (padding), X (header extension), CC
(CSRC count), and M fields (marker) to be set to zero.

The PT (payload type) field is used as following:
     1. One PT value MUST be allocated from the range of dynamic
         values (see [RTP-TYPES]) for each direction of the PW. The
         same PT value MAY be reused for both directions of the PW and
         also reused between different PWs
     2. The PSN-bound IWF MUST set the PT field in the RTP header to
         the allocated value
     3. The CE-bound IWF MAY use the received value to detect
         malformed packets

The sequence number field MAY be used to provide the common PW
sequencing function as well as detection of lost packets. It MUST be
generated in accordance with the rules established in [RFC3550] and
MUST be the same as the sequence number in the SAToP control word.

Timestamps are used for carrying timing information over the network.
Their values are generated in accordance with the rules established in
[RFC3550].

   Vainshtein & Stein        Expires   March 2006              [Page 8]

   Structure-Agnostic TDM over Packet                  September 2005


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.

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 time-stamping clock frequency, the time-
stamping mode, selected PT and SSRC values) MUST be agreed upon between
the two SAToP IWFs at the PW setup as described in [PWE3-TDM-CONTROL].
Other, RTP-specific, methods (e.g., see [RFC 3551]) 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
at the 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 ([PWE3-TDM-
CONTROL]) by using the CEP/TDM Payload Bytes sub-TLV of the Interface
Parameters TLV([PWE3-IANA]).

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

   Vainshtein & Stein        Expires   March 2006              [Page 9]

   Structure-Agnostic TDM over Packet                  September 2005

     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 deframed by a dual-mode E1/T1
framer.

In order to facilitate operation in such cases, SAToP defines a special
"octet-aligned T1" transport mode. When operating 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 Fig. 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
    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


   Vainshtein & Stein        Expires   March 2006             [Page 10]

   Structure-Agnostic TDM over Packet                  September 2005

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 [PWE3-
CONTROL].


   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, multiplexing 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 mis-ordered packets. If the RTP header
is used, the RTP sequence numbers MAY be used for the same purposes.

The CE-bound SAToP IWF MAY re-order mis-ordered packets. Mis-ordered
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


   Vainshtein & Stein        Expires   March 2006             [Page 11]

   Structure-Agnostic TDM over Packet                  September 2005

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 transits to the normal one once a
preconfigured number of consecutive valid SAToP packets have been
received. (Successfully re-ordered 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

   Vainshtein & Stein        Expires   March 2006             [Page 12]

   Structure-Agnostic TDM over Packet                  September 2005

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 multiplexing 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 multiplexing layers. When RTP is used,
lack of correspondence between the PT value and that allocated for this
direction of the PW MAT also be used for this purpose. Malformed in-
order packets MUST be discarded by the CE-bound IWF and replacement
data generated as for 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 CE
bound IWF's jitter buffer 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. 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
         as 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 size defined
         in accordance with the [G.826] rules for the corresponding TDM
         service that has experienced at least one SAToP error event

   Vainshtein & Stein        Expires   March 2006             [Page 13]

   Structure-Agnostic TDM over Packet                  September 2005

     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. QoS Issues

SAToP SHOULD exploit 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) [RFC 2212]
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

SAToP PWs represent a special case of PWs carrying constant bit rate
(CBR) services across the PSN. These services cannot behave in a TCP-
friendly manner prescribed by [RFC2914] under congestion.

SAToP will use the generic PWE3 approach for handling congestion in PWs
carrying CBR services when such an approach has been specified.


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.

Misconnection detection capabilities of SAToP increase its resilience
to misconfiguration and some types of DoS attacks.

Random initialization of sequence numbers defined in [RFC3550] makes
known-plaintext attacks on encryption more difficult.

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.




   Vainshtein & Stein        Expires   March 2006             [Page 14]

   Structure-Agnostic TDM over Packet                  September 2005

SAToP provides sequencing and synchronization functions needed for
emulation of TDM bit-streams, including detection of lost or mis-
ordered 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 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 [PWE3-RDM-REQ)] and clock recovery techniques. The
quality of the TDM clock recovered by the SAToP IWF may be
implementation-specific. If a common. 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 hence emulating '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.


   Vainshtein & Stein        Expires   March 2006             [Page 15]

   Structure-Agnostic TDM over Packet                  September 2005

11. IANA Considerations

Allocation of PW Types for the corresponding SAToP PWs is defined in
[PWE3-IANA].

12. Disclaimer of Validity

The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights.  Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard.  Please address the information to the
IETF at ietf-ipr@ietf.org.

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. NORMATIVE REFERENCES

[RFC791] J. Postel (ed), Internet Protocol, RFC 791, IETF, 1981


   Vainshtein & Stein        Expires   March 2006             [Page 16]

   Structure-Agnostic TDM over Packet                  September 2005

[RFC1122] R. Braden (ed.), Requirements for Internet Hosts --
Communication Layers, RFC 1122, IETF, 1989

[RFC2119] S.Bradner, Key Words in RFCs to Indicate Requirement Levels,
RFC 2119, IETF, 1997

[RFC2112] S. Shenker et al, Specification of Guaranteed Quality of
Service, IETF, RFC 2212, 1997

[RFC2914] S. Floyd, Congestion Control Principles, RFC 2914, IETF, 2000

[RFC3086] K. Nichols, B. Carpenter, Definition of Differentiated
Services Per Domain Behaviors and Rules for their Specification, RFC
3086, IETF, 2001

[RFC3550] H. Schulzrinne et al, RTP: A Transport Protocol for Real-Time
Applications, RFC 3550, IETF, 2003

[RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp-
parameters

[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.751] 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

[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 Criteria for PDH Signals

[G.802] ITU-T Recommendation G.802 (11/88) - Interworking between
Networks Based on Different Digital Hierarchies and Speech Encoding
Laws

[G.826] ITU-T Recommendation G.826 (02/99) - Error performance
parameters and objectives for international, constant bit rate digital
paths at or above the primary rate

[T1.107] American National Standard for Telecommunications - Digital
Hierarchy - Format Specifications, ANSI T1.107-1988

   Vainshtein & Stein        Expires   March 2006             [Page 17]

   Structure-Agnostic TDM over Packet                  September 2005


14. INFORMATIONAL REFERENCES

[PWE3-REQ] XiPeng Xiao et al, Requirements for Pseudo Wire Emulation
Edge-to-Edge (PWE3), IETF RFC 3916, 2004

[PWE3-TDM-REQ] Maximilian Riegel, Requirements for Edge-to-Edge
Emulation of TDM Circuits over Packet Switching Networks (PSN), Work in
Progress, April 2005, draft-ietf-pwe3-tdm-requirements-08.txt

[PWE3-ARCH] S. Bryant, P. Pate, PWE3 Architecture, IETF RFC 3985, 2005

[PWE3-CONTROL] L. Martini et al, Pseudowire Setup and Maintenance using
LDP, Work in progress, June 2005, draft-ietf-pwe3-control-protocol-
17.txt

[PWE3-IANA] L. Martini, M. Townsley, IANA Allocations for pseudo Wire
Edge to Edge Emulation (PWE3), Work in progress, September 2005, draft-
ietf-pwe3-iana-allocation-12.txt

[ATM-CES] ATM forum specification af-vtoa-0078 (CES 2.0)
Circuit Emulation Service Interoperability Specification Ver. 2.0

[CESoPSN] A.Vainshtein et al, TDM Circuit Emulation Service over Packet
Switched Network (CESoPSN), Work in Progress, July 2005, draft-ietf-
pwe3-cesopsn-03.txt

[TDMoIP] Y. Stein, TDMoIP, Work in Progress, February 2005, draft-ietf-
pwe3-tdmoip-03.txt

[PWE3-TDM-CONTROL] A. Vainshtein, Y. Stein, Control Protocol Extensions
for Setup of TDM Pseudowires, Work in Progress, July 2005, draft-ietf-
pwe3-tdm-control-protocol-extensi-00.txt


[PWE3-MS] L. Martini et al, Segmented Pseudo Wire, Work in Progress,
July 2005, draft-ietf-pwe3-segmented-pw-00.txt


[PWE3-VCCV] T. Nadeau, R. Aggarwal, Pseudo Wire Virtual Circuit
Connectivity, Work in Progress, August 2005, draft-ietf-pwe3-vccv-
05.txt


[RFC3551] H. Schulzrinne, S. Casner, RTP Profile for Audio and Video
Conferences with Minimal Control, RFC 3551, IETF, 2003



ANNEX A. OLD MODE OF SATOP ENCAPSULATION OVER L2TPV3

Previous versions of this specification defined a SAToP PW
encapsulation over L2TPv3 which differs from one described in Section

   Vainshtein & Stein        Expires   March 2006             [Page 18]

   Structure-Agnostic TDM over Packet                  September 2005

4.3 and Diagram 2b. In these versions the RTP header, if used, precedes
the SAToP control word.

Existing implementations of the old encapsulation mode MUST be
distinguished from the encapsulations conforming to this specification
via the SAToP PW setup.

Full Copyright Statement

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.

This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

Funding for the RFC Editor function is currently provided by the
Internet Society.

Editors' Addresses

Alexander ("Sasha") Vainshtein
Axerra Networks
24 Raoul Wallenberg St.,
Tel Aviv 69719, Israel
email: sasha@axerra.com

Yaakov (Jonathan) Stein
RAD Data Communications
24 Raoul Wallenberg St., Bldg C
Tel Aviv 69719, Israel
Email: yaakov_s@rad.com



   Vainshtein & Stein        Expires   March 2006             [Page 19]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/