tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 5087

 
 
 

Time Division Multiplexing over IP (TDMoIP)

Part 2 of 2, p. 24 to 50
Prev RFC Part

 


prevText      Top      Up      ToC       Page 24 
7.  Implementation Issues

   General requirements for transport of TDM over pseudo-wires are
   detailed in [RFC4197].  In the following subsections we review
   additional aspects essential to successful TDMoIP implementation.

7.1.  Jitter and Packet Loss

   In order to compensate for packet delay variation that exists in any
   PSN, a jitter buffer MUST be provided.  A jitter buffer is a block of
   memory into which the data from the PSN is written at its variable
   arrival rate, and data is read out and sent to the destination TDM
   equipment at a constant rate.  Use of a jitter buffer partially hides
   the fact that a PSN has been traversed rather than a conventional
   synchronous TDM network, except for the additional latency.
   Customary practice is to operate with the jitter buffer approximately
   half full, thus minimizing the probability of its overflow or
   underflow.  Hence, the additional delay equals half the jitter buffer
   size.  The length of the jitter buffer SHOULD be configurable and MAY
   be dynamic (i.e., grow and shrink in length according to the
   statistics of the Packet Delay Variation (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 arriving packets and MUST take
   appropriate action when anomalies are detected.  When lost packet(s)
   are detected, the mechanism MUST output filler data in order to
   retain TDM timing.  Packets arriving in incorrect order SHOULD be
   reordered.  Lost packet processing SHOULD ensure that proper FAS is
   sent to the TDM network.  An example sequence number processing
   algorithm is provided in Appendix A.

   While the insertion of arbitrary filler data may be sufficient to
   maintain the TDM timing, for telephony traffic it may lead to audio
   gaps or artifacts that result in choppy, annoying or even
   unintelligible audio.  An implementation MAY blindly insert a
   preconfigured constant value in place of any lost samples, and this
   value SHOULD be chosen to minimize the perceptual effect.
   Alternatively one MAY replay the previously received packet.  When
   computational resources are available, implementations SHOULD conceal
   the packet loss event by properly estimating missing sample values in
   such fashion as to minimize the perceptual error.

Top      Up      ToC       Page 25 
7.2.  Timing Recovery

   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 1E-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 four methods of overcoming this
   difficulty.  In the first and second methods timing information is
   provided by some means independent of the PSN.  This timing may be
   provided to the TDM end systems (method 1) or to the IWFs (method 2).
   In a third method, a common clock is assumed available to both IWFs,
   and the relationship between the TDM source clock and this clock is
   encoded in the packet.  This encoding may take the form of RTP
   timestamps or may utilize the synchronous residual timestamp (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 [RFC4197] 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 IWF, 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.

Top      Up      ToC       Page 26 
   Whatever timing recovery mechanism is employed, the output of the
   TDM-bound IWF 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
   imposed.

7.3.  Congestion Control

   As explained in [RFC3985], the underlying PSN may be subject to
   congestion.  Unless appropriate precautions are taken, undiminished
   demand of bandwidth by TDMoIP can contribute to network congestion
   that may impact network control protocols.

   The AAL1 mode of TDMoIP is an inelastic constant bit-rate (CBR) flow
   and cannot respond to congestion in a TCP-friendly manner prescribed
   by [RFC2914], although the percentage of total bandwidth they consume
   remains constant.  The AAL2 mode of TDMoIP is variable bit-rate
   (VBR), and it is often possible to reduce the bandwidth consumed by
   employing mechanisms that are beyond the scope of this document.

   Whenever possible, TDMoIP 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 TDMoIP on neighboring streams.  In order to facilitate
   boundary traffic conditioning of TDMoIP traffic over IP PSNs, the
   TDMoIP packets SHOULD NOT use the Diffserv Code Point (DSCP) value
   reserved for the Default Per-Hop Behavior (PHB) [RFC2474].

   When TDMoIP is run over a PSN providing best-effort service, packet
   loss SHOULD be monitored in order to detect congestion.  If
   congestion is detected and bandwidth reduction is possible, then such
   reduction SHOULD be enacted.  If bandwidth reduction is not possible,
   then the TDMoIP PW SHOULD shut down bi-directionally for some period
   of time as described in Section 6.5 of [RFC3985].

   Note that:

      1.  In AAL1 mode TDMoIP can inherently provide packet loss
      measurement since the expected rate of packet arrival is fixed and
      known.

Top      Up      ToC       Page 27 
      2.  The results of the packet loss measurement may not be a
      reliable indication of presence or absence of severe congestion if
      the PSN provides enhanced delivery.  For example, if TDMoIP
      traffic takes precedence over other traffic, severe congestion may
      not significantly affect TDMoIP packet loss.

      3.  The TDM services emulated by TDMoIP have high availability
      objectives (see [G826]) that MUST be taken into account when
      deciding on temporary shutdown.

   This specification does not define exact criteria for detecting
   severe congestion or specific methods for TDMoIP shutdown or
   subsequent re-start.  However, the following considerations may be
   used as guidelines for implementing the shutdown mechanism:

      1.  If the TDMoIP PW has been set up using the PWE3 control
      protocol [RFC4447], the regular PW teardown procedures of these
      protocols SHOULD be used.

      2.  If one of the TDMoIP IWFs 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.

   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.

8.  Security Considerations

   TDMoIP does not enhance or detract from the security performance of
   the underlying PSN, rather it relies upon the PSN's mechanisms for
   encryption, integrity, and authentication whenever required.  The
   level of security provided may be less than that of a native TDM
   service.

   When the PSN is MPLS, PW-specific security mechanisms MAY be
   required, while for IP-based PSNs, IPsec [RFC4301] MAY be used.
   TDMoIP using L2TPv3 is subject to the security considerations
   discussed in Section 8 of [RFC3931].

Top      Up      ToC       Page 28 
   TDMoIP shares susceptibility to a number of pseudowire-layer attacks
   (see [RFC3985]) and implementations SHOULD use whatever mechanisms
   for confidentiality, integrity, and authentication are developed for
   general PWs.  These methods are beyond the scope of this document.

   Random initialization of sequence numbers, in both the control word
   and the optional RTP header, makes known-plaintext attacks on
   encrypted TDMoIP more difficult.  Encryption of PWs is beyond the
   scope of this document.

   PW labels SHOULD be selected in an unpredictable manner rather than
   sequentially or otherwise in order to deter session hijacking.  When
   using L2TPv3, a cryptographically random [RFC4086] Cookie SHOULD be
   used to protect against off-path packet insertion attacks, and a 64-
   bit Cookie is RECOMMENDED for protection against brute-force, blind,
   insertion attacks.

   Although TDMoIP MAY employ an RTP header when explicit transfer of
   timing information is required, SRTP (see [RFC3711]) mechanisms are
   not applicable.

9.  IANA Considerations

   For MPLS PSNs, PW Types for TDMoIP PWs are allocated in [RFC4446].

   For UDP/IP PSNs, when the source port is used as PW label, the
   destination port number MUST be set to 0x085E (2142), the user port
   number assigned by IANA to TDMoIP.

10.  Applicability Statement

   It must be recognized that the emulation provided by TDMoIP may be
   imperfect, and the service may differ from the native TDM circuit in
   the following ways.

   The end-to-end delay of a TDM circuit emulated using TDMoIP may
   exceed that of a native TDM circuit.

   When using adaptive clock recovery, the timing performance of the
   emulated TDM circuit depends on characteristics of the PSN, and thus
   may be inferior to that of a native TDM circuit.

   If the TDM structure overhead is not transported over the PSN, then
   non-FAS data in the overhead will be lost.

Top      Up      ToC       Page 29 
   When packets are lost in the PSN, TDMoIP mechanisms ensure that frame
   synchronization will be maintained.  When packet loss events are
   properly concealed, the effect on telephony channels will be
   perceptually minimized.  However, the bit error rate will be degraded
   as compared to the native service.

   Data in inactive channels is not transported in AAL2 mode, and thus
   this data will differ from that of the native service.

   Native TDM connections are point-to-point, while PSNs are shared
   infrastructures.  Hence, the level of security of the emulated
   service may be less than that of the native service.

11.  Acknowledgments

   The authors would like to thank Hugo Silberman, Shimon HaLevy, Tuvia
   Segal, and Eitan Schwartz of RAD Data Communications for their
   invaluable contributions to the technology described herein.

Top      Up      ToC       Page 30 
Appendix A.  Sequence Number Processing (Informative)

   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
   previously having been assumed lost, the TDM-bound IWF may discard
   it, and continue to treat it as lost.  Alternatively, if the filler
   data that had been inserted in its place has not yet been played out,
   the option remains to insert the true data into the playout buffer.
   Of course, the filler data may be generated upon initial detection of
   a missing packet or upon playout.  This description is stated in
   terms of a packet-oriented playout buffer rather than a TDM byte
   oriented one; however, this is not a true requirement for re-ordering
   implementations since the latter could be used along with pointers to
   packet commencement points.

   Having introduced the playout buffer we explicitly treat over-run and
   under-run of this buffer.  Over-run occurs when packets arrive so
   quickly that they can not be stored for playout.  This is usually an
   indication of gross timing inaccuracy or misconfiguration, and we can
   do little but discard such early packets.  Under-run is usually a
   sign of network starvation, resulting from congestion or network
   failure.

   The external variables used by the pseudocode are:

      received:  sequence number of packet received
      played:    sequence number of the packet being played out (Note 1)
      over-run:  is the playout buffer full? (Note 3)
      under-run: has the playout buffer been exhausted? (Note 3)

   The internal variables used by the pseudocode are:

      expected: sequence number we expect to receive next
      D: difference between expected and received (Note 2)
      L: difference between sequence numbers of packet being played out
         and that just received (Notes 1 and 2)

Top      Up      ToC       Page 31 
   In addition, the algorithm requires one parameter:

      R: maximum lateness for a packet to be recoverable (Note 1).

     Note 1: this is only required for the optional re-ordering
     Note 2: this number is always in the range -2^15 ... +2^15 - 1
     Note 3: the playout buffer is emptied by the TDM playout process,
             which runs asynchronously to the packet arrival processing,
             and which is not herein specified

   Sequence Number Processing Algorithm

   Upon receipt of a packet
     if received = expected
       { treat packet as in-order }
       if not over-run then
         place packet contents into playout buffer
       else
         discard packet contents
       set expected = (received + 1) mod 2^16
     else
       calculate D = ( (expected-received) mod 2^16 ) - 2^15
       if D > 0 then
         { packets expected, expected+1, ... received-1 are lost }
         while not over-run
           place filler (all-ones or interpolation) into playout buffer
           if not over-run then
             place packet contents into playout buffer
           else
             discard packet contents
           set expected = (received + 1) mod 2^16
       else  { late packet arrived }
         declare "received" to be a late packet
         do NOT update "expected"
         either
           discard packet
         or
           if not under-run then
             calculate L = ( (played-received) mod 2^16 ) - 2^15
             if 0 < L <= R then
               replace data from packet previously marked as lost
             else
               discard packet
   Note: by choosing R=0 we always discard the late packet

Top      Up      ToC       Page 32 
Appendix B.  AAL1 Review (Informative)

   The first byte of the 48-byte AAL1 PDU always contains an error-
   protected 3-bit sequence number.

                    1 2 3 4 5 6 7 8
                   +-+-+-+-+-+-+-+-+-----------------------
                   |C| SN  | CRC |P| 47 bytes of payload
                   +-+-+-+-+-+-+-+-+-----------------------

   C  (1 bit) convergence sublayer indication, its use here is limited
      to indication of the existence of a pointer (see below); C=0 means
      no pointer, C=1 means a pointer is present.

   SN (3 bits) The AAL1 sequence number increments from PDU to PDU.

   CRC  (3 bits) is a 3-bit error cyclic redundancy code on C and SN.

   P  (1 bit) even byte parity.

   As can be readily inferred, 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 unstructured circuit emulation, structured circuit
   emulation, and structured circuit emulation with CAS.

   The simplest PDU is the unstructured one, which is used for
   transparent transfer of whole circuits (T1,E1,T3,E3).  Although AAL1
   provides no inherent advantage as compared to SAToP for unstructured
   transport, in certain cases AAL1 may be required or desirable.  For
   example, when it is necessary to interwork with an existing AAL1-
   based network, or when clock recovery based on AAL1-specific
   mechanisms is favored.

   For unstructured AAL1, the 47 bytes after the sequence number byte
   contain the full 376 bits from the TDM bit stream.  No frame
   synchronization is supplied or implied, and framing is the sole
   responsibility of the end-user equipment.  Hence, the unstructured
   mode can be used to carry data, and for circuits with nonstandard
   frame synchronization.  For the T1 case the raw frame consists of 193
   bits, and hence 1 183/193 T1 frames fit into each AAL1 PDU.  The E1
   frame consists of 256 bits, and so 1 15/32 E1 frames fit into each
   PDU.

Top      Up      ToC       Page 33 
   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 filled.

        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 (most significant bit), 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 numbers.  Unlike most AAL1 PDUs that
   contain 47 TDM bytes, PDUs that contain a pointer (P-format PDUs)
   have the following format.

Top      Up      ToC       Page 34 
            0                 1
            1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------
           |C| SN  | CRC |P|E|   pointer   | 46 bytes of payload
           +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-----------------------

   where

   C  (1 bit) convergence sublayer indication, C=1 for P-format PDUs.

   SN (3 bits) is an even AAL1 sequence number.

   CRC  (3 bits) is a 3-bit error cyclic redundancy code on C and SN.

   P  (1 bit) even byte parity LSB (least significant bit) for sequence
      number byte.

   E  (1 bit) even byte parity MSB for pointer byte.

   pointer  (7 bits) pointer to next structure boundary.

   Since P-format PDUs have 46 bytes of payload and the next PDU has 47
   bytes, viewed as a single entity the pointer needs to indicate one of
   93 bytes.  If P=0 it is understood that the structure commences with
   the following byte (i.e., the first byte in the payload belongs to
   the lowest numbered channel).  P=93 means that the last byte of the
   second PDU is the final byte of the structure, and the following PDU
   commences with a new structure.  The special value P=127 indicates
   that there is no structure boundary to be indicated (needed when
   extremely large structures are being transported).

   The P-format PDU is always placed at the first possible position in
   the sequence number cycle that a structure boundary occurs, and can
   only occur once per cycle.

   The only difference between the structured circuit emulation format
   and structured circuit emulation with CAS is the definition of the
   structure.  Whereas in structured circuit emulation the structure is
   composed of the N channels, in structured circuit emulation with CAS
   the structure encompasses the superframe consisting of multiple
   repetitions of the N channels and then the CAS signaling bits.  The
   CAS bits are tightly packed into bytes and the final byte is padded
   with zeros if required.

   For example, for E1 circuits the CAS signaling bits are updated once
   per superframe of 16 frames.  Hence, the structure for N*64 derived
   from an E1 with CAS signaling consists of 16 repetitions of N bytes,

Top      Up      ToC       Page 35 
   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.

Top      Up      ToC       Page 36 
Appendix C.  AAL2 Review (Informative)

   The basic AAL2 PDU is:

         |    Byte  1    |    Byte  2    |    Byte  3    |
          0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------
         |      CID      |     LI    |   UUI   |   HEC   |   PAYLOAD
         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+------------

   CID  (8 bits) channel identifier is an identifier that must be unique
      for the PW.  The values 0-7 are reserved for special purposes,
      (and if interworking with VoDSL is required, so are values 8
      through 15 as specified in [LES]), thus leaving 248 (240) CIDs per
      PW.  The mapping of CID values to channels MAY be manually
      configured manually or signaled.

   LI (6 bits) length indicator is one less than the length of the
      payload in bytes.  Note that the payload is limited to 64 bytes.

   UUI  (5 bits) user-to-user indication is the higher layer
      (application) identifier and counter.  For voice data, the UUI
      will always be in the range 0-15, and SHOULD be incremented modulo
      16 each time a channel buffer is sent.  The receiver MAY monitor
      this sequence.  UUI is set to 24 for CAS signaling packets.

   HEC  (5 bits) the header error control

   Payload - voice
      A block of length indicated by LI of voice samples are placed as-
      is into the AAL2 packet.

   Payload - CAS signaling
      For CAS signaling the payload is formatted as an AAL2 "fully
      protected" (type 3) packet (see [AAL2]) in order to ensure error
      protection.  The signaling is sent with the same CID as the
      corresponding voice channel.  Signaling MUST be sent whenever the
      state of the ABCD bits changes, and SHOULD be sent with triple
      redundancy, i.e., sent three times spaced 5 milliseconds apart.
      In addition, the entire set of the signaling bits SHOULD be sent
      periodically to ensure reliability.

Top      Up      ToC       Page 37 
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |RED|       timestamp           |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       |  RES  | ABCD  |    type   | CRC
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           CRC (cont)  |
                       +-+-+-+-+-+-+-+-+

   RED  (2 bits) is the triple redundancy counter.  For the first packet
      it takes the value 00, for the second 01 and for the third 10.
      RED=11 means non-redundant information, and is used when triple
      redundancy is not employed, and for periodic refresh messages.

   Timestamp  (14 bits) The timestamp is optional and in particular is
      not needed if RTP is employed.  If not used, the timestamp MUST be
      set to zero.  When used with triple redundancy, it MUST be the
      same for all three redundant transmissions.

   RES  (4 bits) is reserved and MUST be set to zero.

   ABCD  (4 bits) are the CAS signaling bits.

   type  (6 bits) for CAS signaling this is 000011.

   CRC-10  (10 bits) is a 10-bit CRC error detection code.

Top      Up      ToC       Page 38 
Appendix D.  Performance Monitoring Mechanisms (Informative)

   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 [RFC2330], and its
   suitability for carrying TDM services.

   TDMoIP IWFs 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 [RFC792] or MPLS LSP ping packets [RFC4379] 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 [RFC5085], and the second is
   defined only for UDP/IP PSNs, and is based on a separate PW.  The
   latter is particularly efficient for a large number of fate-sharing
   TDM PWs.

D.1.  TDMoIP Connectivity Verification

   In most conventional IP applications a server sends some finite
   amount of information over the network after explicit request from a
   client.  With TDMoIP PWs the PSN-bound IWF could send a continuous
   stream of packets towards the destination without knowing whether the
   TDM-bound IWF 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 IWF is first brought up, when
   the TDM-bound IWF fails or is disconnected from the PSN, or the PW is
   broken.  After an aging time the destination IWF becomes unknown, and
   intermediate switches may flood the network with the TDMoIP packets
   in an attempt to find a new path.

Top      Up      ToC       Page 39 
   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.

   Connectivity is tested by periodically sending OAM messages from the
   source IWF to the destination IWF, 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 IWF is ready to receive packets before
   starting to send them.  Since TDMoIP IWFs 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 IWF may wait until it detects its peer before transmitting
   at full rate.  In addition, configuration errors may be readily
   discovered by using the service specific field of the OAM PW packets.

   In addition to one-way connectivity, OAM signaling mechanisms can be
   used to request and report on various PSN metrics, such as one-way
   delay, round trip delay, packet delay variation, etc.  They may also
   be used for remote diagnostics, and for unsolicited reporting of
   potential problems (e.g., dying gasp messages).

D.2.  OAM Packet Format

   When using inband performance monitoring, additional packets are sent
   using the same PW label.  These packets are identified by having
   their first nibble equal to 0001, and must be separated from TDM data
   packets before further processing of the control word.

   When using a separate OAM PW, all OAM messages MUST use the PW label
   preconfigured to indicate OAM.  All PSN layer parameters MUST remain
   those of the PW being monitored.

   The format of an inband OAM PW message packet for UDP/IP PSNs is
   based on [RFC2679].  The PSN-specific layers are identical to those
   defined in Section 4.1 with the PW label set to the value
   preconfigured or assigned for PW OAM.

Top      Up      ToC       Page 40 
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         PSN-specific layers  (with preconfigured PW label)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |0 0 0 0|L|R| M |RES| Length    |     OAM Sequence Number       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | OAM Msg Type  | OAM Msg Code  | Service specific information  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |       Forward PW label        |      Reverse PW label         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                   Source Transmit Timestamp                   |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                 Destination Receive Timestamp                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                Destination Transmit Timestamp                 |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   L, R, and M  are identical to those of the PW being tested.

   Length  is the length in bytes of the OAM message packet.

   OAM Sequence Number  (16 bits) is used to uniquely identify the
      message.  Its value is unrelated to the sequence number of the
      TDMoIP data packets for the PW in question.  It is incremented in
      query messages, and replicated without change in replies.

   OAM Msg Type  (8 bits) indicates the function of the message.  At
      present the following are defined:

             0 for one-way connectivity query message
             8 for one-way connectivity reply message.

   OAM Msg Code  (8 bits) is used to carry information related to the
      message, and its interpretation depends on the message type.  For
      type 0 (connectivity query) messages the following codes are
      defined:

             0 validate connection.
             1 do not validate connection

   for type 8 (connectivity reply) messages the available codes are:

             0 acknowledge valid query
             1 invalid query (configuration mismatch).

Top      Up      ToC       Page 41 
   Service specific information  (16 bits) is a field that can be used
      to exchange configuration information between IWFs.  If it is not
      used, this field MUST contain zero.  Its interpretation depends on
      the payload type.  At present, the following is defined for AAL1
      payloads.

                        0                   1
                        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                       | Number of TSs | Number of SFs |
                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Number of TSs  (8 bits) is the number of channels being transported,
      e.g., 24 for full T1.

   Number of SFs  (8 bits) is the number of 48-byte AAL1 PDUs per
      packet, e.g., 8 when packing 8 PDUs per packet.

   Forward PW label  (16 bits) is the PW label used for TDMoIP traffic
      from the source to destination IWF.

   Reverse PW label  (16 bits) is the PW label used for TDMoIP traffic
      from the destination to source IWF.

   Source Transmit Timestamp  (32 bits) represents the time the PSN-
      bound IWF transmitted the query message.  This field and the
      following ones only appear if delay is being measured.  All time
      units are derived from a clock of preconfigured frequency, the
      default being 100 microseconds.

   Destination Receive Timestamp  (32 bits) represents the time the
      destination IWF received the query message.

   Destination Transmit Timestamp  (32 bits) represents the time the
      destination IWF transmitted the reply message.

Top      Up      ToC       Page 42 
Appendix E.  Capabilities, Configuration and Statistics (Informative)

   Every TDMoIP IWF 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)

Top      Up      ToC       Page 43 
      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 (successfully 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

Top      Up      ToC       Page 44 
      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.

Top      Up      ToC       Page 45 
References

Normative References

   [AAL1]        ITU-T Recommendation I.363.1 (08/96) - B-ISDN ATM
                 Adaptation Layer (AAL) specification: Type 1

   [AAL2]        ITU-T Recommendation I.363.2 (11/00) - B-ISDN ATM
                 Adaptation Layer (AAL) specification: Type 2

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

   [G704]        ITU-T Recommendation G.704 (10/98) - Synchronous frame
                 structures used at 1544, 6312, 2048, 8448 and 44736
                 kbit/s hierarchical levels

   [G751]        ITU-T Recommendation G.751 (11/88) - Digital multiplex
                 equipments operating at the third order bit rate of
                 34368 kbit/s and the fourth order bit rate of 139264
                 kbit/s and using positive justification

   [G823]        ITU-T Recommendation G.823 (03/00) - The control of
                 jitter and wander within digital networks which are
                 based on the 2048 Kbit/s hierarchy

   [G824]        ITU-T Recommendation G.824 (03/00) - The control of
                 jitter and wander within digital networks which are
                 based on the 1544 Kbit/s hierarchy

   [G826]        ITU-T Recommendation G.826 (12/02) - End-to-end error
                 performance parameters and objectives for
                 international, constant bit-rate digital paths and
                 connections

   [IEEE802.1Q]  IEEE 802.1Q, IEEE Standards for Local and Metropolitan
                 Area Networks -- Virtual Bridged Local Area Networks
                 (2003)

   [IEEE802.3]   IEEE 802.3, IEEE Standard Local and Metropolitan Area
                 Networks - Carrier Sense Multiple Access with Collision
                 Detection (CSMA/CD) Access Method and Physical Layer
                 Specifications (2002)

Top      Up      ToC       Page 46 
   [LES]         ATM forum specification atm-vmoa-0145 (LES) Voice and
                 Multimedia over ATM - Loop Emulation Service Using AAL2

   [MEF8]        Metro Ethernet Forum, "Implementation Agreement for the
                 Emulation of PDH Circuits over Metro Ethernet
                 Networks", October 2004.

   [RFC768]      Postel, J., "User Datagram Protocol (UDP)", STD 6, RFC
                 768, August 1980.

   [RFC791]      Postel, J., "Internet Protocol (IP)", STD 5, RFC 791,
                 September 1981.

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

   [RFC3032]     Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
                 Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
                 Encoding", RFC 3032, January 2001.

   [RFC3931]     Lau, J., Townsley, M., Goyret, I., "Layer Two Tunneling
                 Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

   [RFC3550]     Schulzrinne, H., Casner, S., Frederick, R., and
                 Jacobson, V., "RTP: A Transport Protocol for Real-Time
                 Applications", STD 64, RFC 3550, July 2003.

   [RFC4446]     Martini, L., "IANA Allocations for Pseudowire Edge to
                 Edge Emulation (PWE3)", BCP 116, RFC 4446, April 2006.

   [RFC4447]     Martini, L., Rosen, E., El-Aawar, N., Smith, T., and G.
                 Heron, "Pseudowire Setup and Maintenance Using the
                 Label Distribution Protocol (LDP)", RFC 4447, April
                 2006.

   [RFC4553]     Vainshtein A., and Stein YJ., "Structure-Agnostic TDM
                 over Packet (SAToP)", RFC 4553, June 2006.

   [RFC4618]     Martini L., Rosen E., Heron G., and Malis A.,
                 "Encapsulation Methods for Transport of PPP/High-Level
                 Data Link Control (HDLC) over MPLS Networks", RFC 4618,
                 September 2006.

   [RFC5085]     Nadeau, T., Ed., and C. Pignataro, Ed., "Pseudowire
                 Virtual Circuit Connectivity Verification: A Control
                 Channel for Pseudowires", RFC 5085, December 2007.

Top      Up      ToC       Page 47 
   [SSCS]        ITU-T Recommendation I.366.2 (11/00) - AAL type 2
                 service specific convergence sublayer for narrow-band
                 services.

   [Y1413]       ITU-T Recommendation Y.1413 (03/04) - TDM-MPLS network
                 interworking - User plane interworking

   [Y1414]       ITU-T Recommendation Y.1414 (07/04) - Voice services -
                 MPLS network interworking.

   [Y1452]       ITU-T Recommendation Y.1452 (03/06) - Voice trunking
                 over IP networks.

   [Y1453]       ITU-T Recommendation Y.1453 (03/06) - TDM-IP
                 interworking - User plane interworking.

Informative References

   [ISDN-PRI]    ITU-T Recommendation Q.931 (05/98) - ISDN user-network
                 interface layer 3 specification for basic call control.

   [RFC792]      Postel J., "Internet Control Message Protocol", STD 5,
                 RFC 792, September 1981.

   [RFC2212]     Shenker, S., Partridge, C., and R. Guerin,
                 "Specification of Guaranteed Quality of Service", RFC
                 2212, September 1997.

   [RFC2330]     Paxson, V., Almes, G., Mahdavi, J., Mathis M.,
                 "Framework for IP Performance Metrics", RFC 2330, May
                 1998.

   [RFC2460]     Deering, S. and R. Hinden, "Internet Protocol, Version
                 6 (IPv6) Specification", RFC 2460, December 1998.

   [RFC2474]     Nichols, K., Blake, S., Baker, F., and D. Black,
                 "Definition of the Differentiated Services Field (DS
                 Field) in the IPv4 and IPv6 Headers", RFC 2474,
                 December 1998.

   [RFC2475]     Blake, S., Black, D., Carlson, M., Davies, E., Wang,
                 Z., and W. Weiss, "An Architecture for Differentiated
                 Service", RFC 2475, December 1998.

   [RFC2679]     Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way
                 Delay Metric for IPPM", RFC 2679, September 1999.

Top      Up      ToC       Page 48 
   [RFC2914]     Floyd, S., "Congestion Control Principles", BCP 41, RFC
                 2914, September 2000.

   [RFC3246]     Davie, B., Charny, A., Bennet, J.C., Benson, K., Le
                 Boudec, J., Courtney, W., Davari, S., Firoiu, V., and
                 D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop
                 Behavior)", RFC 3246, March 2002.

   [RFC3711]     Baugher, M., McGrew, D., Naslund, M., Carrara, E., and
                 K. Norrman, "The Secure Real-time Transport Protocol
                 (SRTP)", RFC 3711, March 2004.

   [RFC3985]     Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-
                 to-Edge (PWE3) Architecture", RFC 3985, March 2005.

   [RFC4086]     Eastlake, D., 3rd, Schiller, J., and S. Crocker,
                 "Randomness Requirements for Security", BCP 106, RFC
                 4086, June 2005.

   [RFC4197]     Riegel, M., "Requirements for Edge-to-Edge Emulation of
                 Time Division Multiplexed (TDM) Circuits over Packet
                 Switching Networks", RFC 4197, October 2005.

   [RFC4301]     Kent, S. and K. Seo, "Security Architecture for the
                 Internet Protocol", RFC 4301, December 2005.

   [RFC4379]     Kompella, K. and Swallow, G., "Detecting Multi-Protocol
                 Label Switched (MPLS) Data Plane Failures", RFC 4379,
                 February 2006.

   [RFC4385]     Bryant, S., Swallow, G., Martini, L., and D. McPherson,
                 "Pseudowire Emulation Edge-to-Edge (PWE3) Control Word
                 for Use over an MPLS PSN", RFC 4385, February 2006.

   [RFC5086]     Vainshtein, A., Ed., Sasson, I., Metz, E., Frost, T.,
                 and P. Pate, "Structure-Aware Time Division Multiplexed
                 (TDM) Circuit Emulation Service over Packet Switched
                 Network (CESoPSN)", RFC 5086, December 2007.

   [SS7]         ITU-T Recommendation Q.700 (03/93) - Introduction to
                 CCITT Signalling System No. 7.

   [TDM-CONTROL] Vainshtein, A. and Y(J) Stein, "Control Protocol
                 Extensions for Setup of TDM Pseudowires in MPLS
                 Networks", Work in Progress, November 2007.

Top      Up      ToC       Page 49 
   [TRAU]        GSM 08.60 (10/01) - Digital cellular telecommunications
                 system (Phase 2+); Inband control of remote transcoders
                 and rate adaptors for Enhanced Full Rate (EFR) and full
                 rate traffic channels.

Authors' Addresses

   Yaakov (Jonathan) Stein
   RAD Data Communications
   24 Raoul Wallenberg St., Bldg C
   Tel Aviv  69719
   ISRAEL

   Phone: +972 3 645-5389
   EMail: yaakov_s@rad.com


   Ronen Shashoua
   RAD Data Communications
   24 Raoul Wallenberg St., Bldg C
   Tel Aviv  69719
   ISRAEL

   Phone: +972 3 645-5447
   EMail: ronen_s@rad.com


   Ron Insler
   RAD Data Communications
   24 Raoul Wallenberg St., Bldg C
   Tel Aviv  69719
   ISRAEL

   Phone: +972 3 645-5445
   EMail: ron_i@rad.com


   Motty (Mordechai) Anavi
   RAD Data Communications
   900 Corporate Drive
   Mahwah, NJ  07430
   USA

   Phone: +1 201 529-1100 Ext. 213
   EMail: motty@radusa.com

Top      Up      ToC       Page 50 
Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   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, THE IETF TRUST 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.

Intellectual Property

   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.