One document matched: draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt
Differences from draft-ash-nsis-nslp-qos-sig-proof-of-concept-00.txt
Network Working Group Jerry Ash
Internet Draft Chuck Dvorak
<draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt> Al Morton
Expiration Date: August 2004 Percy Tarapore
AT&T
Yacine El Mghazli
Sven Van den Bosch
Alcatel
February 2004
NSIS Network Service Layer Protocol QoS Signaling Proof-of-Concept
<draft-ash-nsis-nslp-qos-sig-proof-of-concept-01.txt>
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.
ABSTRACT:
This draft describes a proof-of-concept example of NSIS Signaling Layer
Protocol (NSLP) for signaling QoS reservations in the Internet. The
example is based on standardization work in the ITU-T of QoS signaling
requirements. The QoS-NSLP is independent of the underlying QoS
specification or architecture and provides support for different
reservation models. Together with the NSIS Transport Layer Protocol
(NTLP), the NSLP provides functionality similar to RSVP and extends it.
This draft provides a proof-of-concept example of the NSIS NSLP for QoS
signaling. The example is based on standardization work in the ITU-T on
QoS signaling requirements [E.361, TRQ-QoS-SIG], and is specified in
terms of the QoS-signaling model and Qspec template given in the 'NSLP
for QoS Signaling' specification [QoS-SIG].
Table of Contents
1. Introduction
2. NSIS NSLP QoS Signaling Model
3. Qspec Template for Proof-of-Concept Example of NSIS NSLP
QoS-Signaling Model
4. Security Considerations
5. Acknowledgments
6. References
7. Authors' Addresses
Appendix A. Summary of ITU-T Recommendation E.361 "QoS Routing Support
for Interworking of QoS Service Classes Across Routing Technologies"
Appendix B. Summary of ITU-T Recommendation TRQ-QoS-SIG "Signaling
Requirements for IP-QoS"
10. Full Copyright Statement
1. Introduction
This draft describes a proof-of-concept example of NSIS Signaling Layer
Protocol (NSLP) for signaling QoS reservations in the Internet. The
example is based on standardization work in the ITU-T of QoS signaling
requirements. The QoS-NSLP is independent of the underlying QoS
specification or architecture and provides support for different
reservation models. Together with the NSIS Transport Layer Protocol
(NTLP), the NSLP provides functionality similar to RSVP and extends it.
This draft provides a proof-of-concept example of the NSIS NSLP for QoS
signaling. The example is based on standardization work in the ITU-T on
QoS signaling requirements [E.361, TRQ-QoS-SIG], and is specified in
terms of the QoS-signaling model and Qspec template given in the 'NSLP
for QoS Signaling' specification [QoS-SIG].
The QoS-signaling NSLP protocol establishes and maintains state at
nodes along the path of a data flow for the purpose of providing some
forwarding resources for that flow. It is intended to satisfy the
QoS-related requirements of [NSIS-REQ]. This QoS-NSLP is part of a
larger suite of signaling protocols, whose structure is outlined in
[NSIS-FRAMEWORK]; this defines a common NTLP which QoS-NSLP uses to
carry out many aspects of signaling message delivery. The design of
QoS-signaling NSLP is conceptually similar to RSVP [RSVP], and uses
soft-state peer-to-peer refresh messages as the primary state management
mechanism. The QoS-signaling NSLP extends the set of reservation
mechanisms to meet the requirements of [NSIS-REQ], in particular,
support of sender or receiver-initiated reservations, as well as a type
of bi-directional reservation and support of reservations between
arbitrary nodes, e.g. edge-to-edge, end-to-access, etc.
QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular
QoS provisioning method or QoS architecture; this is similar to (but
stronger than) the decoupling between RSVP and the IntServ architecture
[INTSERV]. It should be able to carry information for various QoS
models; the specification of Integrated Services for use with RSVP given
in [RSVP-INTSERV] could form the basis of one QoS model. This draft
provides another proof-of-concept example of NSIS NSLP for QoS
signaling, and is based on standardization work in the ITU-T of QoS
signaling requirements [E.361, TRQ-QoS-SIG]. The QoS-signaling model is
described in Section 2, and is based on the Qspec template given in
[QoS-SIG].
2. NSIS NSLP QoS Signaling Model
[QoS-SIG] defines message types and control information for the
QoS-NSLP generic to all QoS models. A QoS model is a defined mechanism
for achieving QoS as a whole. The specification of a QoS model includes
a description of its QoS parameter information, as well as how that
information should be treated or interpreted in the network. In that
sense, the QoS model goes beyond the QoS-NSLP protocol level in that it
could also describe underlying assumptions, conditions and/or specific
provisioning mechanisms appropriate for it.
Messages are normally passed from the NSLP to the NTLP via an API,
which also specifies the signaling application (as QoS-NSLP), the
flow/session identifier, and an indication of the intended direction -
towards data sender or receiver. On reception, the NTLP provides the
same information to the QoS-NSLP.
The NSIS NSLP protocol specifies four message types (RESERVE, QUERY,
RESPONSE and NOTIFY) and two objects (QSpec and Policy object). Each
protocol message includes header information that identifies the message
type and determines which objects it may carry. A protocol message also
contains Control Information (CI), which is a group of objects that
qualify and/or restrict the action that an NSIS entity may perform on
the QoS message. Control Information is always associated to a QSpec,
i.e. CI and QSpec always come in pairs. The QSpec object contains the
QoS parameters defined by the QoS model, and describes the QoS that is
being reserved. The Policy object authenticates and authorizes the
requester of the QoS reservation.
A QoS model provides a specific set of parameters to be carried in the
QSpec, or restricts the values these parameters can take. Integrated
Services [INTSERV], Differentiated Services DIFFSERV] and RMD [RMD] are
all examples of QoS models. There is no restriction on the number of QoS
models. QoS models may be local, meaning that they are private to one
network, implementation or vendor specific or global, meaning that they
must be implementable by different networks and vendors. The 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 [RSVP,RSVP-INTSERV]. At each NSIS
entity which supports the QoS-signaling NSLP, its content is interpreted
by the resource management function for the purposes of policy control
and traffic control (including admission control and configuration of
the packet classifier and scheduler).
Different QoS models may share a common set of QoS parameters. A QSpec
template is proposed in [QoS-SIG], which would allow for a consistent
specification of common QoS parameters in different QoS models. Flow
identification information is also needed but is not part of the QSpec
template, rather it is made available over the API between the
QoS-signaling NSLP and the NTLP. It is not the intention that all QoS
models support all fields and sub objects defined in [QoS-SIG]. The
definition of a QoS model entails a selection of one or more of these
fields and/or sub objects. For instance, one QoS model could only allow
QSpec ID and DSCP to be specified.
3. Qspec Template for Proof-of-Concept Example of NSIS NSLP
QoS-Signaling Model
The Qspec template [QoS-SIG] for the proof-of-concept example of the
NSIS NSLP QoS-signaling model is given in this Section. The individual
parameters given in the template are based on the QoS signaling
requirements specified in ITU-T Recommendations [E.361] and
[TRQ-QoS-SIG]. Please refer to Appendices A and B for summaries of
these two Recommendations.
The proof-of-concept example has the following Qspec template:
1. QSpec ID (allows IANA reservation of QSpec parameter combinations):
IANA specified.
2. Traffic Envelope/Conformance:
The traffic envelope describes the traffic (conformance)
characteristics of the data stream identified by the QoS NSLP Session
ID. The traffic envelope is a set of Traffic Conformance Parameters,
describing how the packet stream should look to get the guarantees
indicated by the performance parameters (defined below).
The Traffic Conformance Parameters are the basic input for the Traffic
Conformance Algorithm. Traffic Conformance Testing is the combination
of the Traffic Conformance Parameters and the Traffic Conformance
Algorithm. This will usually be done at a boundary node. The algorithm
and the conformance test can be binary-based or multi-level based.
The traffic conformance algorithm used for this model is token-bucket,
with conformance parameters Token Bucket Rate (Br) and Token Bucket Size
(Bp and Bs)
TRAF-PAR (peak rate (Rp), peak bucket size (Bp), sustainable rate
(Rs), sustainable bucket size (Bs), token bucket rate (Br), maximum
allowed packet size (M)). See Section A.3.
3. Excess Treatment:
This parameter describes how the network provider will process excess
traffic, i.e. out-of-profile traffic (in case of binary conformance
testing) or n-level traffic (in case of n-level conformance testing).
The process takes place after Traffic Conformance Testing, described
previously. Excess traffic may be dropped, shaped and/or remarked.
Excess Treatment (EXTR)
4. Offered Guarantees:
The performance parameters describe the service guarantees the network
offers to the customer for the packet stream described by the QoS NSLP
Session ID and within the limits of the geographical/topological extent
given by the scope.
QoS-REQUEST-PAR (Y.1541 QoS class, DIFFSERV, service identity (SI),
class type (CT), link capability (LC)) are qualitative guarantees.
See Section A.3.
QoS-ACCUM-PAR (transfer delay, delay variation, packet loss) are
quantitative guarantees, which are used in the QUERY or RESPONSE
message to collect information along the path. See Section A.3.
The QoS-ACCUM-PAR should only be used in the QUERY message to collect
information along the path and determine if the numerical objectives of
Y.1541 classes are met, and MUST NOT be part of the QoS-REQUEST-PAR.
QoS-ACCUM-PAR MAY also be used in the RESPONSE message to indicate or
convey the estimate of end-end achieved performance.
5. Service Schedule:
The service schedule indicates the start time and end time of the
service, i.e. when is the service available.
As specified in Appendix B/[TRQ-QoS-SIG]. See example in Section
B.5.
6. Priority and Reliability:
CAC Priority (CAC-PRTY), Restoration Priority (RES-PRTY). See
Sections A.3 and B.4.
7. Monitoring requirements:
Information required about reservation, related to AdSpec functionality
and may contain QUERY parameters.
As specified in Appendix B/[TRQ-QoS-SIG]. See example in Section
B.5.
4. Security Considerations
There are no new security considerations based on proposals in this
draft.
5. Acknowledgements
6. References
[DIFFSERV] Blake, S., et. al., "An Architecture for Differentiated
Services", RFC 2475, December 1998.
[DS-TE] Le Faucheur, F., et. al., Requirements for Support of
Differentiated Services-aware MPLS Traffic Engineering , RFC 3564, July
2003
[KEY] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997
[E.361] ITU-T Recommendation, "QoS Routing Support for Interworking of
QoS Service Classes Across Routing Technologies," May 2003.
[INTSERV] Braden, B., et. al., "Integrated Services in the Internet
Architecture: an Overview," RFC 1633, June 1994.
[NSIS-REQ] Brunner, M., et. al., "Requirements for QoS Signaling
Protocols," work in progress.
[NSIS-FRAMEWORK] Hancock, R., et. al., "Next Steps in Signaling:
Framework," work in progress.
[RMD] Westberg, L., "Resource Management in Diffserv (RMD) Framework,"
work in progress.
[RSVP] Braden, B., et. al., "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification," RFC 2205, September 1997.
[RSVP-INTSERV] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services," RFC 2210, September 1997.
[TRQ-QoS-SIG] ITU-T Recommendation, "Signaling Requirements for IP-QoS,"
January 2004.
[QoS-SIG] Van den Bosch, S., et. al., "NSLP for Quality-of-Service
Signaling," work in progress.
[Y.1541] ITU-T Recommendation Y.1541, "Network Performance Objectives
for IP-Based Services," May 2002.
7. Authors' Addresses
Jerry Ash
AT&T
Room MT D5-2A01
200 Laurel Avenue
Middletown, NJ 07748, USA
Phone: +1-(732)-420-4578
Fax: +1-(732)-368-8659
Email: gash@att.com
Chuck Dvorak
AT&T
Room 2A37
180 Park Avenue, Building 2
Florham Park, NJ 07932
Phone: + 1 973-236-6700
Fax:+1 973-236-7453
E-mail: cdvorak@att.com
Yacine El Mghazli
Alcatel
Route de Nozay
91460 Marcoussis cedex - FRANCE
Phone: +33 1 69 63 41 87
Email: yacine.el_mghazli@alcatel.fr
Al Morton
AT&T
Room D3-3C06
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-1571
Fax: +.1 732 368-1192
E-mail: acmorton@att.com
Percy Tarapore
AT&T
Room D1-3D33
200 S. Laurel Avenue
Middletown, NJ 07748
Phone: + 1 732 420-4172
E-mail: tarapore@.att.com
Sven Van den Bosch
Alcatel
Francis Wellesplein 1
B-2018 Antwerpen
Belgium
E-mail: sven.van_den_bosch@alcatel.be
Appendix A. Summary of ITU-T Recommendation E.361 "QoS Routing Support
for Interworking of QoS Service Classes Across Routing Technologies"
A.1. Introduction
QoS routing is an indispensable network function which controls a
network's response to traffic demands and other stimuli, such as network
failures. To support the ability to carry all types of
telecommunications traffic (voice, data, video, etc.) over a single
network, networks are evolving beyond best effort capabilities to
provide a variety of performance and reliability options. Transport
backbones are incorporating new optical technologies enabling flexible
and cost-effective solutions for carrying various grades of
telecommunications traffic. It is important for service providers to
satisfy customer expectations for end-to-end reliability and QoS, for
all types of transactions and services. QoS requirements include
performance parameters such as delay, jitter, packet loss, etc, and are
related to the type of transaction (e.g., voice, data, video).
Reliability on the other hand represents expectations on adequate
service availability over a specified period for the desired transaction
types. Further, services may have different reliability expectations
depending on the type of service. For example, a voice over IP (VoIP)
packet stream for emergency services calls would require high priority
reliability treatment. Other VoIP services may have lower reliability
expectations and hence their network reliability treatment may be less
stringent. To satisfy reliability and QoS considerations for all
transaction and service types, a service provider needs to ensure that
all network protocol layers are equipped to recognize and satisfy the
QoS and reliability requirements for the service classes.
QoS Service Classes (QSCs) are defined as aggregations of individual
service classes. Instead of having per-class parameters being configured
and propagated on each network interface, classes are aggregated into
QSCs having common per-QSC parameters (e.g., maximum bandwidth) to
satisfy required performance levels. There is no maximum or minimum
bandwidth requirement to be enforced at the level of individual class in
the QSC. QSCs are known as class types (CTs) in IP/DiffServ-enabled MPLS
Traffic Engineering (DS-TE) networks [DS-TE], virtual networks (VNETs)
in TDM networks, and QoS classes in ATM networks.
Recommendation E.361 identifies QoS routing functions and associated
parameters, and proposes means of signaling these QoS routing parameters
across networks employing different routing technologies, including IP-,
ATM-, and TDM-based routing technologies. It proposes extensions to
signaling protocols such as SIP and RSVP-TE to support signaling of QoS
routing parameters within and across networks.
A.2 QoS Routing Functions & Parameters
QoS routing functions and associated parameters include:
a. bandwidth allocation/protection (traffic and QoS parameters);
b. routing priority;
c. queuing priority; and
d. class-of-service identification (service, CT, and capability
parameters).
Bandwidth allocation and protection includes connection admission and
bandwidth reservation. Typically, the connection admission control for
each link in the path is performed based on the status of the link. CT
bandwidth is managed to meet the overall bandwidth requirements of QSC
service needs. Individual flows are allocated bandwidth within CTs
accordingly, as bandwidth is available. Bandwidth reservation gives
preference to the preferred traffic by allowing it to seize any idle
bandwidth in a link, while allowing the non- preferred traffic to only
seize bandwidth if there is a minimum level of idle bandwidth available,
where the minimum-bandwidth threshold is called the reservation level.
Routing priority can give preference to admit and/or restore higher
priority connections ahead of lower priority connections. A
high-priority service can be admitted in preference over a
normal-priority service. Restoration priority can assign a priority to
traffic streams for restoration. As in the case for connection
admission, certain services may require higher restoration priority over
others. Bandwidth allocation/protection and priority routing reflect
reliability expectations/objectives such as loss probability,
time-to-restore, and extent of restoration.
Priority queuing considers packet level objectives and performance
expectations such as delay, loss, and delay variation. ITU-T
Recommendation Y.1541 groups services into six QoS classes defined
according to the desired QoS performance objectives (see Appendix B).
[DIFFSERV] specifies several types of DiffServ PHBs, including EF, AF,
and BE.
Class-of-service identification entails:
a. service identity (SI);
b. class type (CT);
c. link capability (LC).
The SI describes the actual service associated with the connection. The
CT describes the bandwidth allocation and routing table parameters to be
used by the connection. The LC describes the desired connection
capabilities such as fiber, radio, satellite, and digital circuit
multiplexing equipment, that the connection should require, prefer, or
avoid. LC is similar to the concept of 'color' in [RSVP-TE].
A.2 Signaling of QoS Routing Information
QoS control includes the following functions:
a) application or 'call' control (SIP/SDP, H.323, etc.);
b) vertical control (H.248/MEGACO, etc.); and
c) bearer control (MPLS, RSVP-TE, DiffServ, DS-TE, etc.).
While these functions are not all in the scope of NSIS, they are briefly
discussed in this Section to show some complementary routing
considerations for this proof-of-concept.
A.2.1. Application/Call Control
End-to-end QoS control is negotiated/communicated end-to-end at the call
control level. The idea is that call control protocols are enhanced with
a generic end-to-end QoS service control mechanism to negotiate the
associated QoS routing parameters (bandwidth/CT, Y.1541 QoS class,
etc.). Such an end-to-end QoS control mechanism is defined independent
of the underlying technology (IP, ATM, etc.) and operates across network
domains. These QoS routing parameters need to be mapped to specific IP,
TDM, and ATM QSCs (CT, VNET, and QoS class, respectively) and these
mappings should be made available to the appropriate control elements.
Such enhancements are applicable to call-control protocols like SIP/SDP,
H.323, etc.
A.2.2. Vertical Control
QoS routing control is also negotiated/communicated at the vertical
control level. The proposed signaling requirements include the vertical
interface. The idea is that vertical control protocols are enhanced to
negotiate/communicate the QoS parameters (bandwidth, Y.1541 QoS class,
etc.) in the bearer network based on H.248/MEGACO extensions. These QoS
parameters are defined independent of the underlying technology (IP,
ATM, etc.) of the bearer network. The vertical interface then maps the
application QoS routing parameters into the bearer QoS routing
parameters.
A.2.3. Bearer Control
Bearer network QoS is negotiated/communicated at the bearer control
level. IP bearer control protocols are enhanced with a mechanism to
negotiate the network QoS by using QoS routing parameters and transfer
capabilities. Bearer network QoS is negotiated/communicated at the
bearer level, i.e., as part of the protocols associated with the bearers
in the core network. QoS routing and transfer capabilities are used to
enhance existing IP mechanisms like MPLS, RSVP-TE, DiffServ, DS-TE, etc.
A.3. Proposed Signaling Protocol Extensions
Table 1 summarizes the required signaling and information exchange
parameters supported within each routing technology which are required
to be supported across network types. Table 1 identifies the required
information-exchange parameters to support the QoS routing functions and
parameters.
Table 1. Required Signaling & Information-Exchange Parameters to Support
QoS Routing Functions & Parameters
QoS Routing Function Supported Signaling & Information
Exchange Parameters
BW Allocation and Protection Y.1541 QoS Class, DS-TE class type,
QoS-PAR, TRAF-PAR
Priority Routing CAC-PRTY, REST-PRTY
Priority Queuing DIFFSERV
Class-of-Service Identification SI, CT, LC
These QoS routing information-exchange parameters are required:
1. QoS parameters (QoS-PAR): The QoS-PAR includes the DS-TE class type
[DS-TE], and QoS thresholds such as transfer delay, delay variation, and
packet loss. Preferably, the Y.1541 QoS class is specified requiring the
QoS performance objectives specified for the selected class.
Alternatively, the QoS-PAR performance thresholds are individually
specified. The QoS-PAR parameters are used by each node to compare the
link QoS performance to the requested QoS threshold to determine if the
connection/bandwidth-allocation request is admitted or blocked on that
link. The QoS parameters could also specify tail distribution values
(percentiles). This may allow combining QoS values from different
domains.
2. Traffic parameters (TRAF-PAR): The TRAF-PAR include DS-TE class type,
and traffic parameters such as peak rate (Rp), peak bucket size (Bp),
sustainable rate (Rs), sustainable bucket size (Bs), token bucket rate
(Br), and maximum allowed packet size (M). The TRAF-PAR parameters are
used by each node to compare the link traffic characteristics to the
requested TRAF-PAR thresholds to determine if the
connection/bandwidth-allocation request is admitted or blocked on that
link.
3. Connection admission control priority (CAC-PRTY) parameter: The
CAC-PRTY parameter is used by each node to determine the priority of the
connection/bandwidth-allocation request being admitted on that link.
4. Restoration priority (REST-PRTY) parameter: The REST-PRTY parameter
is used by each node to determine the priority of the
connection/bandwidth-allocation request being restored on a given VP/LSP
and/or transport link.
5. Differentiated services (DIFFSERV) parameter: The DIFFSERV parameter
is used in ATM-based and IP-based networks to support priority queuing.
The DIFFSERV parameter is used at the queues associated with each link
to designate the relative priority and management policy for each queue.
6. Service Identity (SI) parameter: The SI parameter describes the
actual service associated with the call.
7. Class Type (CT) parameter: The CT parameter describes the bandwidth
allocation and routing table parameters to be used by the call.
8. Link Capability (LC) parameter: The LC parameter describes the link
hardware capabilities such as fiber, radio, satellite, and digital
circuit multiplexing equipment (DCME), that the call should require,
prefer, or avoid.
It is required that these parameters be included (as appropriate) in the
signaling messages within TDM-, ATM-, and IP-based networks. These
parameters are used to control the routing, bandwidth allocation, and
routing/queuing priorities.
Appendix B. Summary of ITU-T Recommendation TRQ-QoS-SIG "Signaling
Requirements for IP-QoS"
B.1. Introduction
Recommendation 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). These requirements and the signaling information elements
identified will enable the development of a signaling protocol(s)
capable of the request, negotiation and ultimately delivery of known IP
QoS classes from UNI to UNI, spanning NNIs as required. The signaling
requirements also address signal information related to traffic priority
and admission control, as these are also central to truly comprehensive
QoS.
To meet specific network performance requirements such as those
specified for the QoS classes of Y.1541, a network needs to provide
specific user plane functionality at UNI, NNI, and INI interfaces. A
network may be provisioned to meet the performance requirements of
Y.1541 either statically or dynamically on a per flow basis using a
protocol that meets the requirements specified in the Recommendation.
Static network provisioning is typically performed by a network
engineering team using a network management system. Static provisioning
typically takes into account both overall network performance
requirements and performance requirements for individual customers based
on traffic contracts between the customer and the network provider.
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.
True QoS goes beyond just the delay and loss that can occur in the
transport of IP packets. The requirements include the bandwidth/capacity
needed by the application, and the priority with which such bandwidth
will be maintained during congestion and restored after various failure
events. As these aspects of QoS can be related to routing, they go
beyond the resource management of the packet transport. Requirements on
priority and admission controls are also considered.
B.2. QoS Signaling Requirements
The call/session control signaling includes an indication of the QoS
requirements for each session. The QoS requirements are realized using
various mechanisms, e.g. packet fragmentation, over-provisioning,
resource reservation (RSVP) or DiffServ. Different QoS mechanisms may
be used on different sections of a session packet-forwarding path. There
may be communicated between call/session control nodes and
packet-forwarding devices using a 'gate' control protocol to control the
QoS mechanism.
QoS signaling requirements are expressed in terms of attributes related
to User-Network Signaling as well as Network-Network signaling. Major
attributes include the following:
a. network QoS Class (i.e., Y.1541/Table 1);
b. network capacity required;
c. reliability/priority with which the service is to be sustained.
Obtaining user-to-user QoS on IP Networks, and on combinations of
various network technologies, will require standard signaling protocols
for communicating the requirements among the major entities. These
entities include users and their end terminal equipment, and network
service providers and their equipment, especially equipment implementing
the inter-working and signaling function between networks, and between
users and networks.
It shall be possible to derive the following service level parameters as
part of the process of requesting service:
a. QoS class from Y.1541, which includes IP Loss Ratio, IP Transfer
Delay, and IP Delay Variation (see Section B.3 below),
b. peak rate (Rp)
c. peak bucket size (Bp)
d. sustainable rate (Rs)
e. sustainable bucket size (Bs)
f. token bucket rate (Br)
g. maximum allowed packet size (M)
h. DiffServ field as specified in RFC 2474
i. reliability/priority of the service (see Section B.4 below)
j. optional attributes include user application type & quality
categories.
B.3 Y.1541 QoS Class Performance Objectives
[Y.1541] proposes grouping services into six 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. Classes 0 and 1, which generally correspond to the DiffServ
EF PHB, support interactive real-time applications. Classes 2, 3, and
4, which generally correspond to the DiffServ AFxy PHB Group, support
non-interactive applications. Class 5, which generally corresponds to
the DiffServ best-effort PHB, 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.
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 class are
summarized here:
Class 0: Real-time, highly interactive applications, sensitive to
jitter. Mean delay upper bound is 100 ms, delay variance 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 variance 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 variance 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 variance 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
variance 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
variance, and loss ratio. Application examples include traditional
applications of Default IP Networks
These six 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.
B.4 Support of Priority & Reliability Attributes
Priority and reliability attributes are the same for User-Network and
Network-Network signaling requirements. No standards exist with respect
to the qualitative (e.g., number of priority classes) or quantitative
(e.g., time-to-restore) aspects of reliability. To that extent, the
following assumptions are made in determining reliability attributes:
a. Reliability can be requested in the form of a Priority Class for a
specific network function, such as CAC priority.
b. There are a limited number of Priority Classes to ensure scalability
(e.g., 3 classes).
Two types of Priority Class attributes are defined:
a. CAC Priority Class: The urgency with which a service connection is
desired (e.g., High, Normal, Best Effort).
b. Restoration Priority Class: The urgency with which a service requires
successful restoration under failure conditions (e.g., High, Normal,
Best Effort). We suggest a mechanism consistent with setup and holding
priority similar to what exists in DiffServ TE [DS-TE]. Perhaps this
could be specified as a priority object in [QoS-SIG].
B.4.1 CAC Priority Class
Admission control policies give preference to traffic streams deemed to
be more critical by a service provider under conditions of congestion.
CAC priority class is a way of giving preference to admit higher
priority flows ahead of lower priority flows. A high-priority service
flow can be admitted in preference over a normal-priority service flow,
and in Table 2 three CAC priorities are given - high, normal, and best
effort - along with example service applications:
Table 2. CAC Priority Class
High CAC Priority: Critical services such as emergency
communications services, key business
services, control traffic
Normal CAC Priority: Non-critical services such as normal VoIP
consumer services, normal email data
traffic
Best Effort CAC Priority: Lower priority services such as WWW/HTTP
transactions
B.4.2. Restoration Priority Class
Table 3 defines restoration priority class as either high, normal, or
best-effort.
Table 3. Restoration Priority Class
High Restoration Priority: Critical Services such as emergency
communications services, key business
services, control traffic
Normal Restoration Priority: Non-critical services such as normal
VoIP consumer services, normal email
data traffic
Best Effort Restoration Priority: Lower priority services such as
WWW/HTTP transactions
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.
Optical transport networks, wavelength division multiplexing, and
automatic switched optical networks (ASON) promise fast provisioning of
a wide range of bandwidths (OC-3, OC-12, OC-48, OC-192). A network
operator may flexibly choose to provide different protection/restoration
options at various multiple transport levels (e.g. OTN, SONET section
level, SONET path level), for different physical areas within the
network. Restoration is broadly defined here as the response from a
network under conditions of failure. Potential methods for failure
recovery include automatic protection switching for line/path
protections and shared mesh restoration methods.
A service provider can assign a priority to traffic streams for
restoration. Each restoration class has two parameters:
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:
High Restoration Priority: Time-to-Restore <= 200 ms
Normal Restoration Priority: Time-to-Restore <= 2 s.
Best Effort Restoration Priority: Time-to-Restore == 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.
B.5. Examples of QoS Signaling Requirements Based on Y.1541 QoS Classes
B.5.1. User-Network Signaling
An example of the network response for 'QoS Class acceptance and
parameter level indication' is a case where the network provider commits
to the requested Class and indicates the achieved performance for Delay
and Delay Variation supporting the Class 0 objectives. The values
indicated are simply estimates of performance, and the only binding
commitment is to the QoS Class. In the following tables, acceptance of
the QoS Class indicates commitment to its objectives.
Table 4. Example of QoS Class Acceptance
with Specified Parameter Indications
Field Name Value MandatoryField?
QoS Class Requested Class 0 Yes
QoS Class Response Accept Yes
Mean Transfer Delay (IPTD) 80 ms No
99.9% - min Delay Var. (IPDV) 20 ms No
Loss (IPLR) No
Errored Packets (IPER) No
An example of the network response for 'QoS Class rejection and
alternate class commitment and indications' is a case where the network
provider rejects the requested Class and offers another Class with a
specified parameter indication for Delay.
Table 5. Example of QoS Class rejection
with alternative offer and indications
Field Name Value MandatoryField?
QoS Class Requested Class 0 Yes
QoS Class Response Reject Yes
QoS Class Offered Class 1 No
Mean Transfer Delay (IPTD) 180 ms No
99.9% - min Delay Var. (IPDV) No
Loss (IPLR) No
Errored Packets (IPER) No
B.5.2. Network-Network Signaling
Signaling must communicate the consumption of the network (source-UNI to
destination-UNI) QoS objectives. The fields used in signaling may take
several forms:
Table 6. Example of Accumulating & Signaling Current Performance
Requested Currently Achieved
QoS Class Class 0 Class 0
Mean Transfer Delay (IPTD) 100 ms 20 ms
99.9% - min Delay Var. (IPDV) 50 ms 10 ms
Loss (IPLR) 10^-3 <10^-3
Errored Packets (IPER) 10^-4 <10^-4
Status of Parameter Indications Allowed
Note that the requested parameter values are fully specified by the QoS
Class, but are included in this table for simple comparison. Only the
achieved values and the requested/achieved Class number require
signaling fields.
The network receiving this message determines its performance from
entrance node to the destination, or to the most likely exit node to the
best-next network. The network would add its contribution to the
Currently Achieved fields (according to a specified set of summation
rules for each parameter), and send these fields on to the next network
or back toward the requesting user. Participating networks can indicate
their willingness to indicate specific parameter values (where a single
negative preference overrides others). In case the requested QoS Class
is not achieved, the response can contain the committed performance in
excess of the offered Class, using the Currently Achieved values.
The ability for each network to enter and communicate its contribution
to the achieved performance level is a network option, an example is
shown below:
Table 7. Example of Accumulating & Signaling Current Performance
Requested Network 1 Network 2 Currently
Achieved
QoS Class Class 0 Class 0 Class 0 Class 0
Mean Transfer Delay 100 ms 20 ms 10 ms 30 ms
(IPTD)
99.9% - min Delay Var. 50 ms 10 ms 10 ms 15 ms
(IPDV)
Loss (IPLR) 10^-3 <10^-3 <10^-3 <10^-3
Errored Packets (IPER) 10^-4 <10^-4 <10^-4 <10^-4
Status of Parameters Allowed Allowed Allowed
Indications
A complete tabulation of the accumulated performance would allow
corrective network actions if the Requested Class were not achieved.
Summation rules are simple for transfer delay. Average values for each
network are added to the currently achieved value. More study is needed
to determine the summation rules for delay variation and other
parameters.
10. Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it or
assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are included
on all such copies and derivative works.
However, this document itself may not be modified in any way, such as by
removing the copyright notice or references to the Internet Society or
other Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be followed,
or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK
FORCE DISCLAIMS 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.
| PAFTECH AB 2003-2026 | 2026-04-23 01:40:45 |