Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 5087

Time Division Multiplexing over IP (TDMoIP)

Pages: 50
Informational
Errata
Part 1 of 2 – Pages 1 to 24
None   None   Next

Top   ToC   RFC5087 - Page 1
Network Working Group                                        Y(J). Stein
Request for Comments: 5087                                   R. Shashoua
Category: Informational                                        R. Insler
                                                                M. Anavi
                                                 RAD Data Communications
                                                           December 2007


              Time Division Multiplexing over IP (TDMoIP)

Status of This Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Abstract

Time Division Multiplexing over IP (TDMoIP) is a structure-aware method for transporting Time Division Multiplexed (TDM) signals using pseudowires (PWs). Being structure-aware, TDMoIP is able to ensure TDM structure integrity, and thus withstand network degradations better than structure-agnostic transport. Structure-aware methods can distinguish individual channels, enabling packet loss concealment and bandwidth conservation. Accesibility of TDM signaling facilitates mechanisms that exploit or manipulate signaling.
Top   ToC   RFC5087 - Page 2

Table of Contents

1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. TDM Structure and Structure-aware Transport . . . . . . . . . 4 3. TDMoIP Encapsulation . . . . . . . . . . . . . . . . . . . . . 6 4. Encapsulation Details for Specific PSNs . . . . . . . . . . . 9 4.1. UDP/IP . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.2. MPLS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.3. L2TPv3 . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.4. Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . 15 5. TDMoIP Payload Types . . . . . . . . . . . . . . . . . . . . . 17 5.1. AAL1 Format Payload . . . . . . . . . . . . . . . . . . . 18 5.2. AAL2 Format Payload . . . . . . . . . . . . . . . . . . . 19 5.3. HDLC Format Payload . . . . . . . . . . . . . . . . . . . 20 6. TDMoIP Defect Handling . . . . . . . . . . . . . . . . . . . . 21 7. Implementation Issues . . . . . . . . . . . . . . . . . . . . 24 7.1. Jitter and Packet Loss . . . . . . . . . . . . . . . . . . 24 7.2. Timing Recovery . . . . . . . . . . . . . . . . . . . . . 25 7.3. Congestion Control . . . . . . . . . . . . . . . . . . . . 26 8. Security Considerations . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 10. Applicability Statement . . . . . . . . . . . . . . . . . . . 28 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 Appendix A. Sequence Number Processing (Informative) . . . . . . 30 Appendix B. AAL1 Review (Informative) . . . . . . . . . . . . . . 32 Appendix C. AAL2 Review (Informative) . . . . . . . . . . . . . . 36 Appendix D. Performance Monitoring Mechanisms (Informative) . . . 38 D.1. TDMoIP Connectivity Verification . . . . . . . . . . . . . 38 D.2. OAM Packet Format . . . . . . . . . . . . . . . . . . . . 39 Appendix E. Capabilities, Configuration and Statistics (Informative) . . . . . . . . . . . . . . . . . . . . 42 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 Normative References . . . . . . . . . . . . . . . . . . . . . . 45 Informative References . . . . . . . . . . . . . . . . . . . . . 47
Top   ToC   RFC5087 - Page 3

1. Introduction

Telephony traffic is conventionally carried over connection-oriented synchronous or plesiochronous links (loosely called TDM circuits herein). With the proliferation of Packet Switched Networks (PSNs), transport of TDM services over PSN infrastructures has become desirable. Emulation of TDM circuits over the PSN can be carried out using pseudowires (PWs), as described in the PWE3 architecture [RFC3985]. This emulation must maintain service quality of native TDM; in particular voice quality, latency, timing, and signaling features must be similar to those of existing TDM networks, as described in the TDM PW requirements document [RFC4197]. Structure-Agnostic TDM over Packet (SAToP) [RFC4553] is a structure- agnostic protocol for transporting TDM over PSNs. The present document details TDM over IP (TDMoIP), a structure-aware method for TDM transport. In contrast to SAToP, structure-aware methods such as TDMoIP ensure the integrity of TDM structure and thus enable the PW to better withstand network degradations. Individual multiplexed channels become visible, enabling the use of per channel mechanisms for packet loss concealment and bandwidth conservation. TDM signaling also becomes accessible, facilitating mechanisms that exploit or manipulate this signaling. Despite its name, the TDMoIP(R) protocol herein described may operate over several types of PSN, including UDP over IPv4 or IPv6, MPLS, Layer 2 Tunneling Protocol version 3 (L2TPv3) over IP, and pure Ethernet. Implementation specifics for particular PSNs are discussed in Section 4. Although the protocol should be more generally called TDMoPW and its specific implementations TDMoIP, TDMoMPLS, etc., we retain the nomenclature TDMoIP for consistency with earlier usage. The interworking function that connects between the TDM and PSN worlds will be called a TDMoIP interworking function (IWF), and it may be situated at the provider edge (PE) or at the customer edge (CE). The IWF that encapsulates TDM and injects packets into the PSN will be called the PSN-bound interworking function, while the IWF that extracts TDM data from packets and generates traffic on a TDM network will be called the TDM-bound interworking function. Emulated TDM circuits are always point-to-point, bidirectional, and transport TDM at the same rate in both directions. As with all PWs, TDMoIP PWs may be manually configured or set up using the PWE3 control protocol [RFC4447]. Extensions to the PWE3 control protocol required specifically for setup and maintenance of TDMoIP pseudowires are described in [TDM-CONTROL].
Top   ToC   RFC5087 - Page 4
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2. TDM Structure and Structure-aware Transport

