Network Working Group G. Ash Internet-Draft A. Morton Intended status: Informational M. Dolly Expires: April 30, 2009 P. Tarapore C. Dvorak AT&T Labs Y. El Mghazli Alcatel-Lucent October 27, 2008 Y.1541-QOSM -- Y.1541 QoS Model for Networks Using Y.1541 QoS Classes draft-ietf-nsis-y1541-qosm-07 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 April 30, 2009. Abstract This draft describes a QoS-NSLP QoS model (QOSM) based on ITU-T Recommendation Y.1541 Network QoS Classes and related signaling requirements. Y.1541 specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. Ash, et al. Expires April 30, 2009 [Page 1] Internet-Draft Y.1541 QOSM October 2008 Requirements Language 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 RFC 2119 [RFC2119]. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Y.1541 Classes . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Y.1541-QOSM Processing Requirements . . . . . . . . . . . 5 3. Additional QSPEC Parameters for Y.1541 QOSM . . . . . . . . . 6 3.1. Traffic Model (TMOD) Extension Parameter . . . . . . . . . 6 3.2. Restoration Priority Parameter . . . . . . . . . . . . . . 7 4. Y.1541-QOSM Considerations and Processing Example . . . . . . 8 4.1. Deployment Considerations . . . . . . . . . . . . . . . . 9 4.2. Applicable QSPEC Procedures . . . . . . . . . . . . . . . 9 4.3. QNE Processing Rules . . . . . . . . . . . . . . . . . . . 9 4.4. Processing Example . . . . . . . . . . . . . . . . . . . . 9 4.5. Bit-Level QSPEC Example . . . . . . . . . . . . . . . . . 11 4.6. Preemption Behaviour . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . . . 17 Ash, et al. Expires April 30, 2009 [Page 2] Internet-Draft Y.1541 QOSM October 2008 1. Introduction This draft describes a QoS model (QOSM) for NSIS QoS signaling layer protocol (QoS-NSLP) application based on ITU-T Recommendation Y.1541 Network QoS Classes and related signaling requirements. [Y.1541] currently specifies 8 classes of Network Performance objectives, and the Y.1541-QOSM extensions include additional QSPEC parameters and QOSM processing guidelines. The extensions are based on standardization work in the ITU-T on QoS signaling requirements [Y.1541] [TRQ-QoS-SIG] [E.361]. [QoS-SIG] [I-D.ietf-nsis-qos-nslp] defines message types and control information for the QoS-NSLP generic to all 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, as well as how that information should be treated or interpreted in the network. The QSPEC [I-D.ietf-nsis-qspec] contains a set of parameters and values describing the requested resources. It is opaque to the QoS-NSLP and similar in purpose to the TSpec, RSpec and AdSpec specified in [RFC2205] [RFC2210] . The QSPEC object contains 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 element (QNE), the QSPEC contents are interpreted by the resource management function (RMF) for purposes of policy control and traffic control, including admission control and configuration of the scheduler. 2. Summary of ITU-T Recommendations Y.1541 & Signaling Requirements As stated above, [Y.1541] is a specification of standardized QoS classes for IP networks (a summary of these classes is given below). [TRQ-QoS-SIG] specifies the requirements for achieving end-to-end QoS in IP networks, with Y.1541 QoS classes as a basis. [Y.1541] recommends a flexible allocation of the end-to-end performance objectives (e.g., delay) across networks, rather than a fixed per- network allocation. NSIS protocols already address most of the requirements, this document identifies additional QSPEC parameters and processing requirements needed to support the Y.1541 QOSM. 2.1. Y.1541 Classes [Y.1541] proposes grouping services into QoS classes defined according to the desired QoS performance objectives. These QoS classes support a wide range of user applications. The classes group objectives for one-way IP packet delay, IP packet delay variation, IP packet loss ratio, etc., where the parameters themselves are defined in [Y.1540]. Classes 0 and 1 might be implemented using the DiffServ Ash, et al. Expires April 30, 2009 [Page 3] Internet-Draft Y.1541 QOSM October 2008 EF PHB, and support interactive real-time applications. Classes 2, 3, and 4 might be implemented using the DiffServ AFxy PHB Group, and support data transfer applications with various degrees of interactivity. Class 5 generally corresponds to the DiffServ Default PHB, has all the QoS parameters unspecified consistent with a best- effort service. Classes 6 and 7 provide support for extremely loss- sensitive user applications, such as high quality digital television, TDM circuit emulation, and high capacity file transfers using TCP. These classes are intended to serve as a basis for agreements between end-users and service providers, and between service providers. They support a wide range of user 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. The QoS classes apply to a packet flow, where [Y.1541] defines a packet flow as the traffic associated with a given connection or connectionless stream having the same source host, destination host, class of service, and session identification. The characteristics of each Y.1451 QoS class are summarized here: Class 0: Real-time, highly interactive applications, sensitive to jitter. Mean delay upper bound is 100 ms, delay variation is less than 50 ms, and loss ratio is less than 10^-3. Application examples include VoIP, Video Teleconference. Class 1: Real-time, interactive applications, sensitive to jitter. Mean delay upper bound is 400 ms, delay variation is less than 50 ms, and loss ratio is less than 10^-3. Application examples include VoIP, video teleconference. Class 2: Highly interactive transaction data. Mean delay upper bound is 100 ms, delay variation is unspecified, and loss ratio is less than 10^-3. Application examples include signaling. Class 3: Interactive transaction data. Mean delay upper bound is 400 ms, delay variation is unspecified, and loss ratio is less than 10^-3. Application examples include signaling. Class 4: Low Loss Only applications. Mean delay upper bound is 1s, delay variation is unspecified, and loss ratio is less than 10^-3. Application examples include short transactions, bulk data, video streaming Class 5: Unspecified applications with unspecified mean delay, delay variation, and loss ratio. Application examples include traditional applications of Default IP Networks Ash, et al. Expires April 30, 2009 [Page 4] Internet-Draft Y.1541 QOSM October 2008 Class 6: Mean delay <= 100 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation. Class 7: Mean delay <= 400 ms, delay variation <= 50 ms, loss ratio <= 10^-5. Applications that are highly sensitive to loss, such as television transport, high-capacity TCP transfers, and TDM circuit emulation. These classes enable SLAs to be defined between customers and network service providers with respect to QoS requirements. The service provider then needs to ensure that the requirements are recognized and receive appropriate treatment across network layers. Work is in progress to specify methods for combining local values of performance metrics to estimate the performance of the complete path. See section 8 of [Y.1541], [I-D.ietf-ippm-framework-compagg], and [I-D.ietf-ippm-spatial-composition]. 2.2. Y.1541-QOSM Processing Requirements [TRQ-QoS-SIG] provides the requirements for signaling information regarding IP-based QoS at the interface between the user and the network (UNI) and across interfaces between different networks (NNI). To meet specific network performance requirements specified for the Y.1541 QoS classes [Y.1541] , a network needs to provide specific user plane functionality at UNI and NNI interfaces. Dynamic network provisioning at a UNI and/or NNI node allows the ability to dynamically request a traffic contract for an IP flow from a specific source node to one or more destination nodes. In response to the request, the network determines if resources are available to satisfy the request and provision the network. It MUST be possible to derive the following service level parameters as part of the process of requesting service: a. Y.1541 QoS class b. rate (r) c. peak rate (p) d. bucket size (b) e. peak bucket size (Bp)*, octets f. maximum packet size (M)*, octets Ash, et al. Expires April 30, 2009 [Page 5] Internet-Draft Y.1541 QOSM October 2008 g. DiffServ PHB class [RFC2475] h. admission priority i. restoration priority* All parameters except Bp, M, and restoration priority have already been specified in [I-D.ietf-nsis-qspec]. These additional parameters are specified in Section 3. It MUST be possible to perform the following QoS-NSLP signaling functions to meet Y.1541-QOSM requirements: a. accumulate delay, delay variation and loss ratio across the end- to-end connection, which may span multiple domains b. enable negotiation of Y.1541 QoS class across domains. c. enable negotiation of delay, delay variation, and loss ratio across domains. These signaling requirements are already supported by [I-D.ietf-nsis-qos-nslp] and the functions are illustrated in Section 4. 3. Additional QSPEC Parameters for Y.1541 QOSM 3.1. Traffic Model (TMOD) Extension Parameter The traffic model (TMOD) extension parameter is represented by one floating point number in single-precision IEEE floating point format and one 32-bit unsigned integer. Ash, et al. Expires April 30, 2009 [Page 6] Internet-Draft Y.1541 QOSM October 2008 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|E|N|r| 15 |r|r|r|r| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size [M] (32-bit unsigned integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: TMOD Extension When the Bp term is represented as an IEEE floating point value, the sign bit MUST be zero (all values MUST be non-negative). Exponents less than 127 (i.e., 0) are prohibited. Exponents greater than 162 (i.e., positive 35) are discouraged, except for specifying a peak rate of infinity. Infinity is represented with an exponent of all ones (255) and a sign bit and mantissa of all zeros. The maximum packet size (M) is an unsigned integer. The QSPEC parameter behavior for (Bp) and (M) is similar to that defined in [I-D.ietf-nsis-qspec], section 6.2.1 and 6.2.2. The new parameters (and all traffic-related parameters) are specified independently from the Y.1541 class parameter. 3.2. Restoration Priority Parameter Restoration priority is the urgency with which a service requires successful restoration under failure conditions. Restoration priority is achieved by provisioning sufficient backup capacity, as necessary, and allowing relative priority for access to available bandwidth when there is contention for restoration bandwidth. Restoration priority is defined as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |M|E|N|r| 16 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Rest. Priority| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: Restoration Priority Restoration Priority: 3 priority values are listed here in the order of lowest priority to highest priority: 0 - best effort Ash, et al. Expires April 30, 2009 [Page 7] Internet-Draft Y.1541 QOSM October 2008 1 - normal 2 - high These priority values are described in [Y.2172], where best effort priority is the same as Priority level 3, normal priority is Priority level 2, and high priority is the same as Priority level 1. Reserved: These 3 octets are reserved for future use. There are several ways to elaborate on restoration priority, and two possibilities are described below: a. Time-to-Restore: Total amount of time to restore traffic streams belonging to a given restoration class impacted by the failure. This time period depends on the technology deployed for restoration. A fast recovery period of < 200 ms is based on current experience with SONET rings and a slower recovery period of 2 seconds is suggested in order to enable a voice call to recover without being dropped. Accordingly, candidate restoration objectives are: Best Time-to-Restore: <= 200 ms Normal Time-to-Restore <= 2 s Unspecified Time-to-Restore = 0 (Unspecified) b. Extent of Restoration: Percentage of traffic belonging to the restoration class that can be restored. This percentage depends on the amount of spare capacity engineered. All high priority restoration priority traffic, for example, may be "guaranteed" at 100% by the service provider. Other classes may offer lesser chances for successful restoration. The restoration extent for these lower priority classes depend on SLA agreements developed between the service provider and the customer. The Reserved octets MAY be designated for these or other uses in the future. 4. Y.1541-QOSM Considerations and Processing Example In this Section we illustrate the operation of the Y.1541 QOSM, and show how current QoS-NSLP and QSPEC functionality is used. No new processing capabilities or parameters (except those described in section 3) are required to enable the Y.1541 QOSM. Ash, et al. Expires April 30, 2009 [Page 8] Internet-Draft Y.1541 QOSM October 2008 4.1. Deployment Considerations [TRQ-QoS-SIG] emphasizes the deployment of Y.1541 QNEs at the borders of supporting domains. There may be domain configurations where interior QNEs are desirable, and the example below addresses this possibility. QNEs may be Stateful in some limited aspects, but obviously it is preferable to deploy stateless QNEs. 4.2. Applicable QSPEC Procedures All procedures defined in section 5.3 of [I-D.ietf-nsis-qspec] are applicable to this QOSM. 4.3. QNE Processing Rules [TRQ-QoS-SIG] describes the information processing in Y.1541 QNEs. [Y.1541] section 8 defines the accumulation rules for individual performance parameters (e.g., delay, jitter). When a QNI specifies the Y.1541 QoS Class number, , it is a sufficient specification of objectives for the , , and parameters. As described above in section 2, some Y.1541 Classes do not set objectives for all the performance parameters above. For example, Classes 2, 3, and 4, do not specify an objective for (referred to as IP Packet Delay Variation). In the case that the QoS Class leaves a parameter Unspecified, then that parameter need not be included in the accumulation processing. 4.4. Processing Example As described in the example given in [I-D.ietf-nsis-qspec] (Section 4.4) and as illustrated in Figure 3, the QoS NSIS initiator (QNI) initiates an end-to-end, inter-domain QoS NSLP RESERVE message containing the Initiator QSPEC. In the case of the Y.1541 QOSM, the Initiator QSPEC specifies the , , , , , and perhaps other QSPEC parameters for the flow. As described in Section 3, the TMOD extension parameter contains the optional, Y.1541-QOSM-specific parameters Bp and M; restoration priority is also an optional, Y.1541-QOSM-specific parameter. As illustrated in Figure 3, the RESERVE message may cross multiple domains supporting different QOSMs. In this illustration, the initiator QSPEC arrives in an QoS NSLP RESERVE message at the ingress Ash, et al. Expires April 30, 2009 [Page 9] Internet-Draft Y.1541 QOSM October 2008 node of the local-QOSM domain. As described in [I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec], at the ingress edge node of the local-QOSM domain, the end-to-end, inter-domain QoS- NSLP message may trigger the generation of a local QSPEC, and the initiator QSPEC encapsulated within the messages signaled through the local domain. The local QSPEC is used for QoS processing in the local-QOSM domain, and the Initiator QSPEC is used for QoS processing outside the local domain. As specified in [I-D.ietf-nsis-qspec], if any QNE cannot meet the requirements designated by the initiator QSPEC to support an optional QSPEC parameter, with the M bit set to zero for the parameter, for example, it cannot support the accumulation of end-to-end delay with the parameter, the QNE sets the N flag (not supported flag) for the path latency parameter to one. Also, the Y.1541-QOSM requires negotiation of the across domains. This negotiation can be done with the use of the existing procedures already defined in [QoS-SIG] [I-D.ietf-nsis-qos-nslp]. For example, the QNI sets , , objects to include , which specifies objectives for the , , parameters. In the case that the QoS Class leaves a parameter Unspecified, then that parameter need not be included in the accumulation processing. The QNE/domain SHOULD set the Y.1541 class and cumulative parameters, e.g., , that can be achieved in the object (but not less than specified in ). This could include, for example, setting the to a lower class than specified in (but not lower than specified in ). If the fails to satisfy one or more of the objectives, the QNE/domain notifies the QNI and the reservation is aborted. Otherwise, the QNR notifies the QNI of the for the reservation. When the available must be reduced from the desired , say because the delay objective has been exceeded, then there is an incentive to respond with an available value for delay in the parameter. If the available is 150 ms (still useful for many applications) and the desired QoS is Class 0 (with its 100 ms objective), then the response would be that Class 0 cannot be achieved and Class 1 is available (with its 400 ms objective). In addition, this QOSM allows the response to include an available = 150 ms, making acceptance of the available more likely. There are many long paths where the propagation delay alone exceeds the Y.1541 Class 0 objective, so this feature adds flexibility to commit to exceed the Class 1 objective when possible. Ash, et al. Expires April 30, 2009 [Page 10] Internet-Draft Y.1541 QOSM October 2008 This example illustrates Y.1541-QOSM negotiation of and cumulative parameter values that can be achieve end-to- end. The example illustrates how the QNI can use the cumulative values collected in to decide if a lower than specified in is acceptable. |------| |------| |------| |------| | e2e |<->| e2e |<------------------------->| e2e |<->| e2e | | QOSM | | QOSM | | QOSM | | QOSM | | | |------| |-------| |-------| |------| | | | NSLP | | NSLP |<->| NSLP |<->| NSLP |<->| NSLP | | NSLP | |Y.1541| |local | |local | |local | |local | |Y.1541| | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | | QOSM | |------| |------| |-------| |-------| |------| |------| ----------------------------------------------------------------- |------| |------| |-------| |-------| |------| |------| | NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP | |------| |------| |-------| |-------| |------| |------| QNI QNE QNE QNE QNE QNR (End) (Ingress Edge) (Interior) (Interior) (Egress Edge) (End) Figure 3: Example of Y.1541-QOSM Operation 4.5. Bit-Level QSPEC Example This is an example where the QOS Desired specification contains the TMOD-1 parameters and TMOD extended parameters defined in this specification, as well as the Y.1541 Class parameter. The QOS Available specification utilizes the Latency, Jitter, and Loss parameters to enable accumulation of these parameters for easy comparison with the objectives desired fir the Y.1541 Class. This example assumes that all the parameters MUST be supported by the QNEs, so all M flags have been set to "1". 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Vers.|QType=I|QSPEC Proc.=0/1|0|R|R|R| Length = 23 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|r|r|r| Type = 0 (QoS Des.) |r|r|r|r| Length = 10 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|0|r| ID = 1 |r|r|r|r| Length = 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Rate-1 [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TMOD Size-1 [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ash, et al. Expires April 30, 2009 [Page 11] Internet-Draft Y.1541 QOSM October 2008 | Peak Data Rate-1 [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Minimum Policed Unit-1 [m] (32-bit unsigned integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|r| 15 |r|r|r|r| 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Peak Bucket Size [Bp] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Maximum Packet Size [M] (32-bit unsigned integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|r| 14 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Y.1541 QoS Cls.| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |E|r|r|r| Type = 1 (QoS Avail) |r|r|r|r| Length = 11 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|r| 3 |r|r|r|r| 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Latency (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|r| 4 |r|r|r|r| 4 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Jitter STAT1(variance) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Jitter STAT2(99.9%-ile) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Jitter STAT3(minimum Latency) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Path Jitter STAT4(Reserved) (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|r| 5 |r|r|r|r| 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | Path Packet Loss Ratio (32-bit floating point) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|E|N|r| 14 |r|r|r|r| 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Y.1541 QoS Cls.| (Reserved) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: An Example QSPEC (Initiator) 4.6. Preemption Behaviour The default QNI behaviour of tearing down a preempted reservation is followed in the Y.1541 QOSM. The restoration priority parameter described above does not rely on preemption. Ash, et al. Expires April 30, 2009 [Page 12] Internet-Draft Y.1541 QOSM October 2008 5. IANA Considerations This section defines the registries and initial codepoint assignments for the QSPEC template, in accordance with BCP 26 [RFC5226]. It also defines the procedural requirements to be followed by IANA in allocating new codepoints. This document specifies the following QSPEC parameters to be assigned within the QSPEC Parameter ID registry created in [I-D.ietf-nsis-qspec]: parameter (Section 3.1, suggested ID=15) parameter (Section 3.2, suggested ID=16) This specification creates the following registry with the structure as defined below: Restoration Priority Parameter (8 bits): The following values are allocated by this specification: 0-2: assigned as specified in Section 3.2: 0: best-effort priority 1: normal priority 2: high priority The allocation policies for further values are as follows: 3-63: Standards Action 64-255: Reserved 6. Security Considerations The security considerations of [I-D.ietf-nsis-qos-nslp] and [I-D.ietf-nsis-qspec] apply to this Document. There are no new security considerations based on this document. 7. Acknowledgements The authors thank Attila Bader, Cornelia Kappler, Sven Van den Bosch, and Hannes Tschofenig for helpful comments and discussion. Ash, et al. Expires April 30, 2009 [Page 13] Internet-Draft Y.1541 QOSM October 2008 8. References 8.1. Normative References [I-D.ietf-nsis-qos-nslp] Manner, J., Karagiannis, G., and A. McDonald, "NSLP for Quality-of-Service Signaling", draft-ietf-nsis-qos-nslp-16 (work in progress), February 2008. [I-D.ietf-nsis-qspec] Ash, G., Bader, A., Kappler, C., and D. Oran, "QoS NSLP QSPEC Template", draft-ietf-nsis-qspec-20 (work in progress), April 2008. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [TRQ-QoS-SIG] ITU-T Supplement, "Signaling Requirements for IP-QoS", January 2004. [Y.1540] ITU-T Recommendation Y.1540, "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2007. [Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives for IP-Based Services", February 2006. [Y.2172] ITU-T Recommendation Y.1540, "Service restoration priority levels in Next Generation Networks", June 2007. 8.2. Informative References [E.361] ITU-T Recommendation E.361, "QoS Routing Support for Interworking of QoS Service Classes Across Routing Technologies", May 2003. [I-D.ietf-ippm-framework-compagg] Morton, A., "Framework for Metric Composition", draft-ietf-ippm-framework-compagg-06 (work in progress), February 2008. [I-D.ietf-ippm-spatial-composition] Morton, A. and E. Stephan, "Spatial Composition of Metrics", draft-ietf-ippm-spatial-composition-07 (work in progress), July 2008. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. Ash, et al. Expires April 30, 2009 [Page 14] Internet-Draft Y.1541 QOSM October 2008 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, December 1998. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. Authors' Addresses Jerry Ash AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: Fax: Email: gash5107@yahoo.com URI: Al Morton AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: +1 732 420 1571 Fax: +1 732 368 1192 Email: acmorton@att.com URI: http://home.comcast.net/~acmacm/ Ash, et al. Expires April 30, 2009 [Page 15] Internet-Draft Y.1541 QOSM October 2008 Martin Dolly AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: Fax: Email: mdolly@att.com URI: Percy Tarapore AT&T Labs 200 Laurel Avenue South Middletown,, NJ 07748 USA Phone: Fax: Email: tarapore@att.com URI: Chuck Dvorak AT&T Labs 180 Park Ave Bldg 2 Florham Park,, NJ 07932 USA Phone: + 1 973-236-6700 Fax: Email: cdvorak@att.com URI: http: Yacine El Mghazli Alcatel-Lucent Route de Nozay Marcoussis cedex, 91460 France Phone: +33 1 69 63 41 87 Fax: Email: yacine.el_mghazli@alcatel.fr URI: Ash, et al. Expires April 30, 2009 [Page 16] Internet-Draft Y.1541 QOSM October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Ash, et al. Expires April 30, 2009 [Page 17]