diff options
Diffstat (limited to 'doc/rfc/rfc5087.txt')
| -rw-r--r-- | doc/rfc/rfc5087.txt | 2803 |
1 files changed, 2803 insertions, 0 deletions
diff --git a/doc/rfc/rfc5087.txt b/doc/rfc/rfc5087.txt new file mode 100644 index 0000000..298e120 --- /dev/null +++ b/doc/rfc/rfc5087.txt @@ -0,0 +1,2803 @@ + + + + + + +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] + |