Although TDM circuits can be used to carry arbitrary bit-streams, there are standardized methods for carrying constant-length blocks of data called "structures". Familiar structures are the T1 or E1 frames [G704] of length 193 and 256 bits, respectively. By concatenation of consecutive T1 or E1 frames we can build higher level structures called superframes or multiframes. T3 and E3 frames [G704][G751] are much larger than those of T1 and E1, and even larger structures are used in the GSM Abis channel described in [TRAU]. TDM structures contain TDM data plus structure overhead; for example, the 193-bit T1 frame contains a single bit of structure overhead and 24 bytes of data, while the 32-byte E1 frame contains a byte of overhead and 31 data bytes. Structured TDM circuits are frequently used to transport multiplexed channels. A single byte in the TDM frame (called a timeslot) is allocated to each channel. A frame of a channelized T1 carries 24 byte-sized channels, while an E1 frame consists of 31 channels. Since TDM frames are sent 8000 times per second, a single byte-sized channel carries 64 kbps. TDM structures are universally delimited by placing an easily detectable periodic bit pattern, called the Frame Alignment Signal (FAS), in the structure overhead. The structure overhead may additionally contain error monitoring and defect indications. We will use the term "structured TDM" to refer to TDM with any level of structure imposed by an FAS. Unstructured TDM signifies a bit stream upon which no structure has been imposed, implying that all bits are available for user data. SAToP [RFC4553] is a structure-agnostic protocol for transporting TDM using PWs. SAToP treats the TDM input as an arbitrary bit-stream, completely disregarding any structure that may exist in the TDM bit- stream. Hence, SAToP is ideal for transport of truly unstructured TDM, but is also suitable for transport of structured TDM when there is no need to protect structure integrity nor interpret or manipulate individual channels during transport. In particular, SAToP is the technique of choice for PSNs with negligible packet loss, and for applications that do not require discrimination between channels nor intervention in TDM signaling. As described in [RFC4553], when a single SAToP packet is lost, an "all ones" pattern is played out to the TDM interface. This pattern
Top   ToC   RFC5087 - Page 5
   is interpreted by the TDM end equipment as an Alarm Indication Signal
   (AIS), which, according to TDM standards [G826], immediately triggers
   a "severely errored second" event.  As such events are considered
   highly undesirable, the suitability of SAToP is limited to extremely
   reliable and underutilized PSNs.

   When structure-aware TDM transport is employed, it is possible to
   explicitly safeguard TDM structure during transport over the PSN,
   thus making possible to effectively conceal packet loss events.
   Structure-aware transport exploits at least some level of the TDM
   structure to enhance robustness to packet loss or other PSN
   shortcomings.  Structure-aware TDM PWs are not required to transport
   structure overhead across the PSN; in particular, the FAS MAY be
   stripped by the PSN-bound IWF and MUST be regenerated by the TDM-
   bound IWF.  However, structure overhead MAY be transported over the
   PSN, since it may contain information other than FAS.

   In addition to guaranteeing maintenance of TDM synchronization,
   structure-aware TDM transport can also distinguish individual
   timeslots of channelized TDM, thus enabling sophisticated packet loss
   concealment at the channel level.  TDM signaling also becomes
   visible, facilitating mechanisms that maintain or exploit this
   information.  Finally, by taking advantage of TDM signaling and/or
   voice activity detection, structure-aware TDM transport makes
   bandwidth conservation possible.

   There are three conceptually distinct methods of ensuring TDM
   structure integrity -- namely, structure-locking, structure-
   indication, and structure-reassembly.  Structure-locking requires
   each packet to commence at the start of a TDM structure, and to
   contain an entire structure or integral multiples thereof.
   Structure-indication allows packets to contain arbitrary fragments of
   basic structures, but employs pointers to indicate where each
   structure commences.  Structure-reassembly is only defined for
   channelized TDM; the PSN-bound IWF extracts and buffers individual
   channels, and the original structure is reassembled from the received
   constituents by the TDM-bound IWF.

   All three methods of TDM structure preservation have their
   advantages.  Structure-locking is described in [RFC5086], while the
   present document specifies both structure-indication (see
   Section 5.1) and structure-reassembly (see Section 5.2) approaches.
   Structure-indication is used when channels may be allocated
   statically, and/or when it is required to interwork with existing
   circuit emulation systems (CES) based on AAL1.  Structure-reassembly
   is used when dynamic allocation of channels is desirable and/or when
   it is required to interwork with existing loop emulation systems
   (LES) based on AAL2.
Top   ToC   RFC5087 - Page 6
   Operation, administration, and maintenance (OAM) mechanisms are vital
   for proper TDM deployments.  As aforementioned, structure-aware
   mechanisms may refrain from transporting structure overhead across
   the PSN, disrupting OAM functionality.  It is beneficial to
   distinguish between two OAM cases, the "trail terminated" and the
   "trail extended" scenarios.  A trail is defined to be the combination
   of data and associated OAM information transfer.  When the TDM trail
   is terminated, OAM information such as error monitoring and defect
   indications are not transported over the PSN, and the TDM networks
   function as separate OAM domains.  In the trail extended case, we
   transfer the OAM information over the PSN (although not necessarily
   in its native format).  OAM will be discussed further in Section 6.

3. TDMoIP Encapsulation

The overall format of TDMoIP packets is shown in Figure 1. +---------------------+ | PSN Headers | +---------------------+ | TDMoIP Control Word | +---------------------+ | Adapted Payload | +---------------------+ Figure 1. Basic TDMoIP Packet Format The PSN-specific headers are those of UDP/IP, L2TPv3/IP, MPLS or layer 2 Ethernet, and contain all information necessary for forwarding the packet from the PSN-bound IWF to the TDM-bound one. The PSN is assumed to be reliable enough and of sufficient bandwidth to enable transport of the required TDM data. A TDMoIP IWF may simultaneously support multiple TDM PWs, and the TDMoIP IWF MUST maintain context information for each TDM PW. Distinct PWs are differentiated based on PW labels, which are carried in the PSN-specific layers. Since TDM is inherently bidirectional, the association of two PWs in opposite directions is required. The PW labels of the two directions MAY take different values. In addition to the aforementioned headers, an OPTIONAL 12-byte RTP header may appear in order to enable explicit transfer of timing information. This usage is a purely formal reuse of the header format of [RFC3550]. RTP mechanisms, such as header extensions, contributing source (CSRC) list, padding, RTP Control Protocol (RTCP), RTP header compression, Secure RTP (SRTP), etc., are not applicable.
Top   ToC   RFC5087 - Page 7
   The RTP timestamp indicates the packet creation time in units of a
   common clock available to both communicating TDMoIP IWFs.  When no
   common clock is available, or when the TDMoIP IWFs have sufficiently
   accurate local clocks or can derive sufficiently accurate timing
   without explicit timestamps, the RTP header SHOULD be omitted.

   If RTP is used, the fixed RTP header described in [RFC3550] MUST
   immediately follow the control word for all PSN types except UDP/IP,
   for which it MUST precede the control word.  The version number MUST
   be set to 2, the P (padding), X (header extension), CC (CSRC count),
   and M (marker) fields in the RTP header MUST be set to zero, and the
   payload type (PT) values MUST be allocated from the range of dynamic
   values.  The RTP sequence number MUST be identical to the sequence
   number in the TDMoIP control word (see below).  The RTP timestamp
   MUST be generated in accordance with the rules established in
   [RFC3550]; the clock frequency MUST be an integer multiple of 8 kHz,
   and MUST be chosen to enable timing recovery that conforms with the
   appropriate standards (see Section 7.2).

   The 32-bit control word MUST appear in every TDMoIP packet.  Its
   format, in conformity with [RFC4385], is depicted in Figure 2.

        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  RES  |L|R| M |RES|  Length   |         Sequence Number       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

              Figure 2.  Structure of the TDMoIP Control Word

   RES  (4 bits) The first nibble of the control word MUST be set to
      zero when the PSN is MPLS, in order to ensure that the packet does
      not alias an IP packet when forwarding devices perform deep packet
      inspection.  For PSNs other than MPLS, the first nibble MAY be set
      to zero; however, in earlier versions of TDMoIP this field
      contained a format identifier that was optionally used to specify
      the payload format.

   L Local Failure  (1 bit) The L flag is set when the IWF has detected
      or has been informed of a TDM physical layer fault impacting the
      TDM data being forwarded.  In the "trail extended" OAM scenario
      the L flag MUST be set when the IWF detects loss of signal, loss
      of frame synchronization, or AIS.  When the L flag is set the
      contents of the packet may not be meaningful, and the payload MAY
      be suppressed in order to conserve bandwidth.  Once set, if the
      TDM fault is rectified the L flag MUST be cleared.  Use of the L
      flag is further explained in Section 6.
Top   ToC   RFC5087 - Page 8
   R Remote Failure  (1 bit) The R flag is set when the IWF has detected
      or has been informed, that TDM data is not being received from the
      remote TDM network, indicating failure of the reverse direction of
      the bidirectional connection.  An IWF SHOULD generate TDM Remote
      Defect Indicator (RDI) upon receipt of an R flag indication.  In
      the "trail extended" OAM scenario the R flag MUST be set when the
      IWF detects RDI.  Use of the R flag is further explained in
      Section 6.

   M Defect Modifier  (2 bits) Use of the M field is optional; when
      used, it supplements the meaning of the L flag.

      When L is cleared (indicating valid TDM data) the M field is used
      as follows:

       0 0  indicates no local defect modification.
       0 1  reserved.
       1 0  reserved.
       1 1  reserved.

      When L is set (invalid TDM data) the M field is used as follows:

       0 0  indicates a TDM defect that should trigger conditioning
            or AIS generation by the TDM-bound IWF.
       0 1  indicates idle TDM data that should not trigger any alarm.
            If the payload has been suppressed then the preconfigured
            idle code should be generated at egress.
       1 0  indicates corrupted but potentially recoverable TDM data.
       1 1  reserved.

      Use of the M field is further explained in Section 6.

   RES  (2 bits) These bits are reserved and MUST be set to zero.

   Length  (6 bits) is used to indicate the length of the TDMoIP packet
      (control word and payload), in case padding is employed to meet
      minimum transmission unit requirements of the PSN.  It MUST be
      used if the total packet length (including PSN, optional RTP,
      control word, and payload) is less than 64 bytes, and MUST be set
      to zero when not used.

   Sequence number  (16 bits) The TDMoIP sequence number provides the
      common PW sequencing function described in [RFC3985], and enables
      detection of lost and misordered packets.  The sequence number
      space is a 16-bit, unsigned circular space; the initial value of
      the sequence number SHOULD be random (unpredictable) for security
