Internet DRAFT - draft-white-sonet-format-rtp

draft-white-sonet-format-rtp



 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]