Transport Working Group Craig White Internet Draft Jim Boyle Expiration Date: January 2001 Level 3 July 2000 RTP Payload Format for SONET over IP draft-white-sonet-format-rtp-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. White & Boyle [Page 1] Internet Draft draft-white-sonet-format-rtp-00.txt July 2000 Abstract This memo describes the mapping of a SONET payload into an RTP payload. This will be useful when providing a SONET path level service between IP end points. The SONET payload is extracted and inserted into a RTP packet 8000 times a second. This document describes the RTP header fields usage and is meant for use by implementers of SONET to IP codecs. 1. Specification of Requirements 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. Introduction As service providers optimize their networks to carry IP traffic, a way to support traditional legacy users of SONET services over these emerging IP networks is needed. This memo will focus on the RTP payload format needed to transport the output of a SONET codec [1]. The codec extracts from the SONET frame the SPE (Synchronous Payload Envelope) which includes both the SONET path overhead and the STS-1 payload. These SPE's occur within a SONET frame nominally every 125 microseconds. The SPE is 783 bytes in length and is copied in its entirety to the RTP packet payload. The codec will create a separate RTP session for each SONET stream that it carries. This will allow a codec to function as a "wide area" add-drop device. The codec can send each SPE that it recovers to a different location. The creation of these sessions and the mapping of the SPE's into them are not covered in this document. To provide a N-concatenated service, the codec MUST send each SPE with the same RTP timestamp but with N consecutive sequence numbers. For more information about SONET SPE extraction techniques, refer to the SONET codec documents. Currently there are 2 codecs defined for doing this. This memo assumes that the IP network will sometimes loose packets but that this packet loss is not chronic. It also relies on the codec to process any line and section over head towards the path terminating equipment and to generate the appropriate SONET Line overhead to indicate SPE position and status if applicable. In addition the codec will generate the customary SONET signals to White & Boyle [Page 2] Internet Draft draft-white-sonet-format-rtp-00.txt July 2000 indicate a payload error condition towards the path terminating equipment in the event that an SPE packet is lost, arrives out of order or is otherwise not suitable for payback when received. It is outside the scope of this document to discuss SONET protection schemes. On the other hand, it is assumed that the IP network will provide IP level re-routing and can employee the use of traffic engineering techniques to control traffic. This memo does not require that the SONET clocking in preserved across the IP backbone. The codec on the other hand MUST provide a SONET compliant synchronization to it's respective path terminating equipment. 3. RTP Header usage padding (P): The padding bit MAY be set as required for other reasons outside the scope of this document. If, for example, the packet is required to end on a certain block boundary, such as may be required by encryption techniques. If used, the last padding bye MUST contain a count of how many padding bytes should be ignored, including itself. marker (M): The marker bit MAY be set to 1 on the first SPE of a concatenated service. This could be used by the codec to maintain sequence number synchronization. payload type (PT): The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. timestamp: The timestamp will increment by 1 every 125 microseconds. This will represent the time at which the first bit of the SPE was received. Since the codec will mask any SONET payload "float" this number doesn't have to exactly match the receipt of the first bit. For SONET concatenated services, the timestamp will be the same for each SPE in the concatenated stream. sequence number: Is used to determine the order of SPE's in a concatenated service. This is used by the codec to reassemble the concatenated stream, and to detect packet loss. White & Boyle [Page 3] Internet Draft draft-white-sonet-format-rtp-00.txt July 2000 4. Security Considerations 5. Intellectual Property Disclaimer This document is being submitted for use in IETF standards discussions. Level 3 Communications, Inc. has filed one or more patent applications relating to the technology outlined in this document. 6. Acknowledgements This draft has benefited from the discussions and assistance provided by Michael McGreevy, and Bill Gorsuch among others. 7. References [1] Boyle, J., Lawrence, J., White, C., "SONET Synchronous Transport Signal over IP", draft-boyle-sts-ip-00.txt, work in progress. [2] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A transport Protocol for Real-Time Applications:, RFC 1889, January 1996. [3] Schulzrinne, H., "RTP Profile for Audio and Video Conferences with Minimal Control", RFC 1890, January 1996. 8. Author Information Craig White Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 e-mail: craig.white@level3.com Jim Boyle Level 3 Communications, LLC. 1025 Eldorado Blvd. Broomfield, CO 80021 e-mail: jboyle@level3.net White & Boyle [Page 4]