Top   ToC   RFC5087 - Page 9
      purposes, and its value is incremented modulo 2^16 separately for
      each PW.  Pseudocode for a sequence number processing algorithm
      that could be used by a TDM-bound IWF is provided in Appendix A.

   In order to form the TDMoIP payload, the PSN-bound IWF extracts bytes
   from the continuous TDM stream, filling each byte from its most
   significant bit.  The extracted bytes are then adapted using one of
   two adaptation algorithms (see Section 5), and the resulting adapted
   payload is placed into the packet.

4. Encapsulation Details for Specific PSNs

TDMoIP PWs may exploit various PSNs, including UDP/IP (both IPv4 and IPv6), L2TPv3 over IP (with no intervening UDP), MPLS, and layer-2 Ethernet. In the following subsections, we depict the packet format for these cases. For MPLS PSNs, the format is aligned with those specified in [Y1413] and [Y1414]. For UDP/IP PSNs, the format is aligned with those specified in [Y1453] and [Y1452]. For transport over layer 2 Ethernet the format is aligned with [MEF8].

4.1. UDP/IP

ITU-T recommendation Y.1453 [Y1453] describes structure-agnostic and structure-aware mechanisms for transporting TDM over IP networks. Similarly, ITU-T recommendation Y.1452 [Y1452] defines structure- reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for UDP/IP PSNs as described herein will interoperate with implementations designed to comply with Y.1453 subclause 9.2.2 or Y.1452 clause 10. For UDP/IPv4, the headers as described in [RFC768] and [RFC791] are prefixed to the TDMoIP data. The format is similar for UDP/IPv6, except the IP header described in [RFC2460] is used. The TDMoIP packet structure is depicted in Figure 3.
Top   ToC   RFC5087 - Page 10
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | IPVER |  IHL  |    IP TOS     |          Total Length         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |         Identification        |Flags|      Fragment Offset    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  Time to Live |    Protocol   |      IP Header Checksum       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Source IP Address                         |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                  Destination IP Address                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |      Source Port Number       |    Destination Port Number    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           UDP Length          |         UDP Checksum          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    opt|RTV|P|X|  CC   |M|     PT      |      RTP Sequence Number      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    opt|                            Timestamp                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    opt|                         SSRC identifier                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  RES  |L|R| M |RES|  Length   |         Sequence Number       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                        Adapted Payload                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                Figure 3.  TDMoIP Packet Format for UDP/IP

   The first five rows are the IP header, the sixth and seventh rows are
   the UDP header.  Rows 8 through 10 are the optional RTP header.  Row
   11 is the TDMoIP control word.

   IPVER  (4 bits) is the IP version number, e.g., IPVER=4 for IPv4.

   IHL  (4 bits) is the length in 32-bit words of the IP header, IHL=5.

   IP TOS  (8 bits) is the IP type of service.

   Total Length  (16 bits) is the length in bytes of header and data.

   Identification  (16 bits) is the IP fragmentation identification
      field.
Top   ToC   RFC5087 - Page 11
   Flags  (3 bits) are the IP control flags and MUST be set to 2 in
      order to avoid fragmentation.

   Fragment Offset  (13 bits) indicates where in the datagram the
      fragment belongs and is not used for TDMoIP.

   Time to Live  (8 bits) is the IP time to live field.  Datagrams with
      zero in this field are to be discarded.

   Protocol  (8 bits) MUST be set to 0x11 (17) to signify UDP.

   IP Header Checksum  (16 bits) is a checksum for the IP header.

   Source IP Address  (32 bits) is the IP address of the source.

   Destination IP Address  (32 bits) is the IP address of the
      destination.

   Source and Destination Port Numbers (16 bits each)

      Either the source UDP port or destination UDP port MAY be used to
      multiplex and demultiplex individual PWs between nodes.
      Architecturally [RFC3985], this makes the UDP port act as the PW
      Label.  PW endpoints MUST agree upon use of either the source UDP
      or destination UDP port as the PW Label.

      UDP ports MUST be manually configured by both endpoints of the PW.
      The configured source or destination port (one or the other, but
      not both) together with both the source and destination IP
      addresses uniquely identify the PW.  When the source UDP port is
      used as the PW label, the destination UDP port number MUST be set
      to the IANA assigned value of 0x085E (2142).  All UDP port values
      that function as PW labels SHOULD be in the range of dynamically
      allocated UDP port numbers (0xC000 through 0xFFFF).

      While many UDP-based protocols are able to traverse middleboxes
      without dire consequences, the use of UDP ports as PW labels makes
      middlebox traversal more difficult.  Hence, it is NOT RECOMMENDED
      to use UDP-based PWs where port-translating middleboxes are
      present between PW endpoints.

   UDP Length  (16 bits) is the length in bytes of UDP header and data.

   UDP Checksum  (16 bits) is the checksum of UDP/IP header and data.
      If not computed it MUST be set to zero.
Top   ToC   RFC5087 - Page 12

4.2. MPLS

ITU-T recommendation Y.1413 [Y1413] describes structure-agnostic and structure-aware mechanisms for transporting TDM over MPLS networks. Similarly, ITU-T recommendation Y.1414 [Y1413] defines structure- reassembly mechanisms for this purpose. Although the terminology used here differs slightly from that of the ITU, implementations of TDMoIP for MPLS PSNs as described herein will interoperate with implementations designed to comply with Y.1413 subclause 9.2.2 or Y.1414 clause 10. The MPLS header as described in [RFC3032] is prefixed to the control word and TDM payload. The packet structure is depicted in Figure 4. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Tunnel Label | EXP |S| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PW label | EXP |1| TTL | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| M |RES| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt|RTV|P|X| CC |M| PT | RTP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| SSRC identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Adapted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4. TDMoIP Packet Format for MPLS The first two rows depicted above are the MPLS header; the third is the TDMoIP control word. Fields not previously described will now be explained. Tunnel Label (20 bits) is the MPLS label that identifies the MPLS LSP used to tunnel the TDM packets through the MPLS network. The label can be assigned either by manual provisioning or via an MPLS control protocol. While transiting the MPLS network there may be zero, one, or several tunnel label rows. For label stack usage see [RFC3032].
Top   ToC   RFC5087 - Page 13
   EXP  (3 bits) experimental field, may be used to carry Diffserv
      classification for tunnel labels.

   S  (1 bit) the stacking bit indicates MPLS stack bottom.  S=0 for all
      tunnel labels, and S=1 for the PW label.

   TTL  (8 bits) MPLS Time to live.

   PW Label  (20 bits) This label MUST be a valid MPLS label, and MAY be
      configured or signaled.
Top   ToC   RFC5087 - Page 14

4.3. L2TPv3

The L2TPv3 header defined in [RFC3931] is prefixed to the TDMoIP data. The packet structure is depicted in Figure 5. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPVER | IHL | IP TOS | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identification |Flags| Fragment Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Time to Live | Protocol | IP Header Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session ID = PW label | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie 1 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | cookie 2 (optional) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | RES |L|R| M |RES| Length | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt|RTV|P|X| CC |M| PT | RTP Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| Timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ opt| SSRC identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Adapted Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5. TDMoIP Packet Format for L2TPv3 Rows 6 through 8 are the L2TPv3 header. Fields not previously described will now be explained. Protocol (8 bits) is the IP protocol field. It must be set to 0x73 (115), the user port number that has been assigned to L2TP by IANA. Session ID (32 bits) is the locally significant L2TP session identifier, and contains the PW label. The value 0 is reserved.
Top   ToC   RFC5087 - Page 15
   Cookie  (32 or 64 bits) is an optional field that contains a randomly
      selected value that can be used to validate association of the
      received frame with the expected PW.

4.4. Ethernet

Metro Ethernet Forum Implementation Agreement 8 [MEF8] describes structure-agnostic and structure-aware mechanisms for transporting TDM over Ethernet networks. Implementations of structure-indicated TDMoIP as described herein will interoperate with implementations designed to comply with MEF 8 Section 6.3.3. The TDMoIP payload is encapsulated in an Ethernet frame by prefixing the Ethernet destination and source MAC addresses, optional VLAN header, and Ethertype, and suffixing the four-byte frame check sequence. TDMoIP implementations MUST be able to receive both industry standard (DIX) Ethernet and IEEE 802.3 [IEEE802.3] frames and SHOULD transmit Ethernet frames. Ethernet encapsulation introduces restrictions on both minimum and maximum packet size. Whenever the entire TDMoIP packet is less than 64 bytes, padding is introduced and the true length indicated by using the Length field in the control word. In order to avoid fragmentation, the TDMoIP packet MUST be restricted to the maximum payload size. For example, the length of the Ethernet payload for a UDP/IP encapsulation of AAL1 format payload with 30 PDUs per packet is 1472 bytes, which falls below the maximal permitted payload size of 1500 bytes. Ethernet frames MAY be used for TDMoIP transport without intervening IP or MPLS layers, however, an MPLS-style label MUST always be present. In this four-byte header S=1, and all other non-label bits are reserved (set to zero in the PSN-bound direction and ignored in the TDM-bound direction). The Ethertype SHOULD be set to 0x88D8 (35032), the value allocated for this purpose by the IEEE, but MAY be set to 0x8847 (34887), the Ethertype of MPLS. The overall frame structure is as follows:
Top   ToC   RFC5087 - Page 16
        0                   1                   2                   3
        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                       |  Destination MAC Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                           Destination MAC Address (cont)              |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Source MAC Address
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           Source MAC Address  (cont)  |   VLAN Ethertype (opt)        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |VLP|C|      VLAN ID (opt)      |         Ethertype             |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |              PW label                 | RES |1|    RES        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |  RES  |L|R| M |RES|  Length   |         Sequence Number       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    opt|RTV|P|X|  CC   |M|     PT      |      RTP Sequence Number      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    opt|                            Timestamp                          |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    opt|                         SSRC identifier                       |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |                        Adapted Payload                        |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                     Frame Check Sequence                      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

               Figure 6.  TDMoIP Packet Format for Ethernet

   Rows 1 through 6 are the (DIX) Ethernet header; for 802.3 there may
   be additional fields, depending on the value of the length field, see
   [IEEE802.3].  Fields not previously described will now be explained.

   Destination MAC Address  (48 bits) is the globally unique address of
      a single station that is to receive the packet.  The format is
      defined in [IEEE802.3].

   Source MAC Address  (48 bits) is the globally unique address of the
      station that originated the packet.  The format is defined in
      [IEEE802.3].
Top   ToC   RFC5087 - Page 17
   VLAN Ethertype  (16 bits) 0x8100 in this position indicates that
      optional VLAN tagging specified in [IEEE802.1Q] is employed, and
      that the next two bytes contain the VLP, C, and VLAN ID fields.
      VLAN tags may be stacked, in which case the two-byte field
      following the VLAN ID is once again a VLAN Ethertype.

   VLP  (3 bits) is the VLAN priority, see [IEEE802.1Q].

   C  (1 bit) the "canonical format indicator" being set, indicates that
      route descriptors appear; see [IEEE802.1Q].

   VLAN ID  (12 bits) the VLAN identifier uniquely identifies the VLAN
      to which the frame belongs.  If zero, only the VLP information is
      meaningful.  Values 1 and FFF are reserved.  The other 4093 values
      are valid VLAN identifiers.

   Ethertype  (16 bits) is the protocol identifier, as allocated by the
      IEEE.  The Ethertype SHOULD be set to 0x88D8 (35032), but MAY be
      set to 0x8847 (34887).

   PW Label  (20 bits) This label MUST be manually configured.  The
      remainder of this row is formatted to resemble an MPLS label.

   Frame Check Sequence  (32 bits) is a Cyclic Redundancy Check (CRC)
      error detection field, calculated per [IEEE802.3].

