PWE3 Working Group Tom Johnson Internet Draft Litchfield Communications, Inc. Expiration Date: August 2003 February 2003 TDM Circuit Emulation over Packet (CEP-TDM) draft-johnson-pwe3-tdm-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of section 10 of [RFC2026]. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. johnson-tdm Expires August 2003 [Page 1] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 Abstract This draft proposes a TDM emulation protocol for consideration by the PWE3 Working Group. The protocol defines methods for transporting DS3, E3, DS1, E1, and NxDS0 circuits over packet switched networks. It is based on ATM Circuit Emulation, but optimized for variable length packet networks. The intent is to provide a relatively simple but flexible method for transporting TDM signals over packet switched networks that also provides a path for interworking with ATM Circuit Emulation. Table of Contents 1 Conventions used in this document 3 2 Scope 3 3 CEP-TDM Encapsulation Format 4 4 Bit Timing 14 5 Misconfiguration Protection 14 6 Performance Monitoring 14 7 Security Considerations 15 8 Network Congestion Considerations 15 9 Applicability Statement 15 10 Intellectual Property Disclaimer 15 11 Acknowledgements 15 12 References 16 13 Author's Address 17 johnson-tdm [Page 2] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 1 Conventions used in this document 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 [RFC 2119]. 2 Scope This document describes a protocol that is intended to satisfy the requirements defined for TDM circuit emulation in [TDM-REQ]. This document provides methods for emulating the following digital signals across a packet-switched network. 1. unstructured DS1, E1, DS3, and E3 circuits 2. structured NxDS0 circuits without CAS 3. structured NxDS0 circuits with CAS For the remainder of this document, these will be referred to as TDM services. Because NSPs are already defined to provide various TDM multiplexing and mapping functions, the protocol is applicable to any TDM service regardless of the multiplexing level at which the service is connected to the PE. For example, unstructured emulation format can be used regardless of whether a T1 circuit is attached to the PE as a discrete T1, as a T1 within a channelized DS3, as a T1 within a channelized DS3 mapped onto an STS-1, etc. This goal of this protocol is to provide a simple method to transport TDM circuits across the PSN. Any multiplexing, mapping, or translation functions defined for the emulated service can be applied at the PE using existing NSPs defined by the appropriate standards bodies such as ANSI and ITU-T. johnson-tdm [Page 3] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3 CEP-TDM Encapsulation Format In order to transport TDM services through a packet-oriented network, the TDM bit-stream is broken into fragments. A CEP Header is pre-pended to each fragment. The resulting packet is encapsulated in RTP for transmission over an arbitrary PSN. (Note: under certain circumstances the RTP header may be suppressed to conserve network bandwidth. See section 3.4.3 for details). The basic CEP packet appears in Figure 1. +-----------------------------------+ | PSN and Multiplexing Layer | | Headers | +-----------------------------------+ | RTP Header | | (RFC1889) | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | TDM Fragment | | | | | +-----------------------------------+ Figure 1 - Basic CEP-TDM Packet johnson-tdm [Page 4] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3.1 TDM Fragment There are three modes of operation for TDM Circuit Emulation: Unstructured, NxDS0 w/o CAS, and NxDS0 w/ CAS. 3.1.1 Unstructured (DS1, E1, DS3, E3) All CEP-TDM implementations MUST support the basic unstructured mode of operation as described below. For example all DS1 end-points MUST support DS1 unstructured mode of operation, all E1 end-points MUST support E1 unstructured mode of operation, etc. In unstructured mode, there is no implied bit or byte alignment between the TDM service and the TDM fragments. The first bit received from the bit-stream MUST be the Most Significant Bit of each byte in the TDM fragment. Bytes are placed into the bit-stream fragment in the same order in which they are received. Implementations MUST support a bit-stream fragment size that is 376 bytes, and MAY support other sizes. Implementation MUST NOT assume any bit, byte, or frame alignment within the fragments. 3.1.2 NxDS0 with CAS CEP-TDM implementations MAY implement NxDS0 mode with CAS. In NxDS0 mode with CAS, the timeslots for the selected channels are concatenated in a superframe format as illustrated below. The number of frames in the CEP-TDM superframe MUST be 16 frames for E1- NxDS0 and 24 frames for T1-NxDS0. This implies that any interworking between formats (such as T1 to E1, etc.) MUST take place in NSPs at either end of the PSN. The goal of the PW is simply to carry the NxDS0 circuit with CAS through the PSN. Immediately following the last timeslot of the NxDS0 superframe, a signaling substructure is appended. This substructure carries the ABCD signaling bits associated with each timeslot in the order shown below. The A bit is the MSB of each nibble within the signaling substructure. If N is an odd number, a pad nybble MUST be appended to the end of the signaling substructure. The structure pointer in the CEP-TDM header MUST point to the first timeslot of the NxDS0 superframe within the packet. johnson-tdm [Page 5] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ Structure Ptr --->| TimeSlot 1 | +-+-+-+-+-+-+-+-+ | TimeSlot 2 | First 125 uSec Frame +-+-+-+-+-+-+-+-+ | TimeSlot 3 | +-+-+-+-+-+-+-+-+ | TimeSlot 1 | +-+-+-+-+-+-+-+-+ | TimeSlot 2 | Second 125 uSec Frame +-+-+-+-+-+-+-+-+ | TimeSlot 3 | +-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+ | TimeSlot 1 | +-+-+-+-+-+-+-+-+ | TimeSlot 2 | Last 125 uSec Frame +-+-+-+-+-+-+-+-+ | TimeSlot 3 | +-+-+-+-+-+-+-+-+ | Sig 1 | Sig 2 | +-+-+-+-+-+-+-+-+ | Sig 3 | Pad | +-+-+-+-+-+-+-+-+ Implementation MUST support a basic mode of operation where the entire superframe structure is included in a single packet. In this basic mode of operation, the first timeslot MUST always be the first byte of the packet and the structure pointer in the CEP-TDM header MUST always be zero. Implementations SHOULD support other packet sizes to trade-off packetization latency for packet overhead. In these cases, implementations MUST NOT assume any relationship between the start of the superframe and the packet boundaries. The structure pointer in the CEP-TDM header MUST be used to locate the start of the superframe within the packet stream. johnson-tdm [Page 6] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3.1.3 NxDS0 without CAS CEP-TDM implementations MAY implement NxDS0 mode without CAS. The superframe structure for NxDS0 without CAS is exactly the same as the superframe structure for NxDS0 with CAS, except that the signaling substructure is NOT appended to the end of the superframe. This is illustrated below for an NxDS0 circuit without CAS for N=3. 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ Structure Ptr --->| TimeSlot 1 | +-+-+-+-+-+-+-+-+ | TimeSlot 2 | First 125 uSec Frame +-+-+-+-+-+-+-+-+ | TimeSlot 3 | +-+-+-+-+-+-+-+-+ | TimeSlot 1 | +-+-+-+-+-+-+-+-+ | TimeSlot 2 | Second 125 uSec Frame +-+-+-+-+-+-+-+-+ | TimeSlot 3 | +-+-+-+-+-+-+-+-+ ... +-+-+-+-+-+-+-+-+ | TimeSlot 1 | +-+-+-+-+-+-+-+-+ | TimeSlot 2 | Last 125 uSec Frame +-+-+-+-+-+-+-+-+ | TimeSlot 3 | +-+-+-+-+-+-+-+-+ Implementation MUST support a basic mode of operation where the entire superframe structure is included in a single packet. A superframe consists of 16 frames for E1-NxDS0 and 24 frames for T1- NxDS0. In this basic mode of operation, the first timeslot MUST always be the first byte of the packet and the structure pointer in the CEP-TDM header MUST always be zero. Implementations SHOULD support other packet sizes to trade-off packetization latency for packet overhead. In these cases, implementations MUST NOT assume any relationship between the start of the superframe and the packet boundaries. The structure pointer in the CEP-TDM Header MUST be used to locate the start of the superframe within the packet stream. johnson-tdm [Page 7] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3.2 CEP Header The Basic CEP header has the following format: 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|R|D|N|P| Structure Pointer[0:12] | Sequence Number[0:13] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The above fields are defined as follows: R bit: CEP-RDI. This bit is set to one to signal to the remote CEP function that a loss of packet synchronization has occurred. D, N, and P bits: For CEP-TDM emulation, only a sub-set of the code-points defined by CEP-SPE/VT are utilized. See Table 1 for more details. +---+---+---+----------------------------------------------+ | D | N | P | Interpretation | +---+---+---+----------------------------------------------+ | 0 | 0 | 0 | Normal Mode | | 0 | 0 | 1 | Reserved | | 0 | 1 | 0 | Reserved | | 0 | 1 | 1 | AIS | | | | | | | 1 | 0 | 0 | Reserved | | 1 | 0 | 1 | Reserved | | 1 | 1 | 0 | Reserved | | 1 | 1 | 1 | Reserved | +---+---+---+----------------------------------------------+ Table 1. Interpretation of D, N, and P bits Sequence Number[0:13]: This is a packet sequence number, which MUST continuously cycle from 0 to 0x3FFF. It is generated and processed in accordance with the rules established in [RFC1889]. When the RTP header is used, this sequence number MUST match the LSBs of the RTP sequence Number. Structure Pointer[0:12]: The Structure Pointer locates the TDM structure within the TDM fragment. In structured data transfer mode, this MUST contain the offset to the first timeslot of the structure. The value is from 0 to 0x1FFE, where 0 means the first byte after the CEP header. The Structure Pointer MUST be set to 0x1FFF for packets that do not contain the first timeslot of the structure or for unstructured data transfer. johnson-tdm [Page 8] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3.3 RTP Header CEP uses the fixed RTP Header as shown below. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |V=2|P|X| CC |M| PT | sequence number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | timestamp | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | synchronization source (SSRC) identifier | +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ o V (version) is always set to 2 o P (padding) is always set to 0 o X (header extension) is always set to 0 o CC (CSRC count) is always set to 0 o M (marker) is set to 0 for CEP packets. o PT (payload type) is used to identify packets carrying the packetized TDM data. One PT value should be allocated from the range of dynamic values (see [RTP-TYPES]) for every CEP PW. Allocation is done during the PW setup and MUST be the same for both PW directions. The PE at the PW ingress MUST set the PT value in the RTP header to the allocated value. o Sequence Number is used primarily to provide the common PW sequencing function as well as detection of lost packets. It is generated and processed in accordance with the rules established in [RFC1889]. o Timestamp is used primarily for carrying timing information over the network. Their values are used in accordance with the rules established in [RFC1889]. O SSRC (synchronization source) value in the RTP header MAY be used for detection of misconnections. johnson-tdm [Page 9] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3.4 PSN Encapsulation In principle, CEP packets can be carried over any packet-oriented network. The following sections describe specifically how CEP packets MUST be encapsulated for carriage over MPLS or IP networks. 3.4.1 IP Encapsulation CEP uses the standard IP/UDP/RTP encapsulation scheme as shown below. The UDP destination port MUST be used to Demultiplex individual emulated TDM streams. +-----------------------------------+ | | | IPv6/v4 Header | | | +-----------------------------------+ | UDP Header | +-----------------------------------+ | RTP Header | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | TDM Fragment | | | | | +-----------------------------------+ Figure 2 - IP Transport Encapsulation johnson-tdm [Page 10] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3.4.2 MPLS Encapsulation RTP MAY be directly encapsulated in MPLS as shown below. To transport a CEP packet over an MPLS network, an MPLS label-stack MUST be pushed on top of the CEP packet. The bottom label in the MPLS label stack MUST be used to demultiplex individual emulated TDM streams. In keeping with the conventions used in [MARTINI-TRANS], this demultiplexing label is referred to as the PW Label and the upper labels are referred to as Tunnel Labels. +-----------------------------------+ | One or more MPLS Tunnel Labels | +-----------------------------------+ | PW Label | +-----------------------------------+ | RTP Header | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | TDM Fragment | | | | | +-----------------------------------+ Figure 3 - Typical MPLS Transport Encapsulation johnson-tdm [Page 11] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 3.4.3 RTP Header Suppression In addition to normal RTP header compression mechanisms as described in [RFC2508] and [RFC3095], an additional option may be used in CEP which suppresses transmission of the RTP header altogether. This mode may be used when both Circuit Emulation PEs are run synchronously and have access to a common reference clock or adaptive timing recovery techniques are being used, and both PEs support RTP Header Suppression. Under these conditions the following encapsulation formats may be used. The choice to utilize RTP Header Suppression may be statically configured, or signaled using a PW maintenance protocol. +-----------------------------------+ | | | IPv6/v4 Header | | | +-----------------------------------+ | UDP Header | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | TDM Fragment | | | | | +-----------------------------------+ Figure 4 - IP Transport Encapsulation w/ RTP Header Suppression johnson-tdm [Page 12] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 +-----------------------------------+ | One or more MPLS Tunnel Labels | +-----------------------------------+ | PW Label | +-----------------------------------+ | CEP Header | +-----------------------------------+ | | | | | TDM Fragment | | | | | +-----------------------------------+ Figure 5 - MPLS Transport Encapsulation w/ RTP Header Suppression 3.5 L2TP Encapsulation Encapsulation for L2TP PSNs is for future study. johnson-tdm [Page 13] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 4 Bit Timing There are three methods for addressing bit timing on the reassembled TDM stream. Synchronous, Adaptive, and Relative. Synchronous mode assumes that a common reference is available at both ends of the PSN that can be used to provide bit timing for the reassembled signal. Adaptive Timing may be used when a suitable reference is not available at both ends of the PSN. The details of adaptive timing recovery techniques are beyond the scope of this draft. However, [AAL1] provides some useful discussion on the topic for reference. Relative Timing may be used when a high quality common reference is available at each end of the PSN that is asynchronous to the TDM circuit being emulated. This case is analogous to the SRTS method described in [AAL1]. The RTP time-stamp may be used to capture the relative timing differences between the emulated signal and the reference clock. Details are TBD. 5 Misconfiguration Protection A key component of TDM circuit emulation is insuring that a TDM circuit is never delivered to the wrong end user. To aid in this effort, PE implementations targeting MPLS networks SHOULD utilize [MPLS OAM] or [MPLS PING]. Implementations utilizing [MPLS OAM] SHOULD validate the Connectivity Verification Packet contents to ensure that the Trail Trace Source ID matches the expected Trail Trace Source ID. If it does not, the associated TDM circuit should NOT be presented to the CE by the PE. 6 Performance Monitoring Another key component of TDM circuits is meeting defined service level agreements (SLAs). To verify the appropriate service level is being met, CEP-TDM will define several performance monitors. All performance monitoring will be based on the detection of lost packets by the CE-bound PE. Packets may be lost for several reasons including discard within the PSN due to congestion, arrival after its play-out time has passed, due to errors in the packet itself (such as IP checksum failure or L2 Frame Check Sequence Failure). Specific performance monitors that will be supported are: johnson-tdm [Page 14] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 CEP-TDM Errored Seconds (ES) - Seconds during which one or more dropped packets were detected. CEP-TDM Severely Errored Seconds (SES)- Seconds during which 3 or more dropped packets were detected. CEP-TDM Unavailable Seconds (UAS) - Seconds during which packet synchronization was lost. 7 Security Considerations A generic approach to security for L1 services must be developed that is applicable to emulated SONET/SDH circuits as well as TDM circuits. When that solution is developed, it will be incorporated into this document. 8 Network Congestion Considerations A generic approach to Network Congestion for CBR services must be developed that is applicable to emulated ATM-CBR circuits, emulated SONET/SDH circuits and TDM circuits. When the generic approach has been specified, it will be incorporated into this document. 9 Applicability Statement TDM Circuit Emulation over Packet (CEP) is an encapsulation layer intended for emulating TDM circuits over a Packet Switched Network. This protocol provides a method for emulating the key elements of traditional TDM services across a packet-switched network. Both large fixed-facility network operators and smaller network operators using ad hoc facilities may use this service. The protocol makes no assumptions as to the contents of the TDM circuit, and therefore is applicable to TDM circuits carrying any type of payload. 10 Intellectual Property Disclaimer TBD johnson-tdm [Page 15] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 11 Acknowledgements The author would like to acknowledge the following individuals for their valuable feedback and assistance during the creation and refinement of this document: Andy Malis, Neil Harrison, Tim Frost, Sasha Vainshtein, Yaakov Stein, Shahram Davari, Prayson Pate, and Max Reigel. 12 References [RFC2026] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC2026, October 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TDM-REQ] M. Riegel et al, Requirements for Edge-to-Edge Emulation of TDM Circuits over Packet Switching Networks (PSN), work in progress, December 2002, draft-riegel-pwe3-tdm-requirements-01.txt. [RTP-TYPES] RTP PARAMETERS, http://www.iana.org/assignments/rtp- parameters [RFC1889] H. Schulzrinne et al, RTP: A Transport Protocol for Real- Time Applications, RFC 1889, IETF, 1996 [MARTINI-TRANS] Martini et al, "Transport of Layer 2 Frames Over MPLS", work in progress, November 2002, draft-ietf-pwe3-control- protocol-01.txt. [RFC2508] S.Casner, V.Jacobson, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links, RFC 2508, IETF, 1999 [RFC3095] C.Bormann (Ed.), RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed, RFC 3095, IETF, 2001 [AAL1] ITU-T, "Recommendation I.363.1, B-ISDN Adaptation Layer Specification: Type AAL1", Appendix III, August 1996. [MPLS OAM] ITU-T, Recommendation Y.1711 OAM mechanism for MPLS networks", July 2002 johnson-tdm [Page 16] Internet Draft draft-johnson-pwe3-tdm-00 February 2003 13 Author's Address Tom Johnson Litchfield Communications, Inc. 27 Princeton Rd. Princeton Center West Watertown, CT 06795 Email: tom_johnson@litchfieldcomm.com Full Copyright Statement Copyright (C) The Internet Society (2001). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. johnson-tdm [Page 17]