Network Working Group Tat-Chee. Wan Internet-Draft Way-Chuang. Ang Intended status: Standards Track Chee Hong. Teh Expires: August, 2008 Universiti Sains Malaysia 19 March, 2008 Robust Header Compression over Unidirectional Lightweight Encapsulation (ULE) and MPEG2 Transport Stream (TS) frames draft-wan-ipdvb-rohc-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on August 25, 2008. Copyright Notice Copyright (C) The IETF Trust (2008). Wan, et al. Expires August 25, 2008 [Page 1] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Abstract This paper introduces approach to carry ROHC packets over ULE and MPEG2-TS frames. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Packet Format of ROHC Packet . . . . . . . . . . . . . . . . . 7 3.1. ROHC over ULE . . . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Dedicated EtherType Fields for ROHC Compressed Packet . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1.2. ROHC Compressed Packet as Payload of Ethernet Packet . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. ROHC over MPEG2-TS . . . . . . . . . . . . . . . . . . . . 8 4. Establishing ROHC Channel . . . . . . . . . . . . . . . . . . 10 4.1. ROHC Channel Parameters Negotiation Protocol (RCPNP) . . . 10 4.1.1. Compressor Advertisement . . . . . . . . . . . . . . . 12 4.1.2. Compressor Solicitation . . . . . . . . . . . . . . . 12 4.1.3. Request . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. Reply . . . . . . . . . . . . . . . . . . . . . . . . 15 4.1.4.1. Medium Information . . . . . . . . . . . . . . . . 16 4.1.4.1.1. MPEG-2 TS Medium . . . . . . . . . . . . . . . 16 4.1.4.1.2. ULE Medium . . . . . . . . . . . . . . . . . . 17 4.1.5. Acknowledgement/Negative Acknowledgement . . . . . . . 18 4.1.6. Compressor Shutdown . . . . . . . . . . . . . . . . . 18 4.1.7. Decompressor Shutdown . . . . . . . . . . . . . . . . 18 4.2. Interaction of RCPNP . . . . . . . . . . . . . . . . . . . 19 5. Bidirectional ROHC Channels . . . . . . . . . . . . . . . . . 20 6. IANA Consideration . . . . . . . . . . . . . . . . . . . . . . 21 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Normative References . . . . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Intellectual Property and Copyright Statements . . . . . . . . . . 26 Wan, et al. Expires August 25, 2008 [Page 2] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 1. Introduction This paper introduces approach to carry ROHC packets over ULE and MPEG2-TS frames. For completeness, ROHC Channel Parameters Negotiation Protocol (RCPNP) is also presented. Wan, et al. Expires August 25, 2008 [Page 3] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 2. Terminologies 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]. DVB Digital Video Broadcast. A framework and set of associated standards published by the European Telecommunications Standards Institute (ETSI) for the transmission of video, audio, and data using the ISO MPEG-2 Standard [ISO-MPEG2]. MAC Medium Access Control [IEEE-802.3]. A link-layer protocol defined by the IEEE 802.3 standard (or by Ethernet v2 [DIX]). MPEG-2 A set of standards specified by the Motion Picture Experts Group (MPEG) and standardized by the International Standards Organisation (ISO/IEC 13818-1) [ISO-MPEG2], and ITU-T (in H.222 [ITU-H222]). PDU Protocol Data Unit. Examples of a PDU include Ethernet frames, IPv4 or IPv6 datagrams, and other network packets. Receiver Equipment that processes the signal from a TS Multiplex and performs filtering and forwarding of encapsulated PDUs to the network-layer service (or bridging module when operating at the link layer). Transmitter Router or host that sends data. SNDU SubNetwork Data Unit. An encapsulated PDU sent as an MPEG-2 Payload Unit. Wan, et al. Expires August 25, 2008 [Page 4] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 TS Transport stream (TS) is a format specified in MPEG-2 Part 1, Systems (ISO/IEC standard 13818-1). Its design goal is to allow multiplexing of digital video and audio and to synchronize the output. Transport stream offers features for error correction for transportation over unreliable media, and is used in broadcast applications such as DVB and ATSC. ULE stream An MPEG-2 TS Logical Channel that carries only ULE encapsulated PDUs. ULE Streams may be identified by definition of a stream_type in SI/PSI [ISO-MPEG2]. ROHC Robust Header Compression. A framework of compression headers of IP packet as defined in [RFC3095]. ROHC channel A logical unidirectional point-to-point channel carrying ROHC packets from one compressor to one decompressor, optionally carrying ROHC feedback information on the behalf of another compressor-decompressor pair operating on a separate ROHC channel in the opposite direction. ROHC profile A logical unidirectional point-to-point channel carrying ROHC packets from one compressor to one decompressor, optionally carrying ROHC feedback information on the behalf of another compressor-decompressor pair operating on a separate ROHC channel in the opposite direction. MRRU Maximum Reconstructed Reception Unit as defined in [RFC3095]. Context Identifier [RFC3095] provides a definition for context identifiers. MSB Wan, et al. Expires August 25, 2008 [Page 5] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Most significant bit. LSB Least significant bit. ACK Acknowledgement. NACk Negative acknowledgement. CID Contect Identifier. Wan, et al. Expires August 25, 2008 [Page 6] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 3. Packet Format of ROHC Packet This section briefly describes the notation used in all diagrams. ":" in a diagram indicates that the part is optional. Likewise, "~" in a diagram indicates the number of octets by the part is not presented in a precise manner. This situation appears when a field or part spans multiple or variable number of bytes. 3.1. ROHC over ULE The packet format for ROHC packet encapsulated can be in one the following two formats: 3.1.1. Dedicated EtherType Fields for ROHC Compressed Packet MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | D | | +-----+ Length + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Type=ROHC + | | +-----+-----+-----+-----+-----+-----+-----+-----+ : : ~ Dest Address* (6 octets) ~ : : +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ ROHC compressed packet (variable length) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ CRC-32 (4 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 1: ROHC compressed packet encapsulated using dedicated EtherType The semantics of D-bit, Length, Type, Destination Address and CRC-32 fields are defined in section 4 of [RFC 4326]. However, the Type fields requires a new IANA assigned EtherType value to indicate the presence of ROHC compressed packet in PDU. In the absence of multiple receivers, a transmitter can send an SNDU Wan, et al. Expires August 25, 2008 [Page 7] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 without Destination Address Field (D bit marked). However, when multiple receivers are listening to the same transmitter, destination address must be included in SNDU. 3.1.2. ROHC Compressed Packet as Payload of Ethernet Packet MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | D=1 | | +-----+ Length + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Type=Ether + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ Dest MAC (6 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ Source MAC (6 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + EtherType=ROHC + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ ROHC compressed packet (varible length) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ CRC-32 (4 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 2: ROHC compressed packet encapsulated in SNDU bridged frame This packet format should be used when there are multiple transmitters and receivers over a DVB link. The value of EtherType field is similar to Type Field in section 3.1.1. 3.2. ROHC over MPEG2-TS This encapsulation format is the smallest packet format in terms of packet size. The format of SNDU is the following format: Wan, et al. Expires August 25, 2008 [Page 8] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 +------+------------------------+--------+ |Length| ROHC compressed packet | CRC-32 | +------+------------------------+--------+ Figure 3: ROHC compressed packet compressed encapsulated direct within MPEG2-TS frames' payload The meaning of each fields is specified below: Length This field indicates the ROHC compressed packet field only. This field can be either 1 or 2 octets depending on the the most significant bit. If the most significant bit is cleared, the length of this field is 1 octet and may represents values from 0 until 127. Otherwise, the length of this field is 2 octets and may represents values from 128 until 61566. ROHC Compressed Packet ROHC compressed packet as defined in section 5.2 of [RFC3095]. CRC-32 The 32-bit CRC is calculated over Length filed and ROHC compressed packet. The polynomial used to calculate the CRC is 0x104C11DB7. Like ULE, ROHC over MPEG2-TS also supports packing and padding mode. The mechanism of encapsulating this SNDU is similar to encapsulation of ULE packet within MPEG2-TS. This approach requires that separate PID dedicated to a ROHC channel. Wan, et al. Expires August 25, 2008 [Page 9] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 4. Establishing ROHC Channel This standard presents two approaches to setup a ROHC channel over a DVB link. The first approach is to setup ROHC channel manually. This requires that the operators at the every transmitters and receivers to manually configure the ROHC channel parameters. When the size of network is small, this approach is favourable. But the former approach becomes nonviable if the network is dynamic and is not scalable as the size of the network grows. Henceforth, we presents a negotiation protocol to create ROHC channel in the next section. 4.1. ROHC Channel Parameters Negotiation Protocol (RCPNP) The approach presented in this section can only work if compressor site and decompressor site are connected through two dedicated unidirectional DVB links, with a unidirectional link originating from each of the sites, configured to form a bidirectional network link between the two sites. This protocol works through ULE packets only. It is possible to extend this protocol to work over Generic Stream Encapsulation [GSE] in the future. While it is possible to extend this protocol to work over asymmetrical link, this draft doesn't try to address this issue. Since new EtherType is allocated, this protocol can be extended to asymmetrical link via Link-Layer Tunneling Mechanism [RFC3077] with little modifications. The basic format of ULE SNDU packet is as such: +---+--------+------------+----------+--------+ |D=1| Length |Type=ROHCNeg| Body | CRC-32 | +---+--------+------------+----------+--------+ Figure 4: Minimal format of RCPNP message Wan, et al. Expires August 25, 2008 [Page 10] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | D=1 | | +-----+ Length + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Type=Ether + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ Dest MAC (6 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ Source MAC (6 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + EtherType=ROHCNeg + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ Body (varible length) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ CRC-32 (4 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 5: RCPNP message encapsulated in bridged frame Type field requires a new separate IANA assigned EtherType number for ROHC Channel Negotiation Protocol. The types of message in this protocol is defined in the Body field. The following subsections will explain the type of messages for this protocol. Compressor Advertisement and Compressor Solicitation uses packet format depicted in Figure 4. While other forms of messages uses packet format depicted in Figure 5. The basic format for these messages is depicted is as such: Wan, et al. Expires August 25, 2008 [Page 11] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version | Operation | X | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 6: Basic format of RCPNP Body field Currently, version number is 0. Operation field defines the type of message contained in the Body field. The content of X-bit depends on operation type. 4.1.1. Compressor Advertisement MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version=0 | Operation=0 | X | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ Address (6 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 7: Format of Compressor Advertisement message This message is used by the compressor site to advertise the availability of ROHC Compressor. Out of concern for bandwidth and energy consumption, compressor site should limit the broadcast of this message for a few times when it first join the network. This message should also be broadcasted when a Compressor Solicitation message is received. The decompressor site will use the value specified in the Address field when addressing compressor site. X-bit is unused and should be ignored. 4.1.2. Compressor Solicitation MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version=0 | Operation=1 | X | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 8: Format of Compressor Solicitation message This message is broadcasted by decompressor to solicit for compressor. X-bit is unused and should be ignored. Decompressor site should rate-limit the frequency of solicitation if it is doesn't Wan, et al. Expires August 25, 2008 [Page 12] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 receive any Compressor Advertisement to avoid flooding DVB link. 4.1.3. Request MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version=0 | Operation=2 | X | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Maximum CID + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ MRRU (4 octets) ~ | | +-----+-----+-----+-----+-----+-----+-----+-----+ | Number of Media | | ~-----+-----+-----+ Medium Types ~ : : +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Num of profiles + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Profile ID 1 + | | +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID 2 + : : +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID N + :| : +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 9: Format of Request message This message is sent by decompressor site to compressor site when it wishes to establish a ROHC channel. The meaning of each fields in the message are described below: Maximum CID Wan, et al. Expires August 25, 2008 [Page 13] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Maximum Context Identifier tolerated by decompressor. MRRU Maximum Reconstructed Reception Unit tolerated by decompressor. Value of 0 indicates the negotiated channel doesn't allow for segmentation of ROHC compressed packet. Number of Media The number of medium types carried in Medium Types field. Medium Types This field consists of all supported medium types by the decompressor. Each medium type consists of 3 bits and corresponds to Medium field described in Medium Information (Section 4.1.4.1) section. The number of bits used by Medium Types and Number of Media fields must be expanded to multiple of 8 if actual number of required bits is not multiple of 8. The unused bits for such case should be ignored by Compressor site. Number of profiles Number of profiles supported by decompressor. Profile IDs ROHC Profile IDs supported by decompressor. Each profile ID occupy 2 octets. X-bit is unused and should be ignored. Wan, et al. Expires August 25, 2008 [Page 14] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 4.1.4. Reply MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version=0 | Operation=3 | X | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Maximum CID + | | +-----+-----+-----+-----+-----+-----+-----+-----+ | | ~ MRRU (4 octets) ~ | | +===============================================+ | Num of profiles | +-----+-----+-----+-----+-----+-----+-----+-----+ | | + Profile ID 1 + | | +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID 2 + : : +-----+-----+-----+-----+-----+-----+-----+-----+ : : + Profile ID N + : : +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 10: Format of Reply message This message is sent by compressor site to decompressor site in response to request message sent by decompressor site. The meaning of each fields in the message are described below: Maximum CID Maximum CID tolerated by compressor. This value of this field should be less than or equal to its counterpart in request message. Decompressor site should send a NACK if it receives Maximum CID that is higher than the initial negotiated value. MRRU Wan, et al. Expires August 25, 2008 [Page 15] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Maximum Reconstructed Reception Unit tolerated by compressor. Likewise, decompressor site should send a NACK if it is receives higher MRRU than what it requested. Number of profile IDs Note that this field is 1 octet instead of 2 because there can be only 256 active profiles at any given ROHC channel. Decompressor site should send a NACK if it receives more profile IDs than it can support. Profile IDs Profile Identifiers of the ROHC profiles that will be used for the negotiated ROHC channel. Decompressor site should send a NACK if it receives any profile ID that it doesn't support. X-bit is unused and should be ignored. 4.1.4.1. Medium Information The following notation depicted in the previous figure 10 indicates the presence of medium information. +===============================================+ Medium information conveys how compressor is to send ROHC compressed packets to decompressor. Currently only 2 media are supported, namely MPEG2-TS and ULE. The details of packet format for ROHC over MPEG2-TS/ULE is described in section 3. Medium type is conveyed by Medium field. Other media may be supported in the future and the support for these media will specified in other documents. Decompressor receiving unsupported medium type should send a NACK. When an unrecognized medium type is received, decompressor site should send an NACK message to compressor. 4.1.4.1.1. MPEG-2 TS Medium MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Medium=0 | | +-----+-----+-----+ PID + | | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 12: Medium information for ROHC over MPEG2-TS Wan, et al. Expires August 25, 2008 [Page 16] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 PID Packet Identifier of MPEG2-TS frames that will carry ROHC compressed packet. 4.1.4.1.2. ULE Medium MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Medium=1 | ULE Type | Reserved | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 13: Medium information for ROHC over ULE ULE Type: 0 No MAC address will be sent in ULE packets. This option should only be used if the compressor site is certain that there is only one receiver and one transmitter over DVB link. 1 Only destination MAC address will be sent in ULE packets that carry ROHC compressed packet. This means that Destination Absent bit in ULE header will be cleared. This option is used only if there is one transmitter and many receivers listening to that transmitter via DVB link. 2 ROHC packets will be encapsulated in Ethernet bridged frame. This option is used when there multiple transmitters and receivers over a DVB link. 3 Not used. Receiver should treat it as corrupted packet, silently discard the message and wait for a valid Reply message or until a timeout occur at which the decompressor site will start the negotiation afresh by sending a Request message. Reserved field is not used and should be ignored. Wan, et al. Expires August 25, 2008 [Page 17] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 4.1.5. Acknowledgement/Negative Acknowledgement MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version=0 | Operation=4 | Ack | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 14: Format of Acknowledgement message Decompressor site should send either an acknowledgement or negative acknowledgement if it receives a valid Reply message. If Ack bit is set, then the message is an acknowledgement. Otherwise, it is a negative acknowledgement. If compressor site doesn't receive ACK nor NACK within a reasonable interval, it should discard any information of negotiated ROHC channel parameters. An acknowledgement must be sent to decompressor site when compressor site receives Decompressor Shutdown message. 4.1.6. Compressor Shutdown MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version=0 | Operation=5 | X | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 15: Format of Compressor Shutdown message This message is sent by the compressor site to notify the decompressor site that it is about to stop compressing IP packets. Upon receiving this message, decompressor should release all resources that are being held. Compressor must wait for an acknowledgement from decompressor site before freeing its resource. If it doesn't an acknowledgement within a reasonable interval, it should keep sending a shutdown message for a number of times before freeing its resource. X-bit is unused and should be ignored. 4.1.7. Decompressor Shutdown Wan, et al. Expires August 25, 2008 [Page 18] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 MSB LSB 0 1 2 3 4 5 6 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | Version=0 | Operation=6 | X | +-----+-----+-----+-----+-----+-----+-----+-----+ Figure 16: Format of Decompressor Shutdown message This message is sent by the decompressor site to notify the compressor that it is about to stop decompressing IP packets. Upon receiving this message, compressor should release all resources that are being held and stop sending compressed IP packets. Decompressor must wait for an acknowledgement from compressor site before freeing its resource. If it doesn't an acknowledgement within a reasonable interval, it should keep sending a shutdown message for a number of times before freeing its resource. X-bit is unused and should be ignored. 4.2. Interaction of RCPNP The following diagram depicts a possible interaction between compressor site and decompressor site in negotiating ROHC channel parameters. Compressor Site Decompressor Site |<---------------- Solicit ---------------| | | |-------------- Advertise --------------->| | | |<-------------- Request -----------------| | | |---------------- Reply ----------------->| | | Create instance | | of decompressor Create |<---------------- ACK -------------------| compressor | | | | |= (Compression can begin at this point) =| | | | | Destroy |<------- Decompressor Shutdown ----------| compressor | | |----------------- ACK --- -------------->| Destroy | | decompressor Figure 17: Packets flow of RCPNP Wan, et al. Expires August 25, 2008 [Page 19] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 5. Bidirectional ROHC Channels While establishing bidirectional ROHC channels allows for the use of ROHC bidirectional optimistic mode and bidirectional reliable mode, RCPNP doesn't concern itself with the establishment of bidirectional ROHC channels. Therefore, it is up to implementers of this protocol to support bidirectional ROHC channels. The implementation should be as straightforward as mapping correct pair of ROHC channels. Wan, et al. Expires August 25, 2008 [Page 20] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 6. IANA Consideration Two EtherTypes should be assigned. One of it is for RCPNP and the other is to indicate the presence of ROHC compressed packet. Wan, et al. Expires August 25, 2008 [Page 21] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 7. Acknowledgements We would like to thank Rod Walsh (Nokia) for his valuable input and feedback. We also want to extend our gratitude to Dr. Gorry Fairhurst for his guidance. Wan, et al. Expires August 25, 2008 [Page 22] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 8. Security Considerations - None - Wan, et al. Expires August 25, 2008 [Page 23] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 9. Normative References [DIX] Digital Equipment Corp, Intel Corp, Xerox Corp, "Ethernet Local Area Network Specification Version 2.0", November 1982. [GSE] Digital Video Broadcasting, ""Generic Stream Encapsulation (GSE) Protocol", DVB Document A116, 2007. [IEEE-802.3] IEEE 802.3, "Local and metropolitan area networks-Specific requirements Part 3: Carrier sense multiple access with collision detection (CSMA/CD) access method and physical layer specifications", IEEE Computer Society, (also ISO/ IEC 8802-3), 2000. [ISO-MPEG2] ISO 13818-1, "Information technology -- Generic coding of moving pictures and associated audio information -- Part 1: Systems", International Standards Organisation (ISO), 2000. [ITU-H222] H.222.0, "Information technology - Generic coding of moving pictures and associated audio information: Systems, International Telecommunication Union, (ITU-T)", 1995. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3077] Duros, E., "A Link-Layer Tunneling Mechanism for Unidirectional Links", RFC 3077, 2001. [RFC3095] Borman, C., "RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP, and uncompressed", RFC 3095, 2001. Wan, et al. Expires August 25, 2008 [Page 24] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Authors' Addresses Tat-Chee Wan Universiti Sains Malaysia School of Computer Science Universiti Sains Malaysia Penang Malaysia Phone: +6 04 653 4633 Email: tcwan@nav6.org URI: http://nrg.cs.usm.my/~tcwan Way-Chuang Ang Universiti Sains Malaysia School of Computer Science Universiti Sains Malaysia Penang Malaysia Email: wcang@nav6.org Chee-Hong Teh Universiti Sains Malaysia School of Computer Science Universiti Sains Malaysia Penang Malaysia Email: chteh@nav6.org Wan, et al. Expires August 25, 2008 [Page 25] Internet-Draft ROHC over ULE and MPEG-2 TS frames March 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). 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. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Wan, et al. Expires August 25, 2008 [Page 26]