PPP Working Group Mooi C. Chuah Internet Draft Enrique J. Hernandez-Valencia Expires December 2000 Lucent Technologies Bell Laboratories August 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." To view the list Internet-Draft Shadow Directories, see 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 encapsulation for voice packet is unnecessary as only the data transfer services provided by the IP layer are 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 or IP session. The decision to multiplexing audio packets at the UDP or IP layer is left as an implementation choice to balance Chuah, et al. expires March 2001 [Page 1] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 between data transport efficiency and transport implementation complexity among the communicating end-points across a routed IP network. This document is the product of the AVT Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-avt@merit.edu mailing list. Chuah, et al. expires March 2001 [Page 2] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 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 March 2001 [Page 3] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 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 communications services, including data, voice and video. While data packets can often be quite large, voice pack- ets are in general rather small. Codecs in IP phones or IP telephony gateways compress the incoming speech samples and generate speech frames with sizes ranging from 5 to 20 bytes per speech sample. For example, G723.1 generates a 20-byte speech frame at 30 ms intervals [3]. Many codecs used in cellular environments generate speech frames of size less than 10 bytes per speech sample. Such small speech frame sizes are subject to a large transport over- head if transferred in individual IP packets. For example a 10-byte voice packet transmitted using UDP/IP encapsulation incurs an over- head 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 actually 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 reaources are plentifull, the situation is quite different for many wireless access networks where T1/E1 links are used to carry packets from many voice users to the base stations. There, the con- cept of pooling multiple user flows into a more efficienty multi- plexed 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 March 2001 [Page 4] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 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 stringent delay requirements. In the first example above, the usual transfer delay and delay jitter requirements for voice application apply. 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 incorporated within LIPE to further improve encapsulation effi- ciency. 2. The LIPE 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 transport 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). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chuah, et al. expires March 2001 [Page 5] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 | + + + + + + + + | | IP + UDP + MH1 + MDP1 + MH2 + MDP2 + ~ + MHn + MDPn | | (20) + (8) + (1) + + (1) + + + (1) + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ MH: Multiplexing Header MDP: Multimedia Data Packet Figure 1 (a): Lightweight IP/UDP Encapsulation Scheme (Field lenths expressed in bytes) 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 Figure 1 (b): Lightweight IP Encapsulation Scheme (Field lengths expressed in bytes) 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 All LIPE packets on the same PPP link MUST use either the LIPE/IP encapsulation depicted in Figure 1 (a), or the LIPE/UDP/IP Chuah, et al. expires March 2001 [Page 6] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 encapsulation depicted in Figure 1 (b), but not both encapsulation types simultaneously. Section 6 explains how IPCP is used to nego- tiate for either type of encapsulation format. 2.1. Basic The Multiplexing Header (MH) comprises of two components: the MDP Header Extension bit (the E bit) and the MDP length field. Optional Extension Headers can be supported via the E bit. The MH format is shown in Figure 3. 1 2 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + Extended | |E+ MDP + Headers | | + Length + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: Multiplexing Header Format 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 longer than 2 bytes. If the E bit is set to zero, the multiplexed header contains a 7 bit MDP length and a 2 bytes extended header identifier. If the E bit is set to one, it means there are more fields after the 2-byte Extended Header. MDP Length: a 7 bit MDP length field. This field indicates the size of the entire MDP packet in bytes including the E bit, Length field and optional Extension Headers (if present). For Type 0 Extended Header, the actual length is as indicated in the 7 bit field. For Type 1 Extended Header, the actual length is 4 times the number expressed in the 7 bit field. 2.2. Extension Extension Headers are used to convey application specific informa- tion. They also facilitate customization of LIPE to incorporate addi- tional transport/session level control functionality such as sequence number, voice/video quality estimator. 2.2.1. Type 0 Extended Header The 16-bit Type 0 Extended Header (EH0) is the first Chuah, et al. expires March 2001 [Page 7] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 field in any Extension Header. It is used to identify MDPs belonging to specific small voice/video flows. The format of an LIPE encapsu- lated payload with a EH0 Extension Header is shown in Figure 4(a). 1 2 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + | |0+ Length +X+ CRC + UserId | | + + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MDPn Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4(a) : A MH with a Type 0 EH When X bit is clear, the following 3 bits are used as the CRC for the Extended Header. This means the UserID field is 12 bits. This version is used mostly for applications that generate small packets e.g. voice. The 12-bit UserID allows up to 4096 flows to be multiplexed into a single UDP/IP session or IP tunnel. 2.2.2. Type 1 Extended Header The 16-bit Type 1 Extended Header (EH1) is used to identify flows that generate large data packets. The format of an LIPE encapsulated payload with a Type 1 Extension Header is shown in Figure 4(b). The least significant bit of the 1st byte of EH1 is the X bit. When X is set to one, it indicates that a EOF bit and a 3-bit Seq Number fields exist. This means when X bit is set, the UserID field is 11-bit. The EOF bit is set when there are more fragments to be transmitted. For the non-fragment case, this bit is clear. 1 2 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + +E+Seq + | |1+ Length +X+O+ No + UserId | | + + +F+ + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | MDPn Payload | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chuah, et al. expires March 2001 [Page 8] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 Figure 4(b) : A MH with a Type 1 EH 2.2.3. Payload Identifier If the E-bit is set, it means there is a Paylaod Identifier (PID) extension header following the Multiplexed Header Identifier field. The Payload Identifier field starts with a 4-bit Payload Type Iden- tifier (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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + PID + | | PTI + LNGTH + Header Information | | + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 : Format of the PID field Thus, a MH with a Type 0 Multiplexed Header and the PID extended header will look like 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + | |1+ Length +0+ CRC + UserId | | + + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PID + PID + PID + Data | | Type + LnG=2 + Payload + Payload | | 1 + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: 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: 2.3.1. Carrying IS95 voice frames In this scenario, the E bit of the first MH header is set to zero to Chuah, et al. expires March 2001 [Page 9] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 indicate that there is no PID field. Type 0 extended header is used. 1 2 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + | |0+ Length +0+CRC + UserId | | + + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | User | | Payload | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7(a) : Carrying raw IS95 voice packets 2.3.2. carrying UMTS Interactive Data Packets 1 2 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + + + + Seq + | |0+ Length +1+0+ No + UserId | | + + + + + | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | FP PDU | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7(b): Carrying UMTS Interactive Data packets In this scenario, Type 1 Extended Header is used where the E bit is set to one and the X bit is set to one. The UserID is used to identify 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 purposes for data traffic. For this scenario, we rely on the link layer error detection capability (e.g., CRC field in HDLC or ATM/AAL5) for LIPE/IP, or on the additional UDP checksum on LIPE/UDP/IP to provide for the overall LIPE payload error detection. We believe this level of protection is sufficient. For voice frames where multiplexing of packets from different users usu- ally take place, a header CRC is provided as an additional protection so that voice frames from different users can be salvaged should Chuah, et al. expires March 2001 [Page 10] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 remaining bit errors exist. 2.4. LIPE LIPE end-points need a mechanism to specify and negotiate UserID and TunnelID/UDP Destination port numbers. When LIPE/UDP/IP encapsulation is used, a specified Destination Port number is used to indicate the LIPE Signaling Channel. The format of the LIPE signaling message over this channel is illustrated in Figure 8 (a). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ | + + + + | | IP + UDP + Type + LNG + Control Msg Payload | | (20) + (8) +(4bits)+(4bits)+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ Figure 8 (a): LIPE Signaling Channel Message Format for IP/UDP Encapsulation Here, the UDP Port Number identifies the LIPE Signaling Channel, the 4-bit LIPE Signaling Channel Type field is used to identify the LIPE Control Message Type, and the 4-bit Length (LNG) field identifies the length of Control Msg Payload expressed in bytes. When LIPE/IP encapsulation is used, a specified TunnelID number is used to indicate the LIPE signaling Channel. The format of the LIPE signaling message is illustrated in Figure 8 (b). +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ | + + + + | | IP +TunID +Type + LNG + Control Msg Payload | | (20) +(Sig ) +(4bits)+(4bits)+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+ Figure 8 (b): LIPE Signaling Channel Message Format for IP Encapsulation Here, the TunnelID field identifies the LIPE Signaling Channel, the 4-bit Type field is used to identiofy the Control Message Type, and the 4-bit (LNG) field is used to indicate the length of Control Msg Payload expressed in bytes. Three types of control messages are currently defined: Type = 0 Length= 1 Control Msg Payload = Tunnel id Type = 1 Length=12 Control Msg Payload = IMSI (10 bytes), UserId (2 bytes) Type = 2 Length=13 Chuah, et al. expires March 2001 [Page 11] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 Control Msg Payload = IMSI (10 bytes), UserId (2 bytes), Sequence Number. Type 2 message can be used to transfer sequence number when there is a handoff from one RNC to another. 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. LIPE is compatible with both the DifServ and IntServ QoS models. To support multiple QoS classes, the DSCP bits of the IP header can be used to request a particular PHB e.g., for high quality voice the IP packet with multiplexed audio frames can be marked with the EF code point; for low quality voice, the IP packet can be marked with one of the appropriate AF code points. LIPE specific QoS requirements may also be conveyed on an end-point specific basis via the TunnelID or UserID field. 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 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. Chuah, et al. expires March 2001 [Page 12] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 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 This section compares 3 approaches for carrying multiplexed audio packets in terms of the overhead incurred. The 3 approaches con- sidered 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 Approach 3 LIPE PPP/HDLC 4 bytes cUDP/IP 3 byte per stream length 1 byte UID 2 bytes payload Chuah, et al. expires March 2001 [Page 13] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 For approach 3, the per stream overhead is 3 bytes while for approaches 1 & 2, the per stream overhead is 4 bytes. 7. PPP A new IPCP Configuration Option is used to request LIPE operation for the PPP link. A summary of the LIPE Configuration Option format for the IP Control Protocol (IPCP) 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 IPCP 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 IPCP Option (TBD) does not obligate a peer to transmit LIPE frames. Non LIPE-speakers SHOULD instead send IPCP Configure- Reject for the option. If either IPCP Configure-Nak or IPCP Configure-Reject is received for this option, then the next transmitted IPCP Configure-Request MUST NOT include this option. If the received IPCP Configure-Request mes- sage does not contain a LIPE IPCP 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 IPCP Configure-Request message MAY, both for clarity and for convergence reasons, elect to send IPCP Configure-Ack. It MUST NOT restart IPCP nor change framing modes in this case.) The size of a LIPE encapsulated frame MUST NOT exceed the maximum receive unit (MRU) size negotiated during LCP [10]. Chuah, et al. expires March 2001 [Page 14] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 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 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 Chuah, et al. expires March 2001 [Page 15] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 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, Holmdel, NJ 07733 chuah@bell-labs.com (732)-949-7206 Chuah, et al. expires March 2001 [Page 16] INTERNET DRAFLightweight Internet Protocol Encapsulation SchemeAugust 2000 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 March 2001 [Page 17] Table of Contents 1. Introduction .................................................. 4 2. The LIPE Encapsulation Scheme ................................. 5 2.1. Basic ....................................................... 7 2.2. Extension ................................................... 7 2.2.1. Type ...................................................... 7 2.2.2. Type ...................................................... 8 2.2.3. Payload ................................................... 9 2.3. Examples .................................................... 9 2.3.1. Carrying .................................................. 9 2.3.2. carrying .................................................. 10 2.4. LIPE ........................................................ 11 3. QoS ........................................................... 12 4. Multiplexing Policy ........................................... 12 5. UDP/IP Header Compression ..................................... 13 6. Comparison of the LIPE scheme with other existing proposals 7. PPP ........................................................... 14 8. Negotiating usage of LIPE ..................................... 15 9. Security ...................................................... 15 10. Summary ...................................................... 15 11. References ................................................... 15 12. Intellectual Property Considerations ......................... 16 13. Acknowledgements ............................................. 16 14. Authors' Addresses ........................................... 16 TO-HERE Chuah, et al. expires March 2001 [Page 1]