5. TDMoIP Payload Types

As discussed at the end of Section 3, TDMoIP transports real-time streams by first extracting bytes from the stream, and then adapting these bytes. TDMoIP offers two different adaptation algorithms, one for constant-rate real-time traffic, and one for variable-rate real- time traffic. For unstructured TDM, or structured but unchannelized TDM, or structured channelized TDM with all channels active all the time, a constant-rate adaptation is needed. In such cases TDMoIP uses structure-indication to emulate the native TDM circuit, and the adaptation is known as "circuit emulation". However, for channelized TDM wherein the individual channels (corresponding to "loops" in telephony terminology) are frequently inactive, bandwidth may be conserved by transporting only active channels. This results in variable-rate real-time traffic, for which TDMoIP uses structure- reassembly to emulate the individual loops, and the adaptation is known as "loop emulation".
Top   ToC   RFC5087 - Page 18
   TDMoIP uses constant-rate AAL1 [AAL1,CES] for circuit emulation,
   while variable-rate AAL2 [AAL2] is employed for loop emulation.  The
   AAL1 mode MUST be used for structured transport of unchannelized data
   and SHOULD be used for circuits with relatively constant usage.  In
   addition, AAL1 MUST be used when the TDM-bound IWF is required to
   maintain a high timing accuracy (e.g., when its timing is further
   distributed) and SHOULD be used when high reliability is required.
   AAL2 SHOULD be used for channelized TDM when bandwidth needs to be
   conserved, and MAY be used whenever usage of voice-carrying channels
   is expected to be highly variable.

   Additionally, a third mode is defined specifically for efficient
   transport of High-Level Data Link Control (HDLC)-based Common Channel
   Signaling (CCS) carried in TDM channels.

   The AAL family of protocols is a natural choice for TDM emulation.
   Although originally developed to adapt various types of application
   data to the rigid format of ATM, the mechanisms are general solutions
   to the problem of transporting constant or variable-rate real-time
   streams over a packet network.

   Since the AAL mechanisms are extensively deployed within and on the
   edge of the public telephony system, they have been demonstrated to
   reliably transfer voice-grade channels, data and telephony signaling.
   These mechanisms are mature and well understood, and implementations
   are readily available.

   Finally, simplified service interworking with legacy networks is a
   major design goal of TDMoIP.  Re-use of AAL technologies simplifies
   interworking with existing AAL1- and AAL2-based networks.

5.1. AAL1 Format Payload

For the prevalent cases of unchannelized TDM, or channelized TDM for which the channel allocation is static, the payload can be efficiently encoded using constant-rate AAL1 adaptation. The AAL1 format is described in [AAL1] and its use for circuit emulation over ATM in [CES]. We briefly review highlights of AAL1 technology in Appendix B. In this section we describe the use of AAL1 in the context of TDMoIP. +-------------+----------------+ |control word | AAL1 PDU | +-------------+----------------+ Figure 7a. Single AAL1 PDU per TDMoIP Packet
Top   ToC   RFC5087 - Page 19
             +-------------+----------------+   +----------------+
             |control word |    AAL1 PDU    |---|    AAL1 PDU    |
             +-------------+----------------+   +----------------+

             Figure 7b.  Multiple AAL1 PDUs per TDMoIP Packet

   In AAL1 mode the TDMoIP payload consists of at least one, and perhaps
   many, 48-byte "AAL1 PDUs", see Figures 7a and 7b.  The number of PDUs
   MUST be pre-configured and MUST be chosen such that the overall
   packet size does not exceed the maximum allowed by the PSN (e.g., 30
   for UDP/IP over Ethernet).  The precise number of PDUs per packet is
   typically chosen taking latency and bandwidth constraints into
   account.  Using a single PDU delivers minimal latency, but incurs the
   highest overhead.  All TDMoIP implementations MUST support between 1
   and 8 PDUs per packet for E1 and T1 circuits, and between 5 and 15
   PDUs per packet for E3 and T3 circuits.

   AAL1 differentiates between unstructured and structured data
   transfer, which correspond to structure-agnostic and structure-aware
   transport.  For structure-agnostic transport, AAL1 provides no
   inherent advantage as compared to SAToP; however, there may be
   scenarios for which its use is desirable.  For example, when it is
   necessary to interwork with an existing AAL1 ATM circuit emulation
   system, or when clock recovery based on AAL1-specific mechanisms is
   favored.

   For structure-aware transport, [CES] defines two modes, structured
   and structured with Channel Associated Signaling (CAS).  Structured
   AAL1 maintains TDM frame synchronization by embedding a pointer to
   the beginning of the next frame in the AAL1 PDU header.  Similarly,
   structured AAL1 with CAS maintains TDM frame and multiframe
   synchronization by embedding a pointer to the beginning of the next
   multiframe.  Furthermore, structured AAL1 with CAS contains a
   substructure including the CAS signaling bits.

5.2. AAL2 Format Payload

