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]