GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc5087

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.

Stein, et al. Informational [Page 1] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 2] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 3] RFC 5087 TDMoIP December 2007

 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

Stein, et al. Informational [Page 4] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 5] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 6] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 7] RFC 5087 TDMoIP December 2007

 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

Stein, et al. Informational [Page 8] RFC 5087 TDMoIP December 2007

    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.

Stein, et al. Informational [Page 9] RFC 5087 TDMoIP December 2007

      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.

Stein, et al. Informational [Page 10] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 11] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 12] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 13] RFC 5087 TDMoIP December 2007

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.

Stein, et al. Informational [Page 14] RFC 5087 TDMoIP December 2007

 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:

Stein, et al. Informational [Page 15] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 16] RFC 5087 TDMoIP December 2007

 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".

Stein, et al. Informational [Page 17] RFC 5087 TDMoIP December 2007

 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

Stein, et al. Informational [Page 18] RFC 5087 TDMoIP December 2007

           +-------------+----------------+   +----------------+
           |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.

Stein, et al. Informational [Page 19] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 20] RFC 5087 TDMoIP December 2007

 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

Stein, et al. Informational [Page 21] RFC 5087 TDMoIP December 2007

 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

Stein, et al. Informational [Page 22] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 23] RFC 5087 TDMoIP December 2007

 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.

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.

Stein, et al. Informational [Page 24] RFC 5087 TDMoIP December 2007

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.

Stein, et al. Informational [Page 25] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 26] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 27] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 28] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 29] RFC 5087 TDMoIP December 2007

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)

Stein, et al. Informational [Page 30] RFC 5087 TDMoIP December 2007

 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

Stein, et al. Informational [Page 31] RFC 5087 TDMoIP December 2007

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.

Stein, et al. Informational [Page 32] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 33] RFC 5087 TDMoIP December 2007

          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,

Stein, et al. Informational [Page 34] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 35] RFC 5087 TDMoIP December 2007

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.

Stein, et al. Informational [Page 36] RFC 5087 TDMoIP December 2007

                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                     |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.

Stein, et al. Informational [Page 37] RFC 5087 TDMoIP December 2007

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.

Stein, et al. Informational [Page 38] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 39] RFC 5087 TDMoIP December 2007

      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).

Stein, et al. Informational [Page 40] RFC 5087 TDMoIP December 2007

 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.

Stein, et al. Informational [Page 41] RFC 5087 TDMoIP December 2007

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)

Stein, et al. Informational [Page 42] RFC 5087 TDMoIP December 2007

    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

Stein, et al. Informational [Page 43] RFC 5087 TDMoIP December 2007

    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.

Stein, et al. Informational [Page 44] RFC 5087 TDMoIP December 2007

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)

Stein, et al. Informational [Page 45] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 46] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 47] RFC 5087 TDMoIP December 2007

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

Stein, et al. Informational [Page 48] RFC 5087 TDMoIP December 2007

 [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

Stein, et al. Informational [Page 49] RFC 5087 TDMoIP December 2007

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.

Stein, et al. Informational [Page 50]

/data/webs/external/dokuwiki/data/pages/rfc/rfc5087.txt · Last modified: 2007/12/15 00:41 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki