IETF Next Steps in Signaling S. Jeong Working Group HUFS Internet-Draft S. Lee Expires: November 18, 2005 J. Bang BJ. Lee Samsung AIT May 17, 2005 3GPP QoS Model for Networks Using 3GPP QoS Classes draft-jeong-nsis-3gpp-qosm-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 November 19, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract QoS interworking between 3GPP wireless and non-3GPP wireline networks will be essential if future IP-based next generation networks are to provide assured-quality end-to-end IP flows. This draft discusses how to achieve QoS interoperability between 3GPP based wireless networks and IETF/ITU-T based wireline IP networks. In particular, Jeong, et al. Expires November 18, 2005 [Page 1] Internet-Draft 3GPP QoS Model May 2005 this draft tries to describe a QoS-NSLP QoS model (QOSM) based on 3GPP QoS classes and bearer service attributes. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. 3GPP QoS Classes and Bearer Service Attributes . . . . . . . . 4 3.1 Summary of 3GPP QoS Classes . . . . . . . . . . . . . . . 4 3.1.1 Mapping between the TS 23.107 and Y.1541 QoS Classes . . . . . . . . . . . . . . . . . . . . . . . 5 3.1.2 Mapping between the TS 23.107 and DiffServ QoS Classes . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 QoS Attributes for 3GPP UMTS Bearer Services . . . . . . . 6 4. Additional QSPEC Parameters for 3GPP QOSM . . . . . . . . . . 9 4.1 Token Bucket Extension . . . . . . . . . . . . . . . . . . 9 4.2 Residual Bit Error Ratio . . . . . . . . . . . . . . . . . 10 4.3 Delivery of Erroneous SDU . . . . . . . . . . . . . . . . 10 4.4 Source Statistics Descriptor . . . . . . . . . . . . . . . 10 4.5 Signaling Indication . . . . . . . . . . . . . . . . . . . 11 5. Scenarios for End-to-End QoS Support . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 14 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 9.1 Normative References . . . . . . . . . . . . . . . . . . . 14 9.2 Informative References . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 17 Jeong, et al. Expires November 18, 2005 [Page 2] Internet-Draft 3GPP QoS Model May 2005 1. Requirements notation 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 [1]. 2. Introduction The NSIS working group is standardizing a signaling protocol suite with QoS signaling as the first use case. The overall signaling protocol suite is decomposed into a generic lower layer with separate upper layers for signaling applications. The upper layer protocol, called NSIS Signaling Layer Protocol (NSLP), has an end-to-end scope and contains application specific functionality. QoS-NSLP [2] which is an NSLP for QoS Signaling defines message types and control information generic to all QoS models (QOSMs). A QOSM is a defined mechanism for achieving QoS as a whole. The specification of a QOSM includes a description of its QSPEC parameter information and how that information should be treated or interpreted in the network. The QSPEC contains a set of parameters and values describing the requested resources [3]. The QSPEC object also contains control information and the QoS parameters defined by the QOSM. A QOSM provides a specific set of parameters to be carried in the QSPEC. At each QoS NSIS Entity (QNE), its contents are interpreted by the resource management function (RMF) for policy control and traffic control (including admission control and configuration of the packet classifier and scheduler). Figure 1 shows a network environment where there are multiple different QOSMs [3]. One of the representative XG QOSMs shown in the figure could be 3GPP QOSM. +----------+ /-------\ /--------\ /--------\ | Laptop | | Home | | Cable | | Diffserv | | Computer |-----| Network |-----| Network |-----| Network |----+ +----------+ | No QOSM | |DQOS QOSM | | RMD QOSM | | \-------/ \--------/ \--------/ | | +-----------------------------------------------+ | | /--------\ +----------+ | | "X"G | | Handheld | +---| Wireless |-----| Device | | XG QOSM | +----------+ \--------/ Figure 1. An Example Configuration with Multiple Different QOSMs Jeong, et al. Expires November 18, 2005 [Page 3] Internet-Draft 3GPP QoS Model May 2005 QoS interworking between 3GPP wireless and non-3GPP wireline networks will be essential if future IP-based next generation networks are to provide assured-quality end-to-end IP flows. This draft discusses how to achieve QoS interoperability between 3GPP-based wireless networks and IETF/ITU-T based wireline IP networks. In particular, this draft tries to describe a QoS-NSLP QoS model (QOSM) based on 3GPP QoS classes and bearer service attributes. 3GPP TS 23.107 [5] specifies four universal mobile telecommunications system (UMTS) QoS classes (also called "traffic classes"), and the 3GPP-QOSM extensions include additional QSPEC parameters which may be optional. The more detailed description of the 3GPP QOSM will be provided in the later version of this draft. 3. 3GPP QoS Classes and Bearer Service Attributes 3GPP TS 23.107 specifies four different QoS classes for UMTS, and these QoS classes support a wide range of user applications. TS 23.107 also describes specific value ranges for each QoS class. 3GPP TS 203.207 [6] specifies the architecture and procedures for achieving end-to-end QoS across networks with the 3GPP QoS classes as a basis. QSPEC in [3] already addresses most of generic QoS parameters, and therefore this draft identifies additional QSPEC parameters for the 3GPP QOSM. 3.1 Summary of 3GPP QoS Classes 3GPP UMTS QoS classes were defined in [5] by taking the restrictions and limitations of the air interface into account. The QoS mechanisms provided in the cellular network have to be robust and capable of providing reasonable QoS resolution. As mentioned above, there are four different QoS classes, i.e., Conversational class, Streaming class, Interactive class, and Background class. The main distinguishing factor between these QoS classes is how delay sensitive the traffic is. For example, Conversational class is meant for traffic which is very delay sensitive while Background class is the most delay insensitive traffic class. Conversational and Streaming classes are mainly intended to be used to carry real-time traffic flows. The main divider between them is how delay sensitive the traffic is. Conversational real-time services, like video telephony, are the most delay sensitive applications and those data streams should be carried in Conversational class. Interactive and Background classes are mainly meant to be used by traditional Internet applications like WWW, E-mail, Telnet, FTP, and Jeong, et al. Expires November 18, 2005 [Page 4] Internet-Draft 3GPP QoS Model May 2005 News. Due to looser delay requirements, compared to Conversational and Streaming classes, both provide better error rate by means of channel coding and retransmission. The main difference between Interactive and Background classes is that Interactive class is mainly used by interactive applications, e.g., interactive e-mail or interactive web browsing, while Background class is meant for background traffic, e.g., background download of e-mail or background file downloading. Traffic in the Interactive class has higher priority in scheduling than Background class traffic, so background applications use transmission resources only when interactive applications do not need them. This is very important in wireless environment where the bandwidth is scarce compared to fixed networks. To achieve QoS interoperability for end-to-end QoS, the mappings between 3GPP QoS classes (defined in TS 23.107) and non-3GPP QoS Classes such as Y.1541 and DiffServ classes will be essential. The following two subsections illustrate possible mappings between them. Detailed mappings will be implementation specific. 3.1.1 Mapping between the TS 23.107 and Y.1541 QoS Classes Y.1541 proposes six QoS classes defined according to the desired QoS performance objectives [4]. These QoS classes support a wide range of user applications. The QoS classes group performance objectives for one-way IP packet delay (IPTD), IP packet delay variation (IPDV), IP packet loss ratio (IPLR), and IP Error Ratio (IPER). Classes 0 and 1 support interactive real-time applications, and Classes 2, 3, and 4, support non-interactive applications. Class 5 has all the QoS parameters unspecified. These classes serve as a basis for agreements between end-users and service providers, and between service providers. They support a wide range of traffic applications including point-to-point telephony, data transfer, multimedia conferencing, and others. The limited number of classes supports the requirement for feasible implementation, particularly with respect to scale in global networks. Based on the definitions of the QoS Classes, the 3GPP Conversational and Streaming classes may correspond to Y.1541 classes 0 and 1, respectively. The two classes of Y.1541 and TS 23.107 are intended to support real-time services. The Conversational class and Y.1541 class 0 have a more stringent latency requirement than the Streaming class and Y.1541 class 1. In both specifications, jitter is intended to be limited. In addition, the 3GPP Interactive class may correspond to Y.1541 classes 2, 3, and 4, and one of the relevant applications is interactive data. 3.1.2 Mapping between the TS 23.107 and DiffServ QoS Classes Jeong, et al. Expires November 18, 2005 [Page 5] Internet-Draft 3GPP QoS Model May 2005 DiffServ [9] proposes differentiation in the queuing and forwarding treatment received by packets at the routers in the network domain, on the basis of DiffServ Code Points (DSCPs) included in their headers at the ingress of the network domain. IETF has standardized two groups of behavior aggregates, namely expedited forwarding or EF (one class) and assured forwarding or AF (four classes each containing three drop-precedence levels). The actual policies used for marking, queuing and forwarding of packets at routers in DiffServ domain is an implementation-specific issue. EF per-hop behavior (PHB) group has been defined with the intention of providing leased-line like service using DiffServ. This is achieved by regulating the total rate of all the flows registered with the EF PHB class to be less than the service rate allocated to the EF PHB class at that node. Strict policing is enforced on the flows, and any non-conforming packets are dropped at the ingress itself. The AF PHB group has provision for classifying packets into different precedence levels. Three such levels have been specified and each level is associated with a drop precedence. Thus, each AF class has three DSCPs reserved, one for each level. AF PHB group defines a relationship between these three precedence levels. If congestion occurs at a particular forwarding node, a packet with the lowest drop precedence must have the lowest probability of being dropped. Likewise, a packet with the highest drop precedence has the highest probability of dropping. Based on the definitions of the QoS Classes, it appears that the 3GPP Conversational class corresponds to EF PHB class which can support low latency and jitter, and the 3GPP Streaming class corresponds to AF 4 which can support low jitter. The 3GPP Interactive class may correspond to AF 3 (which can support low latency (but not as low as in conversational class)), and the Background class may correspond to AF2, AF1, or BE PHB class (which does not impose any special QoS requirement except reliability). 3.2 QoS Attributes for 3GPP UMTS Bearer Services UMTS bearer service attributes describe the service provided by the UMTS network to the user of the UMTS bearer service. A set of QoS attributes (QoS profile) are described below [5]. (a) Traffic class: Traffic class represents the type of application (i.e., 'conversational', 'streaming', 'interactive', or 'background') for which the UMTS bearer service is optimized. By including the traffic class itself as an attribute, UMTS can make assumptions about the traffic source and optimize the transport Jeong, et al. Expires November 18, 2005 [Page 6] Internet-Draft 3GPP QoS Model May 2005 for that traffic type. (b) Maximum bitrate (kbps): Maximum bitrate represents the maximum number of bits delivered by UMTS within a period of time, divided by the duration of the period. The traffic is conformant with Maximum bitrate as long as it follows a token bucket algorithm where token rate equals Maximum bitrate. The Maximum bitrate is the upper limit a user or application can accept or provide. All UMTS bearer service attributes may be fulfilled for traffic up to the Maximum bitrate depending on the network conditions. (c) Guaranteed bitrate (kbps): Guaranteed bitrate represents the guaranteed number of bits delivered by UMTS within a period of time, divided by the duration of the period. The traffic is conformant with the guaranteed bitrate as long as it follows a token bucket algorithm where token rate equals Guaranteed bitrate. UMTS bearer service attributes, e.g., delay and reliability attributes, are guaranteed for traffic up to the Guaranteed bitrate. For the traffic exceeding the Guaranteed bitrate the UMTS bearer service attributes are not guaranteed. This attribute describes the bitrate the UMTS bearer service shall guarantee to the user or application. Guaranteed bitrate may be used to facilitate admission control based on available resources, and for resource allocation within UMTS. (d) Delivery order (y/n): Delivery order indicates whether the UMTS bearer shall provide in-sequence service data unit (SDU) delivery or not. The SDU may correspond to an IP packet. This attribute is derived from the user protocol (i.e., packet data protocol (PDP) type) and specifies if out-of-sequence SDUs are acceptable or not. Whether out-of-sequence SDUs are dropped or re-ordered depends on the specified reliability Delivery order should be set to 'no' for PDP Type = 'IPv4' or 'IPv6'. (e) Maximum SDU size (octets): Maximum SDU size represents the maximum SDU size for which the network shall satisfy the negotiated QoS. The maximum SDU size is used for admission control and policing and/or optimizing transport. Handling by the network of packets larger than Maximum SDU size is implementation specific (e.g., they may be dropped or forwarded with decreased QoS). (f) SDU format information (bits): SDU format information represents the list of possible exact sizes of SDUs. The radio access network (RAN) needs SDU size information to be able to operate in transparent radio link control (RLC) protocol mode, which is beneficial to spectral efficiency and delay when RLC re- transmission is not used. Thus, if the application can specify Jeong, et al. Expires November 18, 2005 [Page 7] Internet-Draft 3GPP QoS Model May 2005 SDU sizes, the bearer is less expensive. (d) SDU error ratio: SDU error ratio indicates the fraction of SDUs lost or detected as erroneous. SDU error ratio is defined only for conforming traffic. By reserving resources, SDU error ratio performance is independent of the loading conditions, whereas without reserved resources, such as in Interactive and Background classes, SDU error ratio is used as target value. This attribute is used to configure the protocols, algorithms and error detection schemes. (h) Residual bit error ratio: Residual bit error ratio indicates the undetected bit error ratio in the delivered SDUs. If no error detection is requested, Residual bit error ratio indicates the bit error ratio in the delivered SDUs. This attribute is used to configure radio interface protocols, algorithms and error detection coding. (i) Delivery of erroneous SDUs (y/n/-): Delivery of erroneous SDUs indicates whether SDUs detected as erroneous shall be delivered or discarded. 'yes' implies that error detection is employed and that erroneous SDUs are delivered together with an error indication, 'no' implies that error detection is employed and that erroneous SDUs are discarded, and '-' implies that SDUs are delivered without considering error detection. This attribute is used to decide whether error detection is needed and whether frames with detected errors shall be forwarded or not. (j) Transfer delay (ms): Transfer delay indicates maximum delay for 95th percentile of the distribution of delay for all delivered SDUs during the lifetime of a bearer service. This attribute is related to the delay tolerated by the application. In conjunction with the SDU error ratio attribute, care needs to be taken in deriving the value for the 95th percentile when an application desires, for example, that 99.9% of all transmitted packets are delivered within a certain time. This attribute allows RAN to set transport formats and ARQ parameters. (k) Traffic handling priority: Traffic handling priority specifies the relative importance for handling of all SDUs belonging to the UMTS bearer compared to the SDUs of other bearers. Within the interactive class, there is a definite need to differentiate between bearer qualities. This is handled by using the traffic handling priority attribute, to allow UMTS to schedule traffic accordingly. By definition, priority is an alternative to absolute guarantees, and thus these two attribute types cannot be used together for a single bearer. Jeong, et al. Expires November 18, 2005 [Page 8] Internet-Draft 3GPP QoS Model May 2005 (l) Allocation/Retention Priority: Allocation/Retention Priority specifies the relative importance compared to other UMTS bearers for allocation and retention of the UMTS bearer. Priority is used for differentiating between bearers when performing allocation and retention of a bearer. In situations where resources are scarce, the relevant network elements can use the Allocation/Retention Priority to prioritize bearers with a high Allocation/Retention Priority over bearers with a low Allocation/Retention Priority when performing admission control. (m) Source statistics descriptor ('speech'/'unknown'): Source statistics descriptor specifies characteristics of the source of submitted SDUs. Conversational speech has a well-known statistical behaviour. By being informed that the SDUs for a UMTS bearer are generated by a speech source, RAN, the serving GPRS support node (SGSN) and the gateway GPRS support node (GGSN) and also the user equipment (UE) may, based on experience, calculate a statistical multiplex gain for use in admission control on the relevant interfaces. (n) Signaling Indication (Yes/No): Signaling Indication indicates the signaling nature of the submitted SDUs. This attribute is additional to the other QoS attributes and does not over-ride them. This attribute is only defined for the interactive traffic class. If signaling indication is set to 'Yes', the UE should set the traffic handling priority to '1'. Signaling traffic can have different characteristics to other interactive traffic, e.g., higher priority, lower delay, and so on. This attribute permits enhancing the RAN operation accordingly. 4. Additional QSPEC Parameters for 3GPP QOSM Among the attributes described in Section 3, most of relevant attributes for QSPEC have been specified in [3]. Additional parameters which may need to be specified further include Guaranteed bitrate, Source statistics descriptor, Delivery of erroneous SDUs, Residual bit error ratio, and Signaling Indication. This section briefly describes the format of these additional parameters which may be optional in QSPEC. More detailed description and other possible parameters will be provided in the later version of this draft. 4.1 Token Bucket Extension The parameter, "Guaranteed bitrate (Gbr)" is represented by a floating point number in the single-precision IEEE floating point format. Jeong, et al. Expires November 18, 2005 [Page 9] Internet-Draft 3GPP QoS Model May 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Guaranteed Bit Rate [Gbr] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The sign bit MUST be zero (all values MUST be non-negative) and Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying the rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeroes. 4.2 Residual Bit Error Ratio Residual Bit Error Ratio (BER) is represented as a 32-bit integer as shown below. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Residual Bit Error Ratio (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3 Delivery of Erroneous SDU Delivery of Erroneous SDU (DES) (2 bits) parameter is represented as follows. +------------+ | DES(2bits) | +------------+ Three values of DES are listed below to indicate different meanings. 0 - 'No' 1 - 'Yes' 2 - '-' 4.4 Source Statistics Descriptor Source statistics descriptor (SSD) parameter is represented as follows. Different sources has a different value. Jeong, et al. Expires November 18, 2005 [Page 10] Internet-Draft 3GPP QoS Model May 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source statistics descriptor [SSD] (32 bit) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.5 Signaling Indication Signaling Indication (SI) parameter is represented as follows. +-----------+ | SI (1bit) | +-----------+ Two values of SI are listed below to indicate different meanings. 0 - 'No' 1 - 'Yes' 5. Scenarios for End-to-End QoS Support This section describes end-to-end scenarios that may occur from a UE connected to a UTMS network. The Figure 2 shows a network architecture [6] used to explain the scenario which illustrates how end-to-end QoS is delivered in the network environment where 3GPP and non-3GPP networks co-exist. ^ +-----+ +----+ +------+ +------+ IP | | | IP Bearer | | //------\\ | | | | Bearer | | | Service | | | | | | | | Layer | | |<----------| |-+---------+-| |-->| | V |Local| | | | | |Remote| |Remote| ============|UE |===========|GGSN| | Backbone| |Access|===|Host | Access ^ | | | | | IP | |Point | | | Bearer | | | +----+ | | | Network | | | | | Layer | | |<-|SGSN|-->| | | | | |<->| | (eg. UMTS | | | +----+ | | \\------// | | | | Bearer) V +-----+ +----+ +------+ +------+ ^ ^ +............+ Scope of PDP Context Jeong, et al. Expires November 18, 2005 [Page 11] Internet-Draft 3GPP QoS Model May 2005 Figure 2. An End-to-End Network Architecture It is assumed that the UE performs an IP bearer service (BS) manager function which enables end-to-end QoS using IP-based signaling (e.g., NSIS signaling) towards the remote end. It is also assumed that the GGSN supports DiffServ edge functions, and that the backbone IP network is DiffServ enabled. The application layer (e.g., SIP/SDP) between the end hosts identifies the QoS requirements. The QoS requirements from application layer are mapped down to create an NSIS session. The UE shall establish the PDP context suitable for support of the NSIS session. The GGSN may use information regarding the PDP context in order to select the appropriate DiffSer setting to apply. It may be possible for the GGSN to support the mappting between TS 23.107 and Y.1541 QoS classes. UE GGSN Remote AP Remote Host | | | | | Application Layer (eg. SIP/SDP) | |<...............................................>| | | | | | NSIS Signalling | |...........................+-------------------->| Uplink Data | | | | | | DiffServ | |....................+------+-------------------->| | | | | | PDP Flow | | | |------------------->| | | | | | | ================================================================== | | | | | Application Layer (eg. SIP/SDP) | |<...............................................>| | | | | | NSIS Signalling | |<..........................|<--------------------+ Downlink Data| | | | | | DiffServ | |<...................|<-----+---------------------+ | | | | | PDP Flow | | | |<-------------------+ | | | | | | Figure 3. An End-to-End Scenario Jeong, et al. Expires November 18, 2005 [Page 12] Internet-Draft 3GPP QoS Model May 2005 The control of the QoS over the UMTS access network (from the UE to the GGSN) may be performed either from the terminal using the PDP context signaling. Alternatively, subscription data accessed by the SGSN may override the QoS requested via signaling from the UE. In this scenario, the terminal supports signaling via the NSIS protocol to control the QoS at the local and remote accesses. The QoS for the wireless access is provided by the PDP context. The UE may control the wireless QoS through signaling for the PDP context. The characteristics for the PDP context can be derived from the NSIS signaling information. The end-to-end QoS is provided by a local mechanism in the UE, the PDP context over the UMTS access network, DiffServ through the backbone IP network, and DiffServ in the remote access network in the scenario shown in Figures 2 and 3. The NSIS signaling may control the QoS at both the local and remote accesses. This function may be used to determine the characteristics for the PDP context, so the UE may perform the interworking between the NSIS signaling and PDP context. The UE may provide control of the DiffServ (although this may be overwritten by the GGSN), and in effect, determine the appropriate interworking between the PDP context and DiffServ. An example scenario for end-to-end QoS signaling is described below. - The UE sends an Activate (Secondary) PDP Context message to the SGSN with the UMTS QoS parameters, and the SGSN sends the corresponding Create PDP Context message to the GGSN. - The GGSN authorizes the PDP context activation request according to the local operator's IP bearer resource based policy, the local operator's admission control function and the GPRS roaming agreements and sends a Create PDP Context Response message back to the SGSN. - The radio access bearer (RAB) setup is done by the RAB assignment procedure, and the SGSN sends an Activate (Secondary) PDP Context Accept message to UE. - Upon receiving the Activation PDP Context Accept message, the QoS- NSLP at the UE as a QoS NSIS Initiator (QNI) sends a QoS-NSLP RESERVE message containing the Initiator QSPEC to the next hop in the external IP network through the GGSN. The Initiator QSPEC specifies parameters specific to the 3GPP QOSM and other generic QSPEC parameters for the flow. The GGSN processes the NSIS RESERVE message based on the PDP context and performs the translation function for mapping between UMTS QoS classes and DiffServ classes. Jeong, et al. Expires November 18, 2005 [Page 13] Internet-Draft 3GPP QoS Model May 2005 In the example above, the Create PDP Context Request message was created before sending the NSIS message. However, it is also possible to trigger the Create PDP Context Request message after receiving the RESERVE message. Note that QoS mapping between the UMTS and DiffServ QoS classes may occur at the UE and GGSN. The signaling procedure for QoS interworking between Y.1541 and UMTS QoS Classes may be similar to the procedure described above. 6. Security Considerations There are no new security considerations based on this draft at the moment. Security considerations will be provided in the later version of this draft, if any. 7. IANA Considerations This section provides guidance to the Internet Assigned Numbers Authority (IANA) regarding registration of values related to the QSPEC template, in accordance with BCP 26 RFC 2434 [RFC2434]. [2] requires IANA to create a new registry for QoS Model Identifiers. The QoS Model Identifier (QOSM ID) is a 32-bit value carried in a QSPEC object. The allocation policy for new QOSM IDs is TBD. This document also defines five new objects for the QSPEC Template, as detailed in Section 4. Values are to be assigned for them from the NTLP Object Type registry. 8. Acknowledgements The authors thank Jerry Ash and Al Morton for very helpful comments and discussion. 9. References 9.1 Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Bosch, S., Karagiannis, G., and A. McDonald, "NSLP for Quality- of-Service signaling", draft-ietf-nsis-qos-nslp-06 (work in progress), February 2005. [3] Ash, J., "QoS-NSLP QSpec Template", draft-ietf-nsis-qspec-03 (work in progress), February 2005. [4] Ash, J., "Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in progress), May 2005. Jeong, et al. Expires November 18, 2005 [Page 14] Internet-Draft 3GPP QoS Model May 2005 [5] 3GPP TS 23.107 : Quality of Service (QoS) concept and architecture (Release 6), V6.2.0, Dec. 2004. [6] 3GPP TS 23.207 : End-to-end Quality of Service (QoS) concept and architecture (Release 6), V6.4.0, Sept. 2004. 9.2 Informative References [7] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [8] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. Authors' Addresses Seong-Ho Jeong Hankuk University of FS 89 Wangsan Mohyun Yongin-si, Gyeonggi-do 449-791 KOREA Phone: +82 31 330 4642 Email: shjeong@hufs.ac.kr Sung-Hyuck Lee Samsung Advanced Institute of Technology Comm. and Network Lab. San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9585 Email: starsu.lee@samsung.com Jong Ho Bang Samsung Advanced Institute of Technology Comm. and Network Lab. San 14-1, Nongseo-ri, Giheung-eup Jeong, et al. Expires November 18, 2005 [Page 15] Internet-Draft 3GPP QoS Model May 2005 Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9585 Email: jh0278.bang@samsung.com Byoung-Joon Lee Samsung Advanced Institute of Technology Comm. and Network Lab. San 14-1, Nongseo-ri, Giheung-eup Yongin-si, Gyeonggi-do 449-712 KOREA Phone: +82 31 280 9626 Email: bj33.lee@samsung.com Jeong, et al. Expires November 19, 2005 [Page 16] Internet-Draft 3GPP QoS Model May 2005 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Jeong, et al. Expires November 19, 2005 [Page 17]