Although AAL1 may be configured to transport fractional E1 or T1 circuits, the allocation of channels to be transported must be static due to the fact that AAL1 transports constant-rate bit-streams. It is often the case that not all the channels in a TDM circuit are simultaneously active ("off-hook"), and activity status may be determined by observation of the TDM signaling channel. Moreover, even during active calls, about half the time is silence that can be identified using voice activity detection (VAD). Using the variable- rate AAL2 mode, we may dynamically allocate channels to be transported, thus conserving bandwidth.
Top   ToC   RFC5087 - Page 20
   The AAL2 format is described in [AAL2] and its use for loop emulation
   over ATM is explained in [SSCS,LES].  We briefly review highlights of
   AAL2 technology in Appendix C.  In this section, we describe the use
   of AAL2 in the context of TDMoIP.

             +-------------+----------------+   +----------------+
             |control word |    AAL2 PDU    |---|    AAL2 PDU    |
             +-------------+----------------+   +----------------+

         Figure 8.  Concatenation of AAL2 PDUs in a TDMoIP Packet

   In AAL2 mode the TDMoIP payload consists of one or more variable-
   length "AAL2 PDUs", see Figure 8.  Each AAL2 PDU contains 3 bytes of
   overhead and between 1 and 64 bytes of payload.  A packet may be
   constructed by inserting PDUs corresponding to all active channels,
   by appending PDUs ready at a certain time, or by any other means.
   Hence, more than one PDU belonging to a single channel may appear in
   a packet.

   [RFC3985] denotes as Native Service Processing (NSP) functions all
   processing of the TDM data before its use as payload.  Since AAL2 is
   inherently variable rate, arbitrary NSP functions MAY be performed
   before the channel is placed in the AAL2 loop emulation payload.
   These include testing for on-hook/off-hook status, voice activity
   detection, speech compression, fax/modem/tone relay, etc.

   All mechanisms described in [AAL2,SSCS,LES] may be used for TDMoIP.
   In particular, channel identifier (CID) encoding and use of PAD
   octets according to [AAL2], encoding formats defined in [SSCS], and
   transport of CAS and CCS signaling as described in [LES] MAY all be
   used in the PSN-bound direction, and MUST be supported in the TDM-
   bound direction.  The overlap functionality and AAL-CU timer and
   related functionalities may not be required, and the STF (start
   field) is NOT used.  Computation of error detection codes -- namely,
   the Header Error Check (HEC) in the AAL2 PDU header and the CRC in
   the CAS packet -- is superfluous if an appropriate error detection
   mechanism is provided by the PSN.  In such cases, these fields MAY be
   set to zero.

5.3. HDLC Format Payload

The motivation for handling HDLC in TDMoIP is to efficiently transport common channel signaling (CCS) such as SS7 [SS7] or ISDN PRI signaling [ISDN-PRI], embedded in the TDM stream. This mechanism is not intended for general HDLC payloads, and assumes that the HDLC messages are always shorter than the maximum packet size.
Top   ToC   RFC5087 - Page 21
   The HDLC mode should only be used when the majority of the bandwidth
   of the input HDLC stream is expected to be occupied by idle flags.
   Otherwise, the CCS channel should be treated as an ordinary channel.

   The HDLC format is intended to operate in port mode, transparently
   passing all HDLC data and control messages over a separate PW.  The
   encapsulation is compatible with that of [RFC4618], however the
   sequence number generation and processing SHOULD be performed
   according to Section 3 above.

   The PSN-bound IWF monitors flags until a frame is detected.  The
   contents of the frame are collected and the Frame Check Sequence
   (FCS) tested.  If the FCS is incorrect, the frame is discarded;
   otherwise, the frame is sent after initial or final flags and FCS
   have been discarded and zero removal has been performed.  When a
   TDMoIP-HDLC frame is received, its FCS is recalculated, and the
   original HDLC frame reconstituted.

6. TDMoIP Defect Handling

