AVT Working Group Mooi C. Chuah Internet Draft Enrique J. Hernandez-Valencia Expires December 2000 Lucent Technologies Bell Laboratories June 2000 A LightWeight IP Encapsulation (LIPE) Scheme 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. This document is submitted to the Audio/Video Transport Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the rem-conf@es.net mailing list. Distribution of this memo is unlimited. Abstract Several application level compression/multiplexing solutions have been proposed in the IETF Audio/Video Transport (AVT) Working Group [1][2][9] to improve the transport efficiency of packet-voice traffic over IP-based networks. These approaches generally assume voice packets are RTP/UDP/IP encapsulated by the communicating end-points (e.g., IP phones, mobile terminal, media gateways, etc.). In some transport scenarios, using RTP/UDP/IP encapsulation for voice packet is unnecessary as only the data transfer service provided by the IP layer is required, not the media control functions. This document describes a lightweight IP encapsulation scheme to multiplex low bit rate audio (or multimedia) packets into a single UDP/IP session or IP session. The decision to multiplexing audio Chuah, et al. expires December 2000 [Page 1] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 packets at the UDP or IP layer is left as a balance between data transport efficiency and implementation complexity among the communicating end-points across a routed IP network. This document is submitted to the AVT Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the rem-conf@es.net mailing list. Chuah, et al. expires December 2000 [Page 2] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 Applicability These extensions are intended for those implementations which desire to multiplex small data packets together into one IP protocol data unit (PDU). Table of Contents Chuah, et al. expires December 2000 [Page 3] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 1. Introduction As the Internet evolves into a ubiquitous communication infrastruc- ture, IP based technologies have also become more sophisticated. As a consequence of the maturing of the IP technology, it is now evident that the previously separate data and voice networks are converging to provide integrated service, including data, voice and video. While data packets can often be quite large, voice packets are in general rather small. Codecs at the IP telephony gateway which, compress the incoming speech samples, generate packets with sizes ranging from 5 to 20 bytes per speech sample. For example, G723.1 generates a 20 bytes speech packet at 30 ms intervals [3]. Many codecs used in cellular environments generate packets of size less than 10 bytes per speech sample. Such small size packets are subjected to a large transport overhead if transfered in individual IP packets. For example a 10-byte voice packet transmitted using UDP/IP encapsulation incurs an overhead of 28 bytes (20 byte IP header, plus possibly 8 bytes UDP header), or 280%. In addition, if each audio stream uses one UDP media session, the large number of packets will create heavy packet processing load for the intermediate media gateway devices that operate above the IP-layer, even if no processing of the user flow is required. The available UDP port numbers may also become a limiting factor on the maximum number of sessions. Although the relatively high transport overhead may not constitute a critical traffic engineering factor in transport scenarios where net- work bandwidth is plentifull, the situation is quite different for many wireless access networks where T1/E1 links are used to carry packets from many voice users. There, the concept of pooling multiple user flows into a more efficienty multiplexed channel is highly appealing. Fortunately, for many applications, it is possible to multiplex a large number of sessions into a single IP packet to improve effi- ciency and scalability without incurring much multiplexing delay. For example, when long distance telephony is offered over the Inter- net, the IP telephony gateways or the mobile switching centers in a cellular network provide an interface between the existing circuit switched telephone networks (such as PSTN and cellular networks like CDMA/GSM/TDMA network) and the packet switched IP data networks. The voice calls between a pair of IP telephony gateways or the mobile switching centers can be multiplexed into a single UDP session. As another example, in a CDMA based cellular network, an IP network may be used as the access network by the wireless service provider to connect the base stations to the mobile switching centers, part of whose function is to select the reverse direction radio frames and Chuah, et al. expires December 2000 [Page 4] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 duplicate the forward direction radio frames for mobiles in soft handoff. In this case, the radio frames from different mobiles han- dled by the same base station, which can be either voice or data, can also be multiplexed into a single UDP session. Many such applications have specific delay requirements. In the first example above, the usual transfer delay and delay jitter requirements for voice application applies. In the second example, the duplicate radio frames in the reverse direction must be received by the mobile switching center within a small time window for the frame selection. RTP [4] is a protocol designed to provide various real time services to the application layer with no assumption on the underlying network providing timely delivery or quality-of-service commitments. It can be used when the network is not heavily loaded and the application it supports can adapt to the varying network conditions to some extent. To improve the transport efficiency, some multiplexing schemes have been proposed within the framework of RTP [1,2]. Many of the features of RTP are designed to provide media control information to cope with the unavailability of QoS guarantees from the underlying network at the application layer. As such guarantees become available in modern/future IP networks, some of these features become unnecessary. These features are also of limited value to non- RTP applications (e.g., most commercial wireless voice traffic). In this document, we propose to use a lightweight encapsulation scheme based on UDP/IP for multiplexing application sessions. LIPE is designed to support multimedia traffic including both voice and data. We also include some discussions on how UDP/IP header compression can be done to provide even more savings. 2. The Encapsulation Scheme The Lightweight IP Encapsulation (LIPE) uses either UDP/IP or IP as the transport layer. Each LIPE encapsulated payload consists of a variable number of multimedia data packet (MDP). For each MDP, there is a multiplexing header (MH) that conveys protocol and media specific information. The format of an IP packet conveying multiple MDPs over UDP using a minimum size MH is shown in Figure 1 (a). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ | + + + + + + + + | | IP + UDP* + MH1 + MDP1+ MH2 + MDP2+ ~ + MHn + MDPn| | (20) + (8) + (1) + + (1) + + + (1) + | Chuah, et al. expires December 2000 [Page 5] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ MH: Multiplexing Header MDP: Multimedia Data Packet (Length expressed in bytes) Figure 1 (a): Lightweight IP/UDP Encapsulation Scheme The format of an IP packet conveying multiple MDPs without UDP is and using a minimum size MH shown in Figure 1 (b). Note that a 1-byte tunnel-identifier (TID) is included when the LIPE PDUs are conveyed direcly over IP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ | + + + + + + + + | | IP + TID + MH1 + MDP1+ MH2 + MDP2+ ~ + MHn + MDPn| | (20) + (1) + (1) + + (1) + + + (1) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+ TID: Tunnel Identifier MH: Multiplexing Header MDP: Multimedia Data Packet (Length expressed in bytes) Figure 1 (b): Lightweight IP Encapsulation Scheme The generic protocol stack for LIPE, assuming PPP in HDLC-like fram- ing [RFC 1662], is as shown in Figure 2: ------ | LIPE | ------ ------ | UDP | | LIPE | ------ ------ | IP | | IP | ------ ------ | PPP | | PPP | ------ ------ | HDLC | | HDLC | ------ ------ (a) IP/UDP/LIPE (b) IP/LIPE Figure 2: Protocol Stacks for LIPE We assume that all LIPE packets on the same PPP link are encapsulated either as in Figure 1 (a) or as in Figure 1 (b), but not both simul- taneously. Section 6 explains how IPCP is used to negotiate for either type of encapsulation format. Chuah, et al. expires December 2000 [Page 6] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 2.1. Basic The Multiplexing Header (MH) comprises of two components: the Header Extension bit (the E bit) and the MDP length field. Optional Exten- sion Headers can be supported via the E bit. The MH format is shown in Figure 3. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | + + |E+ Length + Extension | + + Headers +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Figure 3: Multiplexing Header Format E bit (E bit): The Header Extension bit is the least significant bit of the MH header. It is set to one/zero to indicate the presence/absense of an extension header. If the E-bit is set to one, the first header extension MUST be a UserID header. Length: 7 bit length field. This field indicates the size of the entire MDP packet in bytes, including the E bit, Length field and optional extended headers (if they exist). 2.2. Extension Extension headers are used to convey user specific information. It also facilitates the customization of LIPE to provide additional con- trol information e.g. sequence number, voice/video quality estimator. 2.2.1. User The 16-bit User Identifier is the first field in any Extension Header. It is used to identify MDPs belonging to specific user flows. The format of a LIPE encapsulated payload with a UserID extension header is shown in Figure 4. The least significant bit of the 1st byte of UserID is the X-bit. When set to one, it indicates that the extension header is longer than 2 bytes. Thus, effectively addressing range of the UserID field is 15-bit long. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +X+ UserId | | + + + | Chuah, et al. expires December 2000 [Page 7] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <--------------------- MH ---------------------> (3 bytes) Figure 4 : A MH with a UserID field The 15-bit UserID allows up to 32768 flows to be multiplexed into a single UDP/IP session. The seemingly high number for the UserID is chosen for various reasons. First, many applications may be alive, but not active, for quite some time. These "dormant" applications will still hold on to the user identifiers. Therefore, the number of active applications that can actually contribute to the multiplexed channel may be much smaller. Second, in a mobile environment, when a mobile is handed off from one base station to another, the applica- tion on this mobile will have to be multiplexed into another UDP ses- sion in the new base station. Assuming each mobile takes up one iden- tifier, if the UserID space is large enough, it is possible to make the UserID unique to the frame handler in the mobile switching center (or Radio Network Controller). Consequently during soft handoff between base stations controlled by the same frame handler (as shown in Figure 4), there is no need to reassign UserID thus saving signal- ing cost. (IP2) ---- ------- |UE| <----- |NodeB1| SIP DIP UID= UserID ---- -------- ---------------------- ^ |IP1 |IP2|UID1 |payload | ---------------------- -------- | RNC | (IP1) SIP: Source IP address -------- DIP: Destination IP address (IP3) / ------------------------- --------/ |IP1| IP3| UID1 | payload | |NodeB2| -------------------------- -------- Figure 5: Using the same UserID in the softhandoff scenario Note that a service provider may decide to further subdivide the 15 bit UserID field into a user identifier field (e.g. 10 bits) and a Chuah, et al. expires December 2000 [Page 8] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 base station identifier field (e.g. 5 bits). Such subdivision is vendor-specific and can be done transparently (as long as the two peers understand the formats). 2.2.2. Payload If the X-bit in the UserId field is set, it means there is a Paylaod Identifier (PID) extension header following the UserID field. The Payload Identifier field starts with a 4-bit Payload Type Identifier (PTI) , a 4-bit PID Length and any additional payload specific data. The format of the PID field is illustarted in Figure 6. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + | | Type + LNGTH + Header Information | | + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6 : Format of the PID field Thus, a MH with 2-byte UserId and the PID extended header will look like Figure 7. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +1+ UserId | | + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID + PID + PID + Data | | Type + LnG=2 + Payload + Payload | | 1 + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: A MH with a UserID field and a PID field Note that one can use the PID Type to indicate different wireless access technologies e.g. PID Type = 1 indicates IS95 network, PID Type = 2 indicates UMTS network. 2.3. Examples In this section, we show some specific LIPE examples: In this example, it is assumed that each mobile terminal generates compressed RTP/UDP/IP packets. The MH header is only 1-byte long with Chuah, et al. expires December 2000 [Page 9] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 the E bit set to zero indicating that there is no extended header. The UserID is not used since the context ID [8] within the compressed RTP/UDP/IP header can uniquely identify the user. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + Compressed | + + Compressed | |0+ Length 1 + RTP/UDP/IP |0+ Length 2 + RTP/UDP/IP | | + + PDU 1 | + + PDU 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <--- MH ---> <---Payload ---> (1byte) <----------- MDP 1 -------------><---------- MDP 2 -----------> <------------- LIPE packet -------> Figure 8(a): Carrying Compressed RTP/UDP/IP packets 2.3.1. Carrying IS95 voice packets In this scenario, the E bit of the first MH header is set to one to indicate that UserId exists. The X-bit is set to one indicating that there is a PID field. 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +1+ UserId | | + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID + PID + PTI +Timing +Quality+ Seq | | Type + LnG=3 + + Info + + # | | 1 + + + + Ind + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data | | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8(b) : Carrying IS95 voice packets In the example, PID Type =1 indicates that this is IS95 voice packets and the additional extended header is 3 bytes long. The additional information carried in the extended header is the IS95 packet type (PTI), some timing information, voice quality indictor, and sequence numbers. Chuah, et al. expires December 2000 [Page 10] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 2.3.2. carrying UMTS conversational/streaming packets 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + | |1+ Length +0+ UserId | | + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | FP PDU | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <--------------------- MH ---------------------> (3 bytes) Figure 8(c): Carrying UMTS conversational/streaming packets In this scenario, the E bit is set to one and the X bit is set to zero. The UserID is used to identify the different user flows. The payload is the frame protocol (FP) PDU described in [TS25.413]. Note that in our encapsulation scheme, no field is provided in the header for error checking. Instead we rely on the IP or UDP checksum to provide for the overall IP or UDP payload error detection. We believe this level of protection is sufficient since the IP packet carrying multiplexed audio (or multimedia) frames are not carried over the air. 3. QoS Besides the traditional best-effort service, other services such as integrated service (including controlled load service and guaranteed service) and differentiated service have been defined. These ser- vices, by reserving certain network resources such as bandwidth, can provide the traffic with certain guarantees such as delay and loss. To support multiple QoS classes, we suggest using the DSCP bits of the IP header e.g. for high quality voice, we can mark the IP packet with multiplexed audio frames with EF code point; for low quality voice, we can mark it with one of the appropriate AF code points. 4. Multiplexing Policy Given the link MTU L_max, a UDP/IP packet can carry payload of up to L_max - H_ip - H_udp, where H_ip is the IP header length (20 bytes Chuah, et al. expires December 2000 [Page 11] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 without option) and H_udp is the UDP header length (8 bytes). To limit the multiplexing delay, a multiplexing timer with a lifetime of T_mux is used. H_mh is the multiplexing header length. The encapsula- tion policy is as follows: a) If the total size of the received radio frames plus that of that of their H_mh exceeds L_max - H_ip - H_udp, send all the MDP frames except the most recently received one (no fragmentation of MDP) in one UDP packet, and restart the multiplexing timer. The newly received MDP is held for multiplexing with upcoming MDPs. b) If the multiplexing timer expires, send the accumulated MDPs in one UDP packet and restart the encapsulation timer. 5. UDP/IP Header Compression Note that if IP headers are not required to do routing (say the underlying network is either ATM or MPLS), one can either remove or compress the UDP/IP (IP) header. That will increase further the bandwidth efficiency of using the LIPE scheme in a radio access net- work where the BSs have IP interfaces that run over ATM/MPLS net- works. When we map a certain UDP, or (IP+TID), tunnel into a particular MPLS/ATM connection, we need to ensure that the quality of service provided by the MPLS/ATM connection matches with the DSCP indicated in the IP header. 6. Comparison of the LIPE scheme with other existing proposals In this section, we compare 3 approaches for carrying multiplexed audio packets in terms of the overhead incurred. The 3 approaches considered are cUDP/PPPMux, tCRTP, and LIPE. We assume that PPP/HDLC is the Layer 2 technology used. Approach 1 cUDP/PPPMux PPP/HDLC 4 bytes PPP ID 1 byte per stream PFF,length 1 byte cUDP/IP 3 byte payload Approach 2 tCRTP PPP/HDLC 4 bytes cIP 3 byte L2TP HC 1 byte PPPMuxID 1 byte PPPID 1 byte per stream PFF,length 1 byte cUDP/IP 3 byte payload Chuah, et al. expires December 2000 [Page 12] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 Approach 3 LIPE PPP/HDLC 4 bytes cUDP/IP 3 byte per stream length 1 byte UID 0-2 bytes payload We see that for approach 3, the per stream overhead is 1-3 bytes while for approaches 1 & 2, the per stream overhead is 4 bytes. 7. PPP A new LCP Configuration Option is used to request LIPE operation for the PPP link. A summary of the LIPE Configuration Option format for the Link Control Protocol (LCP) is shown below. The fields are transmit- ted from left to right. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type TBD Length 3 The new LCP option is used only as a hint to the peer that LIPE operation is preferred by the sender. Support of LIPE operations is negotiated in each direction independently. Acknowledgement of the LIPE LCP Option (TBD) does not obligate a peer to transmit LIPE frames. Non LIPE-speakers SHOULD instead send LCP Configure- Reject for the option. If either LCP Configure-Nak or LCP Configure-Reject is received for this option, then the next transmitted LCP Configure-Request MUST NOT include this option. If the received LCP Configure-Request message does not contain a LIPE LCP option, an implementation MUST NOT send an unsolicited Configure-Nak for the option. (An implementation of LIPE that is already in LIPE framing mode and receives this option in an LCP Configure-Request message MAY, both for clarity and for convergence reasons, elect to send LCP Configure-Ack. It MUST NOT restart LCP nor change framing modes in this case.) Chuah, et al. expires December 2000 [Page 13] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 The size of a LIPE encapsulated frame MUST NOT exceed the maximum receive unit (MRU) size negotiated during LCP [10]. 8. Negotiating usage of LIPE When the layer 2 protocol is PPP, the usage of various LIPE confi- guration options can be negociated via the IP Compression Protocol option of IPCP: IPCP Option 2: IP configuration protocol Network Protocol: TBD indicates LIPE sub-option 1 enables use of IP session sub-option 2 enables use of UDP/IP session 9. Security This draft does not impose additional security considerations beyond those that apply to PPP and header-compression schemes over PPP. 10. Summary LIPE is designed to support multimedia traffic when certain resource guarantees are available from the underlying network. It is based on UDP/IP or IP; hence is lightweight compared with other proposals based on RTP [1,2]. As IP based networks become more and more sophis- ticated and offer various levels of resource guarantees [5], this scheme is more suitable to the modern/future IP architecture compared with RTP based schemes. The 15-bit UserID field in LIPE facilitates its usage in the third generation wireless system where handoffs may occur during the life- time of a session. By having a larger user space, we can greatly reduce the signalling overhead due to identifier re-negotiation dur- ing a handoff. A multiplexing policy is also outlined for LIPE. 11. References [1] J. Rosenberg, An RTP Payload Format for User Multiplexing work in progress, draft-ietf-avt-aggregation-00.txt [2] B. Subbiah, S. Sengodan, User Multiplexing in RTP payload between Chuah, et al. expires December 2000 [Page 14] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 IP Telephony Gateway, work in progress, draft-ietf-avt-mux-rtp-00.txt, Aug, 1998 [3] ITU-T Recommendation G.723.1 "Dual Rate Speech Coder for Multimedia Communications Transmitting At 5.3 and 6.3 Kbps", 1995 [4] H. Schulzrinne, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC 1889 [5] K. El-Khatib, G. Luo, G. Bochmann, P. Feng, Multiplexing Scheme for RTP flows between access routers, work in progress, draft-ietf-avg-multiplexing-rtp-01.txt Oct 22, 1999 [6] 3G TS 25.413 v3.1.0, 3rd Generation Partnership Project: UTRAN Iu Interface RANAP Signaling, March 2000 [7] W. Simpson, Ed.,"PPP in HDLC-like Framing", STD 5X, RFC 1662, July 1994 [8] M. Engan etc, "IP header compression over PPP", RFC 2509, Feb 1999 [9] T. Koren etc, Enhancements to IP/UDP/RTP Header Compression, work in progress, draft-koren-avt-crtp-enhance-01.txt [10] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 51, RFC 1661, July 1994. 12. Intellectual Property Considerations Lucent Technologies Inc. may own intellectual property in some on some of the technologies disclosed in this document. The patent licensing policy of Lucent Technologies Inc. with respect to any patents or patent applications relating to this submission is stated in the March 1, 1999, letter to the IETF from Dr Roger E. Stricker, Intellectual Property Vice President, Lucent Technologies, Inc. This letter is on file in the offices of the IETF Secretariat. 13. Acknowledgements 14. Authors' Addresses Mooi C. Chuah Bell Laboratories Lucent Technologies 101, Crawfords Corner Road, Chuah, et al. expires December 2000 [Page 15] INTERNET DRAFLightweight Internet Protocol Encapsulation Scheme June 2000 Holmdel, NJ 07733 chuah@bell-labs.com (732)-949-7206 Enrique J. Hernandez-Valencia Bell Laboratories Lucent Technologies 101, Crawfords Corner Road, Holmdel, NJ 07733 enrique@bell-labs.com (732)-949-6153 0 1 .ti 0 INSERT-THIS Chuah, et al. expires December 2000 [Page 16] Table of Contents 1. Introduction .................................................. 4 2. The Encapsulation Scheme ...................................... 5 2.1. Basic ....................................................... 7 2.2. Extension ................................................... 7 2.2.1. User ...................................................... 7 2.2.2. Payload ................................................... 9 2.3. Examples .................................................... 9 2.3.1. Carrying .................................................. 10 2.3.2. carrying .................................................. 11 3. QoS ........................................................... 11 4. Multiplexing Policy ........................................... 11 5. UDP/IP Header Compression ..................................... 12 6. Comparison of the LIPE scheme with other existing proposals 7. PPP ........................................................... 13 8. Negotiating usage of LIPE ..................................... 14 9. Security ...................................................... 14 10. Summary ...................................................... 14 11. References ................................................... 14 12. Intellectual Property Considerations ......................... 15 13. Acknowledgements ............................................. 15 14. Authors' Addresses ........................................... 15 TO-HERE Chuah, et al. expires December 2000 [Page 1]