PPP Working Group Mooi C. Chuah Internet Draft Enrique J. Hernandez-Valencia Expires December 1999 Lucent Technologies Bell Laboratories Matt Holdrege Ascend Communications June 1999 QoS Mapping Extensions to Multilink PPP 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 the product of the Point-to-Point Protocol Extensions Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Distribution of this memo is unlimited. Abstract This document discusses QoS mapping extensions to multilink PPP. The extensions facilitate the mapping of particular flows to a given physical link and with a given PPP class. The extensions are intended to provide more flexible quality of service support for wireless networking environments. This document is the product of the Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Comments should be submitted to the ietf-ppp@merit.edu mailing list. Chuah, et al. expires December 1999 [Page 1] INTERNET DRAFT MP QoS Mapping Extensions June 1999 Applicability These extensions are intended for those implementations which desire to use the multilink PPP capability but also need to allocate specific flows to a given physical link. Table of Contents 1. Introduction ............................................... 3 2. Design Requirements ........................................ 6 2.1. Non-Sharing QoS (NS-QoS) Option .......................... 8 2.2. QoS-Map Multilink Header Format (QoS-MMHF) Option ........ 9 3. Formats of the LCP Options ................................. 9 3.1. Non-Sharing QoS Option ................................... 9 3.2. QoS-Map Multilink Header Format (QoS-MMHF) Option ........ 10 4. Security Considerations .................................... 11 5. References ................................................. 11 6. Intellectual Property Considerations ....................... 12 7. Acknowledgements ........................................... 12 8. Authors' Addresses ......................................... 12 Chuah, et al. expires December 1999 [Page 2] INTERNET DRAFT MP QoS Mapping Extensions June 1999 1. Introduction In many networking scenarios, such as in wireless networks, there are capabilities defined to instantiate multiple physical links with difference performance characteristics between two peers. To make better use of QoS capabilities implemented by various link and net- work layer protocols there is a need to map QoS indications from one layer to the other. Below is an example specific to wireless net- works. Foreign | Home AAA | AAA ^ | ^ IFA2 | | | V V MN ---- BS1 --IWF(IFA1) --- VPDSN ----- HPDSN ----- HA (GFA) (GHA) MN: Mobile Node BS: Base Station IWF: Interworking Function IFA: Intermediate Foreign Agent GHA: Gateway Home Agent GFA: Gateway Foreign Agent HPDSN: Home Packet Data Service Node VPDSN: Visiting Packet Data Service Node AAA: Authentication, Authorization, Accounting Server Figure 1: Generic Wide Area Data Network Reference Model Figure 1 shows a generic wide area wireless data network reference model. In the most general scenario of interest the MN is assumed to request IP services from a foreign wireless network other than its home service provider. Support of mobile-IP services [10] typically requires that messages are "tunneled" from the home IP network to the foreign IP network for addressing and routing purposes. The interworking functions (IWF) terminates the radio link. It is also assumed that different IWFs can communicate with one another. The communication between the Base Station (BS) and the IWF can be either by means of link-layer or network-layer messages. In this document it is assumed communications is by means of link-layer messages. The protocol stack for supporting regular IP services in a typical Chuah, et al. expires December 1999 [Page 3] INTERNET DRAFT MP QoS Mapping Extensions June 1999 wide area wireless access network is as shown in Figure 2. The current working model in Telecommunications Industry Association's (TIA) TR45.6 WG [4][5] uses PPP as the link-layer between the Termi- nal Equipment/Mobile Terminal (TE/MT) and the visiting Packet Data Service Node (PDSN). The PDSN functions are typically implemented in packet switches or routers. The MN first registers with the closest BS via link-layer messages. Then, a PPP session is activated between the MN and the visiting PDSN. Via the PPP session set up procedures, the Visiting PDSN can assign an IP address dynamically to the TE/MT. In addition, some layer 3 tunnel set up messages will be exchanged between the visiting and the home PDSNs such that a core IP tunnel will exist from the home PDSN to the visiting PDSN. This tunnel will be used to deliver packets destined for the MN. If necessary, a reverse tunnel will be set up from the visiting PDSN to the home PDSN to deliver traffic from the MN to any host within the home network. Packets destined to the mobile user can be intercepted by the home PDSN and delivered to the visiting PDSN via the core IP tunnel. The visiting PDSN in turns delivers them to the appropriate IWF via the backhaul IP tunnel if the network between the visiting PDSN and IWF is an IP network. Note that, this backhaul IP tunnel is intended to carry PPP frames. Either L2TP [9] or an enhanced version of the tun- nel establishment protocol [6] may be used to set up this backhaul IP tunnel. The IWF will then forward the packets to the appropriate base station, which then delivers them to the mobile node. Packets from the mobile node will similarly be delivered from the base station to the IWF, which forwards them to the visiting PDSN. If no reverse tun- nel exists, the packets will be forwarded to the home PDSN via regu- lar IP routing (only if packets are destined for a host within the home PDSN). Otherwise, the traffic will be carried by the reverse core IP tunnel between the visiting PDSN and the home PDSN. ----- ----------- --------- |IP | | IP | | IP | ----- ----------- --------- |PPP| |PPP | | | | ----- ---------- ------ | | | |L/M| |L/M|BHIP| |BHIP|TIP | | TIP | | | | | L2 | |L2 | L2 | | L2 | ----- ---------- ----------- --------- |WL | ----- |WL | L1 | ---- | L1 | L1 | -///- | L1 | ----- --------- ----------- --------- TE/MT IWF V-PDSN H-PDSN TE/MT: Terminal Equipment/Mobile Terminal L/M: LAC/MAC WL: Wireless Physical Link BHIP: Backhaul IP tunnel TIP: Core IP tunnel Chuah, et al. expires December 1999 [Page 4] INTERNET DRAFT MP QoS Mapping Extensions June 1999 L2: Layer 2 (Link Layer) L2: Layer 1 (Physical Link) H-PDSN: Home PDSNV-PDSN: Visiting PDSN Figure 2: Using Existing Standard with PPP as link-layer For future wireless data services, the ability to provide quality of service features is critical as more multimedia web-based applica- tions like PointCast or Netmeeting become popular. Thus, enhancing the PPP protocol to support quality of services is a very attractive option. There are existing proposals on how to provide quality of service features at the PPP layer, e.g., real-time framing [1], mul- ticlass extensions to multilink PPP [2] as well as define service mappings of the IETF Integrated Services for low-bitrate links [8]. However, these proposals do not address some important needs that arise in 3G wireless systems. Real-time framing [1] proposal is not sufficient to meet the needs of wireless data services because the PPP peers can only become aware of the different traffic classes instantiated when bearer traffic appears in the receiving interfaces. In wireless access networks, there is a need to know the class number values ahead of time to decide which type of wireless links to activate. Multiple PPP/RTF links would not be appropriate since they would be handled as independent links (with a separate IP address per physical link). Multiclass extension to multilink PPP [2] are not well-suited to TR45.6 environments due to various reasons. Among oth- ers: (a) In 3G wireless systems, a mobile user has the flexibility of activating multiple wireless links with different quality of service characteristics, e.g., one link that supports voice with no link layer retransmission, one link that supports data with link layer retransmission and another link that supports video with higher bandwidth and forward error correction. Although the multiclass extension proposal increases the number of traffic classes that may be defined over the point-to-point link, multilink PPP also bundles the separate physical point-to-point links between two entities into a single virtual link. Yet, it is not always appropriate to dissect one video packet into multiple multilink PPP fragments to send them across the multiple wireless links. For example, some of the wireless links may not be engineered to carry video fragments. What is desir- able is to have the ability to map packets from one or multiple IP sessions into one of the wireless link in the link bundle. Chuah, et al. expires December 1999 [Page 5] INTERNET DRAFT MP QoS Mapping Extensions June 1999 (b) The multilink header option in [3] only specifies the maximum number of classes for a multilink PPP session. It does not specify exactly what those classes are. It will be desirable to know ahead of time the exact class numbers that are activated at any particular time for admission control, radio resource management, and traffic engineering purposes. (c) In most standard multilink PPP implementations, each packet is fragmented and sent across multiple links. In a cellular environ- ment, a mechanism is needed to allow packets from some given ses- sions to be sent to one physical link and packets from other sessions to be sent to another physical link. In the service mapping draft [8], only guidelines on how to map pack- ets into multiple PPP Quality of Service classes are given. Again, the PPP peer cannot know the class numbers or types until it receives the bearer traffic. The draft also does not mention how to map different PPP QoS classes into different wireless links. In this document, two LCP options are defined to allow communicating interfaces to: a) send packets of a particular class number to a particular link in a link bundle b) provide upfront information on the specific classes to be supported rather than wait until packets of that class appear. The defined LCP options can work with Real-Time Framing [1], Multiclass-Multilink PPP [2] as well as the service mapping [8] drafts for can use either the real-time framing format or the multiclass-multilink PPP format for the bearer traffic. 2. Design Requirements The main design requirements are: (i) to provide a mechanism such that real-time multimedia flows can be carried over multiple PPP links (which translates to multiple wireless links of different characteristics), and (ii) to achieve quality of service requirements for each of the PPP links, (iii) consistency with existing PPP LCP functionality. In this document, two new PPP LCP options are defined to achieve the requirements described above. There are several more detailed requirements for the defined QoS mechanism: a) the scheme must be predictable enough that admission control can be made during the PPP negotiation phase. Since radio resources are often limited, a new session will be Chuah, et al. expires December 1999 [Page 6] INTERNET DRAFT MP QoS Mapping Extensions June 1999 admitted only when enough resources can be allocated to meet its quality of service requirements. In order to make this decision, the system needs to know the exact types of the different classes that will be activated over any specific link. Multilink approaches (such as Multilink PPP [3]) are more suitable than single link approaches (such as conventional PPP) for supporting multimedia services due to the following reason: A user may buy both voice-over-IP and regular internet access services. When a user activates a PPP session at timet t1, he/she may just want to activate the regular internet access (mostly web-browsing) service. This service may use, for instance, the highest class number (which denotes the lowest prior- ity treatment) for best effort service. Half-way through the activated PPP session, he/she may wish to add in the voice-over-ip service. The voice-over-IP service may be supported via the lowest class number (which denotes the highest priority treatment). If there exists sufficient resources, the voice service can be better sup- ported over a second wireless link that is optimized for voice. In 3G wireless system that supports multimedia services, radio resource management and admission control are very critical. A user may be granted 144 Kbps for conventional internet access service if it is close to the base station and has a good radio link (very lit- tle fading etc.) but only 9.6 Kbps if it is at the edge of a cell. This may be sufficient to meet the user's need. However, when a user wishes to activate a voice call, it desires to have a dedicated 9.6 Kbps in order to enjoy good voice quality. The network may decide to reduce the bandwidth allocated to the data user from 144 Kbps to 56 Kbps in order to admit in a second voice user. Thus, knowing ahead of time (before traffic packets are sent) what PPP QoS classes are using any particular PPP link help the 3G wireless system to perform better radio resource management. b) the scheme must allow packets with a particular class number(s) to be carried over a specified physical link. Using the example illustrated in (a), one may use a wireless link that does not support retransmissions to support the voice-over-IP service and a wireless link with automatic retransmission request (ARQ) to support the internet browsing service or other non-real time services. Thus, it is highly desirable to send packets of a particu- lar class number(s) via a chosen link (whose characteristics matches the quality of service requirements for that class number(s)). c) the scheme must be robust against errors d) the scheme must in general interoperate with existing PPP func- tionalities. Chuah, et al. expires December 1999 [Page 7] INTERNET DRAFT MP QoS Mapping Extensions June 1999 Two new LCP options, namely the Non-Sharing QoS Negotiation option, and the QoS-Map Multilink Header Format Option, are defined to achieve the requirements described in section 2. Below are brief descriptions of these options. 2.1. Non-Sharing QoS (NS-QoS) Option During the LCP negotiation phase, the PPP peers can include the newly defined Non-sharing QoS Option together with MRRU and End Point Discriminator Options. The Non-sharing QoS Option allows one to specify the number of classes to be carried on a particular link. Say the PPP peers first activate a link (link 1) using this Non-Sharing Qos Option and specifies that there will be 2 classes on link 1, namely classes 3 and 4. Then, the PPP peers activate 2 more links without enabling the Non-sharing QoS option. This means all PPP frames with class numbers 3 and 4 will be carried over link 1, the rest of the PPP frames will be segmented and carried over the two remaining links that do not support the Non-sharing option. Note that the bearer data (PPP frames) can use either the short or long sequence number fragment format with classes. We recommend using a different sequence number space for each physical link that supports the Non-Sharing Option. The PPP peers must have the understanding that if NS-QoS option is negotiated, then the option applies for the traffic in both direc- tion. Using the example in the earlier paragraph, it means PPP frames with class numbers 3 and 4 will be carried over link 1 in either direction. Figure 3 illustrates how the Non-Sharing QOS Option is used with standard Multilink PPP. Cls 3, Cls4 A -----------> B Cls 3, Cls4 <---------- Figure 3(a): Traffic on Link 1 between A-B with Non-Sharing Option Cls2-Frag, Cls1-Frag A -------------------> B Cls2-Frag, Cls1-Frag <------------------ B Figure 3(b): Traffic on Link 2 between A-B without Non-Sharing Option Chuah, et al. expires December 1999 [Page 8] INTERNET DRAFT MP QoS Mapping Extensions June 1999 Cls2-Frag, Cls1-Frag A -------------------> B Cls2-Frag, Cls1-Frag <------------------ B Figure 3(c): Traffic on Link 3 between A-B without Non-Sharing Option 2.2. QoS-Map Multilink Header Format (QoS-MMHF) Option To support the mapping of differentiated services PHBs and other Layer 3 fields to PPP QoS classes, another LCP option is defined: QoS-Map multilink header format option. Say both PPP peers carry IP packets with multiple DS-code points (DSCP) [7] marked, namely DSCP Code 1, DSCP Code 2, DSCP Code 3 and DSCP Code 4. Assume that there is the desire to map DSCP Code 1 and DSCP Code 2 to PPP QoS Class 1 and DSCP Code 3 and DSCP Code 4 to PPP QoS Class 2. The PPP peers use the Qos-EMHF Option to inform one another of this mapping so that they can mark the PPP frames appropriately. Without this option, both PPP peers may perform dif- ferent mapping. Equipment from different vendors may not perform the same mapping and hence it is harder to provide QoS guarantees over a PPP/MP link. 3. Formats of the LCP Options The formats of the two newly defined LCP options, namely the Non- Sharing Qos option, and the Qos-Map multilink header format option are described below. 3.1. Non-Sharing QoS Option A summary of the Non-Sharing QoS Option format is shown in figure 4. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 5 | Code |NoCls | Rsv | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | QoS BitMap | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Non-Sharing QoS Option Format Chuah, et al. expires December 1999 [Page 9] INTERNET DRAFT MP QoS Mapping Extensions June 1999 The values defined in this document for the use of this option are: - Code = 2: long sequence number packet format with classes - Code = 6: short sequence number packet format with classes - Code = 11: basic and extended compact real-time fragment format with classes, in FSE-encoded HDLC frame - Code = 15: basic compact real-time fragment format with classes, in FSE-encoded HDLC frame It is assumed that 16 PPP QoS classes are sufficient (classes 0-15 with 0 as the highest priority class). Thus, a 2-bytes bitmap is used to indicate the presence/absence of a particular class number. If the PPP peers desire to communicate the idea that there will be 3 classes on this link, namely cls 3, cls 4, and cls 5, then NoCls field will be set to 3, and the the bitmap should be set as follows: QoS BitMap Bytes 00011100 00000000 3.2. QoS-Map Multilink Header Format (QoS-MMHF) Option A summary of the QoS-Map Multilink Header Format (QoS-MMHF) Option format is shown in figure 5. The fields are transmitted from left to right. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type = TBD | Length = 7 |ClsNo|NoSD |Rsv| OptionTyp=1 | | | | = 1 | = 3 | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DSCP #1 | DSCP #2 | DSCP #3 | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ClsNo: PPP QoS Class Number NoSD: No of session descriptor associated with this PPP QoS Class Chuah, et al. expires December 1999 [Page 10] INTERNET DRAFT MP QoS Mapping Extensions June 1999 OptionTyp= 1: Session Descriptor is DSCP codepoint (1 byte) Additional OptionTyps may also be define. For example, as shown in the figure, one may define one PPP QoS No say Class 1 with session descriptor being the DSCP code point (OptionTyp=1) and map 3 DSCP code points to this PPP Class Number. Wireless Service Option Number refers to the type of wireless link that one may want to use for a particular PPP QoS class. If the receiving PPP peer cannot accept this mapping, it MUST Configure-Nak or Configure-Reject the option. Implementations SHOULD provide sufficient buffer space to accommodate different classes of services they provide each multilink PPP user with. 4. Security Considerations Many of the security issues raised by the introduction of quality of service, and primarily the potential for denial-of- service attacks, and the related potential for theft of service by unauthorized traffic are also applicable to these options. Beside the QoS-related security issues, this document introduces no other known security threats over and above those facing any node on the internet that connect via PPP. 5. References [1] C. Bormann, "PPP in a real-time oriented HDLC-like framing", ISSLL WG work in progress, , April 1999. [2] C. Bormann "The Multiclass Extension to Multilink PPP", PPPEXT WG work in progress, , June 1999. Chuah, et al. expires December 1999 [Page 11] INTERNET DRAFT MP QoS Mapping Extensions June 1999 [3] K. Slower et al., "The PPP Multilink Protocol (MP)", RFC 1990, August 1996. [4] T. Hiller et al., "3G Wireless Data Provider Architecture Using Mobile IP and AAA", , March, 1999 [5] T. Hiller, "Wireless IP Network Architecture based on IETF Protocols", TR45.6-3G/99.05.17.06. [6] P. Calhoun et al., "Tunnel Establishment Protocol", , March 1998. [7] K. Nichols et al., "Definition of the differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998. [8] S. Jackowski et al., "Integrated Services Mappings for Low Speed Networks", ISSLL WG work in progress , May 1999. [9] W. Townsley et l., "Layer Two Tunnelling Protocol," PPPEXT WG work in progress, . June 1999. [10] C. Perkins, "IP Mobility Support", RFC 2002. October 1996. 6. 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. 7. Acknowledgements The authors acknowledge useful comments from G. Armitage. 8. Authors' Addresses Mooi C. Chuah Bell Laboratories Chuah, et al. expires December 1999 [Page 12] INTERNET DRAFT MP QoS Mapping Extensions June 1999 Lucent Technologies 101, Crawfords Corner Road, 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 Chuah, et al. expires December 1999 [Page 13]