Native TDM networks signify network faults by carrying indications of forward defects (AIS) and reverse defects (RDI) in the TDM bit stream. Structure-agnostic TDM transport transparently carries all such indications; however, for structure-aware mechanisms where the PSN-bound IWF may remove TDM structure overhead carrying defect indications, explicit signaling of TDM defect conditions is required. We saw in Section 3 that defects can be indicated by setting flags in the control word. This insertion of defect reporting into the packet rather than in a separate stream mimics the behavior of native TDM OAM mechanisms that carry such indications as bit patterns embedded in the TDM stream. The flags are designed to address the urgent messaging, i.e., messages whose contents must not be significantly delayed with respect to the TDM data that they potentially impact. Mechanisms for slow OAM messaging are discussed in Appendix D. +---+ +-----+ +------+ +-----+ +------+ +-----+ +---+ |TDM|->-| |->-|TDMoIP|->-| |->-|TDMoIP|->-| |->-|TDM| | | |TDM 1| | | | PSN | | | |TDM 2| | | |ES1|-<-| |-<-| IWF1 |-<-| |-<-| IWF2 |-<-| |-<-|ES2| +---+ +-----+ +------+ +-----+ +------+ +-----+ +---+ Figure 9. Typical TDMoIP Network Configuration The operation of TDMoIP defect handling is best understood by considering the downstream TDM flow from TDM end system 1 (ES1) through TDM network 1, through TDMoIP IWF 1 (IWF1), through the PSN, through TDMoIP IWF 2 (IWF2), through TDM network 2, towards TDM end
Top   ToC   RFC5087 - Page 22
   system 2 (ES2), as depicted in the figure.  We wish not only to
   detect defects in TDM network 1, the PSN, and TDM network 2, but to
   localize such defects in order to raise alarms only in the
   appropriate network.

   In the "trail terminated" OAM scenario, only user data is exchanged
   between TDM network 1 and TDM network 2.  The IWF functions as a TDM
   trail termination function, and defects detected in TDM network 1 are
   not relayed to network 2, or vice versa.

   In the "trail extended" OAM scenario, if there is a defect (e.g.,
   loss of signal or loss of frame synchronization) anywhere in TDM
   network 1 before the ultimate link, the following TDM node will
   generate AIS downstream (towards TDMoIP IWF1).  If a break occurs in
   the ultimate link, the IWF itself will detect the loss of signal.  In
   either case, IWF1 having directly detected lack of validity of the
   TDM signal, or having been informed of an earlier problem, raises the
   local ("L") defect flag in the control word of the packets it sends
   across the PSN.  In this way the trail is extended to TDM network 2
   across the PSN.

   Unlike forward defect indications that are generated by all network
   elements, reverse defect indications are only generated by trail
   termination functions.  In the trail terminated scenario, IWF1 serves
   as a trail termination function for TDM network 1, and thus when IWF1
   directly detects lack of validity of the TDM signal, or is informed
   of an earlier problem, it MAY generate TDM RDI towards TDM ES1.  In
   the trail extended scenario IWF1 is not a trail termination, and
   hence MUST NOT generate TDM RDI, but rather, as we have seen, sets
   the L defect flag.  As we shall see, this will cause the AIS
   indication to reach ES2, which is the trail termination, and which
   MAY generate TDM RDI.

   When the L flag is set there are four possibilities for treatment of
   payload content.  The default is for IWF1 to fill the payload with
   the appropriate amount of AIS (usually all-ones) data.  If the AIS
   has been generated before the IWF this can be accomplished by copying
   the received TDM data; if the penultimate TDM link fails and the IWF
   needs to generate the AIS itself.  Alternatively, with structure-
   aware transport of channelized TDM one SHOULD fill the payload with
   "trunk conditioning"; this involves placing a preconfigured "out of
   service" code in each individual channel (the "out of service" code
   may differ between voice and data channels).  Trunk conditioning MUST
   be used when channels taken from several TDM PWs are combined by the
   TDM-bound IWF into a single TDM circuit.  The third possibility is to
   suppress the payload altogether.  Finally, if IWF1 believes that the
   TDM defect is minor or correctable (e.g., loss of multiframe
   synchronization, or initial phases of detection of incorrect frame
Top   ToC   RFC5087 - Page 23
   sync), it MAY place the TDM data it has received into the payload
   field, and specify in the defect modification field ("M") that the
   TDM data is corrupted, but potentially recoverable.

   When IWF2 receives a local defect indication without M field
   modification, it forwards (or generates if the payload has been
   suppressed) AIS or trunk conditioning towards ES2 (the choice between
   AIS and conditioning being preconfigured).  Thus AIS has been
   properly delivered to ES2 emulating the TDM scenario from the TDM end
   system's point of view.  In addition, IWF2 receiving the L flag
   uniquely specifies that the defect was in TDM network 1 and not in
   TDM network 2, thus suppressing alarms in the correctly functioning
   network.

   If the M field indicates that the TDM has been marked as potentially
   recoverable, then implementation specific algorithms (not herein
   specified) may optionally be utilized to minimize the impact of
   transient defects on the overall network performance.  If the M field
   indicates that the TDM is "idle", no alarms should be raised and IWF2
   treats the payload contents as regular TDM data.  If the payload has
   been suppressed, trunk conditioning and not AIS MUST be generated by
   IWF2.

   The second case is when the defect is in TDM network 2.  Such defects
   cause AIS generation towards ES2, which may respond by sending TDM
   RDI in the reverse direction.  In the trail terminated scenario this
   RDI is restricted to network 2.  In the trail extended scenario, IWF2
   upon observing this RDI inserted into valid TDM data, MUST indicate
   this by setting the "R" flag in packets sent back across the PSN
   towards IWF1.  IWF1, upon receiving this indication, generates RDI
   towards ES1, thus emulating a single conventional TDM network.

   The final possibility is that of a unidirectional defect in the PSN.
   In such a case, TDMoIP IWF1 sends packets toward IWF2, but these are
   not received.  IWF2 MUST inform the PSN's management system of this
   problem, and furthermore generate TDM AIS towards ES2.  ES2 may
   respond with TDM RDI, and as before, in the trail extended scenario,
   when IWF2 detects RDI it MUST raise the "R" flag indication.  When
   IWF1 receives packets with the "R" flag set it has been informed of a
   reverse defect, and MUST generate TDM RDI towards ES1.

   In all cases, if any of the above defects persist for a preconfigured
   period (default value of 2.5 seconds) a service failure is declared.
   Since TDM PWs are inherently bidirectional, a persistent defect in
   either directional results in a bidirectional service failure.  In
   addition, if signaling is sent over a distinct PW as per Section 5.3,
   both PWs are considered to have failed when persistent defects are
   detected in either.
Top   ToC   RFC5087 - Page 24
   When failure is declared the PW MUST be withdrawn, and both TDMoIP
   IWFs commence sending AIS (and not trunk conditioning) to their
   respective TDM networks.  The IWFs then engage in connectivity
   testing using native methods or TDMoIP OAM as described in Appendix D
   until connectivity is restored.



(page 24 continued on part 2)

Next Section