< draft-ietf-nsis-qos-nslp-02.txt   draft-ietf-nsis-qos-nslp-03.txt >
Next Steps in Signaling S. Van den Bosch Next Steps in Signaling S. Van den Bosch
Internet-Draft Alcatel Internet-Draft Alcatel
Expires: August 16, 2004 G. Karagiannis Expires: November 9, 2004 G. Karagiannis
University of Twente/Ericsson University of Twente/Ericsson
A. McDonald A. McDonald
Siemens/Roke Manor Research Siemens/Roke Manor Research
February 16, 2004 May 11, 2004
NSLP for Quality-of-Service signaling NSLP for Quality-of-Service signaling
draft-ietf-nsis-qos-nslp-02.txt draft-ietf-nsis-qos-nslp-03.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 16, 2004. This Internet-Draft will expire on November 9, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This draft describes an NSIS Signaling Layer Protocol (NSLP) for This draft describes an NSIS Signaling Layer Protocol (NSLP) for
signaling QoS reservations in the Internet. It is in accordance with signaling QoS reservations in the Internet. It is in accordance with
the framework and requirements developed in NSIS. the framework and requirements developed in NSIS.
Together with the NTLP, it provides functionality similar to RSVP and Together with GIMPS, it provides functionality similar to RSVP and
extends it. The QoS-NSLP is independent of the underlying QoS extends it. The QoS-NSLP is independent of the underlying QoS
specification or architecture and provides support for different specification or architecture and provides support for different
reservation models. It is simplified by the elimination of support reservation models. It is simplified by the elimination of support
for multicast flows. for multicast flows.
This version of the draft focuses on the basic protocol structure. It This version of the draft focuses on the basic protocol structure.
identifies the different message types and describes the basic It identifies the different message types and describes the basic
operation of the protocol to create, refresh, modify and teardown a operation of the protocol to create, refresh, modify and teardown a
reservation or to obtain information on the characteristics of the reservation or to obtain information on the characteristics of the
associated data path. associated data path.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. document are to be interpreted as described in RFC 2119.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Scope and background . . . . . . . . . . . . . . . . . . . . 5 1.1 Scope and background . . . . . . . . . . . . . . . . . . . 6
1.2 Model of operation . . . . . . . . . . . . . . . . . . . . . 5 1.2 Model of operation . . . . . . . . . . . . . . . . . . . . 6
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 8 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . 9 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 10
3.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . . 10 3.1 QoS Models . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2 NTLP Interactions . . . . . . . . . . . . . . . . . . . . . 10 3.2 GIMPS Interactions . . . . . . . . . . . . . . . . . . . . 11
3.3 Authentication and authorization . . . . . . . . . . . . . . 10 3.3 Authentication and authorization . . . . . . . . . . . . . 11
3.4 Aggregation . . . . . . . . . . . . . . . . . . . . . . . . 11 3.4 Aggregation . . . . . . . . . . . . . . . . . . . . . . . 12
3.5 Examples of QoS NSLP Operation . . . . . . . . . . . . . . . 11 3.5 Examples of QoS NSLP Operation . . . . . . . . . . . . . . 12
3.5.1 Simple Resource Reservation . . . . . . . . . . . . . . . . 12 3.5.1 Simple Resource Reservation . . . . . . . . . . . . . 13
3.5.2 Sending a Query . . . . . . . . . . . . . . . . . . . . . . 13 3.5.2 Sending a Query . . . . . . . . . . . . . . . . . . . 14
3.5.3 Use of Local QoS Models . . . . . . . . . . . . . . . . . . 14 3.5.3 Basic Receiver Initiated Reservation . . . . . . . . . 15
3.5.4 Aggregate Reservations . . . . . . . . . . . . . . . . . . . 15 3.5.4 Bidirectional Reservations . . . . . . . . . . . . . . 17
3.5.5 Reduced State or stateless Interior Nodes . . . . . . . . . 16 3.5.5 Use of Local QoS Models . . . . . . . . . . . . . . . 20
4. Design decisions . . . . . . . . . . . . . . . . . . . . . . 18 3.5.6 Aggregate Reservations . . . . . . . . . . . . . . . . 21
4.1 Message types . . . . . . . . . . . . . . . . . . . . . . . 18 3.5.7 Reduced State or Stateless Interior Nodes . . . . . . 23
4.1.1 RESERVE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 3.6 Authorization Model Examples . . . . . . . . . . . . . . . 25
4.1.2 QUERY . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.1 Authorization for the two party approach . . . . . . . 25
4.1.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.6.2 Token based three party approach . . . . . . . . . . . 26
4.1.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 3.6.3 Generic three party approach . . . . . . . . . . . . . 26
4.2 Control information . . . . . . . . . . . . . . . . . . . . 20 4. Design decisions . . . . . . . . . . . . . . . . . . . . . . . 27
4.2.1 Message sequencing . . . . . . . . . . . . . . . . . . . . . 20 4.1 Message types . . . . . . . . . . . . . . . . . . . . . . 27
4.2.2 Requesting responses . . . . . . . . . . . . . . . . . . . . 21 4.1.1 RESERVE . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.3 Message scoping . . . . . . . . . . . . . . . . . . . . . . 22 4.1.2 QUERY . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2.4 State timers . . . . . . . . . . . . . . . . . . . . . . . . 22 4.1.3 RESPONSE . . . . . . . . . . . . . . . . . . . . . . . 29
4.2.5 Session binding . . . . . . . . . . . . . . . . . . . . . . 23 4.1.4 NOTIFY . . . . . . . . . . . . . . . . . . . . . . . . 29
4.3 Layering . . . . . . . . . . . . . . . . . . . . . . . . . . 23 4.2 Control information . . . . . . . . . . . . . . . . . . . 30
4.3.1 Local QoS models . . . . . . . . . . . . . . . . . . . . . . 23 4.2.1 Message sequencing . . . . . . . . . . . . . . . . . . 30
4.3.2 Local control plane properties . . . . . . . . . . . . . . . 24 4.2.2 Requesting responses . . . . . . . . . . . . . . . . . 31
4.3.3 Aggregate reservations . . . . . . . . . . . . . . . . . . . 25 4.2.3 Message scoping . . . . . . . . . . . . . . . . . . . 31
4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 25 4.2.4 State handling . . . . . . . . . . . . . . . . . . . . 32
4.5 Priority . . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.5 State timers . . . . . . . . . . . . . . . . . . . . . 32
4.6 Rerouting . . . . . . . . . . . . . . . . . . . . . . . . . 26 4.2.6 Session binding . . . . . . . . . . . . . . . . . . . 33
4.7 State storage . . . . . . . . . . . . . . . . . . . . . . . 28 4.3 Layering . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.8 Authentication and authorization . . . . . . . . . . . . . . 29 4.3.1 Local QoS models . . . . . . . . . . . . . . . . . . . 34
4.8.1 Policy Ignorant Nodes . . . . . . . . . . . . . . . . . . . 29 4.3.2 Local control plane properties . . . . . . . . . . . . 35
4.8.2 Policy Data . . . . . . . . . . . . . . . . . . . . . . . . 30 4.3.3 Aggregate reservations . . . . . . . . . . . . . . . . 35
5. QoS-NSLP Functional specification . . . . . . . . . . . . . 31 4.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . 36
5.1 QoS-NSLP Message Formats . . . . . . . . . . . . . . . . . . 31 4.5 Priority . . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.1 Common header . . . . . . . . . . . . . . . . . . . . . . . 31 4.6 Rerouting . . . . . . . . . . . . . . . . . . . . . . . . 37
5.1.2 Object Formats . . . . . . . . . . . . . . . . . . . . . . . 32 4.7 State storage . . . . . . . . . . . . . . . . . . . . . . 39
5.1.3 RESERVE Messages . . . . . . . . . . . . . . . . . . . . . . 34 4.8 Authentication and authorization . . . . . . . . . . . . . 40
5.1.4 QUERY Messages . . . . . . . . . . . . . . . . . . . . . . . 37 4.8.1 Policy Ignorant Nodes . . . . . . . . . . . . . . . . 40
5.1.5 RESPONSE Messages . . . . . . . . . . . . . . . . . . . . . 38 4.8.2 Policy Data . . . . . . . . . . . . . . . . . . . . . 41
5.1.6 NOTIFY Messages . . . . . . . . . . . . . . . . . . . . . . 40 5. QoS-NSLP Functional specification . . . . . . . . . . . . . . 42
6. IANA considerations . . . . . . . . . . . . . . . . . . . . 40 5.1 QoS-NSLP Message and Object Formats . . . . . . . . . . . 42
7. Requirements for the NSIS Transport Layer Protocol (NTLP) . 42 5.1.1 Common header . . . . . . . . . . . . . . . . . . . . 42
7.1 Session identification . . . . . . . . . . . . . . . . . . . 42 5.1.2 Object Formats . . . . . . . . . . . . . . . . . . . . 42
7.2 Support for bypassing intermediate nodes . . . . . . . . . . 42 5.2 General Processing Rules . . . . . . . . . . . . . . . . . 44
7.3 Support for peer change identification . . . . . . . . . . . 42 5.2.1 State Manipulation . . . . . . . . . . . . . . . . . . 44
7.4 Support for stateless operation . . . . . . . . . . . . . . 43 5.2.2 Message Forwarding . . . . . . . . . . . . . . . . . . 44
7.5 Last node detection . . . . . . . . . . . . . . . . . . . . 43 5.2.3 Standard Message Processing Rules . . . . . . . . . . 44
7.6 Re-routing detection . . . . . . . . . . . . . . . . . . . . 44 5.3 Object Processing . . . . . . . . . . . . . . . . . . . . 45
7.7 Priority of signalling messages . . . . . . . . . . . . . . 44 5.3.1 Reservation Sequence Number . . . . . . . . . . . . . 45
7.8 Knowledge of intermediate QoS NSLP unaware nodes . . . . . . 44 5.3.2 Response Request . . . . . . . . . . . . . . . . . . . 45
7.9 NSLP Data Size . . . . . . . . . . . . . . . . . . . . . . . 44 5.3.3 Bound Session ID . . . . . . . . . . . . . . . . . . . 46
7.10 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.4 Refresh Period . . . . . . . . . . . . . . . . . . . . 46
8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.5 Scoping . . . . . . . . . . . . . . . . . . . . . . . 47
8.1 Aggregation error handling . . . . . . . . . . . . . . . . . 45 5.3.6 Error Spec . . . . . . . . . . . . . . . . . . . . . . 48
8.2 Region scoping . . . . . . . . . . . . . . . . . . . . . . . 45 5.3.7 Policy Data . . . . . . . . . . . . . . . . . . . . . 48
8.3 Priority of reservations . . . . . . . . . . . . . . . . . . 45 5.3.8 QSpec . . . . . . . . . . . . . . . . . . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . 46 5.4 Message Processing Rules . . . . . . . . . . . . . . . . . 48
9.1 Introduction and Threat Overview . . . . . . . . . . . . . . 46 5.4.1 RESERVE Messages . . . . . . . . . . . . . . . . . . . 48
9.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . . . 47 5.4.2 QUERY Messages . . . . . . . . . . . . . . . . . . . . 49
9.3 QoS Authorization . . . . . . . . . . . . . . . . . . . . . 49 5.4.3 RESPONSE Messages . . . . . . . . . . . . . . . . . . 51
9.3.1 Authorization for the two party approach . . . . . . . . . . 49 5.4.4 NOTIFY Messages . . . . . . . . . . . . . . . . . . . 52
9.3.2 Token based three party approach . . . . . . . . . . . . . . 50 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 52
9.3.3 Generic three party approach . . . . . . . . . . . . . . . . 52 7. Requirements for the NSIS Transport Layer Protocol (GIMPS) . . 54
9.3.4 Computing the authorization decision . . . . . . . . . . . . 54 7.1 Session identification . . . . . . . . . . . . . . . . . . 54
10. Change History . . . . . . . . . . . . . . . . . . . . . . . 55 7.2 Support for bypassing intermediate nodes . . . . . . . . . 54
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 55 7.3 Support for peer change identification . . . . . . . . . . 54
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 55 7.4 Support for stateless operation . . . . . . . . . . . . . 55
Normative References . . . . . . . . . . . . . . . . . . . . 55 7.5 Last node detection . . . . . . . . . . . . . . . . . . . 55
Informative References . . . . . . . . . . . . . . . . . . . 55 7.6 Re-routing detection . . . . . . . . . . . . . . . . . . . 56
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57 7.7 Priority of signalling messages . . . . . . . . . . . . . 56
A. Object Definitions . . . . . . . . . . . . . . . . . . . . . 58 7.8 Knowledge of intermediate QoS NSLP unaware nodes . . . . . 56
A.1 RESPONSE_REQUEST Class . . . . . . . . . . . . . . . . . . . 58 7.9 NSLP Data Size . . . . . . . . . . . . . . . . . . . . . . 56
A.2 RSN Class . . . . . . . . . . . . . . . . . . . . . . . . . 59 7.10 Notification of NTLP 'D' flag value . . . . . . . . . . . 56
A.3 REFRESH_PERIOD Class . . . . . . . . . . . . . . . . . . . . 59 7.11 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 57
A.4 SESSION_ID Class . . . . . . . . . . . . . . . . . . . . . . 60 8. Assumptions on the QoS model . . . . . . . . . . . . . . . . . 57
A.5 SCOPING Class . . . . . . . . . . . . . . . . . . . . . . . 60 8.1 Resource sharing . . . . . . . . . . . . . . . . . . . . . 57
A.6 ERROR_SPEC Class . . . . . . . . . . . . . . . . . . . . . . 61 8.2 Reserve/commit support . . . . . . . . . . . . . . . . . . 57
A.7 POLICY_DATA Class . . . . . . . . . . . . . . . . . . . . . 62 9. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 57
A.7.1 Base Format . . . . . . . . . . . . . . . . . . . . . . . . 62 9.1 Region scoping . . . . . . . . . . . . . . . . . . . . . . 57
A.7.2 Options . . . . . . . . . . . . . . . . . . . . . . . . . . 63 9.2 Priority of reservations . . . . . . . . . . . . . . . . . 58
A.7.3 Policy Elements . . . . . . . . . . . . . . . . . . . . . . 64 9.3 Peering agreements on interdomain links . . . . . . . . . 58
A.8 QSPEC Class . . . . . . . . . . . . . . . . . . . . . . . . 66 9.4 GIMPS Modifications for Refresh Overhead Reduction . . . . 59
Intellectual Property and Copyright Statements . . . . . . . 67 9.5 Path state maintenance implementation at NSLP . . . . . . 59
9.6 GIMPS Path State Maintenance . . . . . . . . . . . . . . . 59
9.7 Protocol Operating Environment Assumptions . . . . . . . . 60
10. Security Considerations . . . . . . . . . . . . . . . . . . 60
10.1 Introduction and Threat Overview . . . . . . . . . . . . . 61
10.2 Trust Model . . . . . . . . . . . . . . . . . . . . . . . 62
10.3 Computing the authorization decision . . . . . . . . . . . 64
11. Change History . . . . . . . . . . . . . . . . . . . . . . . 64
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 65
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 65
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 65
14.1 Normative References . . . . . . . . . . . . . . . . . . . . 65
14.2 Informative References . . . . . . . . . . . . . . . . . . . 66
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 68
A. Object Definitions . . . . . . . . . . . . . . . . . . . . . . 68
A.1 RESPONSE_REQUEST Class . . . . . . . . . . . . . . . . . . 68
A.2 RSN Class . . . . . . . . . . . . . . . . . . . . . . . . 69
A.3 REFRESH_PERIOD Class . . . . . . . . . . . . . . . . . . . 69
A.4 SESSION_ID Class . . . . . . . . . . . . . . . . . . . . . 70
A.5 SCOPING Class . . . . . . . . . . . . . . . . . . . . . . 71
A.6 ERROR_SPEC Class . . . . . . . . . . . . . . . . . . . . . 71
A.7 POLICY_DATA Class . . . . . . . . . . . . . . . . . . . . 72
A.7.1 Base Format . . . . . . . . . . . . . . . . . . . . . 73
A.7.2 Options . . . . . . . . . . . . . . . . . . . . . . . 73
A.7.3 Policy Elements . . . . . . . . . . . . . . . . . . . 74
A.8 QSPEC Class . . . . . . . . . . . . . . . . . . . . . . . 76
Intellectual Property and Copyright Statements . . . . . . . . 77
1. Introduction 1. Introduction
1.1 Scope and background 1.1 Scope and background
This document defines a Quality of Service (QoS) NSIS Signaling Layer This document defines a Quality of Service (QoS) NSIS Signaling Layer
Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This Protocol (NSLP), henceforth referred to as the "QoS-NSLP". This
protocol establishes and maintains state at nodes along the path of a protocol establishes and maintains state at nodes along the path of a
data flow for the purpose of providing some forwarding resources for data flow for the purpose of providing some forwarding resources for
that flow. It is intended to satisfy the QoS-related requirements of that flow. It is intended to satisfy the QoS-related requirements of
[15]. This QoS-NSLP is part of a larger suite of signaling protocols, [14]. This QoS-NSLP is part of a larger suite of signaling
whose structure is outlined in [3]; this defines a common NSIS protocols, whose structure is outlined in [15]; this defines a common
Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out many NSIS Transport Layer Protocol (NTLP) which QoS-NSLP uses to carry out
aspects of signaling message delivery. The specification of the NTLP many aspects of signaling message delivery. The specification of the
is done in another document [4]. NTLP is done in another document [3].
The design of QoS-NSLP is conceptually similar to RSVP [6], and uses The design of QoS-NSLP is conceptually similar to RSVP [5], and uses
soft-state peer-to-peer refresh messages as the primary state soft-state peer-to-peer refresh messages as the primary state
management mechanism (i.e. state installation/refresh is performed management mechanism (i.e. state installation/refresh is performed
between pairs of adjacent NSLP nodes, rather than in an end-to-end between pairs of adjacent NSLP nodes, rather than in an end-to-end
fashion along the complete signalling path. Although there is no fashion along the complete signalling path). Although there is no
backwards compatibility at the level of protocol messages, backwards compatibility at the level of protocol messages,
interworking with RSVP at a signaling application gateway would be interworking with RSVP at a signaling application gateway would be
possible in some circumstances. QoS-NSLP extends the set of possible in some circumstances. QoS-NSLP extends the set of
reservation mechanisms to meet the requirements of [15], in reservation mechanisms to meet the requirements of [14], in
particular support of sender or receiver-initiated reservations, as particular support of sender or receiver-initiated reservations, as
well as a type of bi-directional reservation and support of well as a type of bi-directional reservation and support of
reservations between arbitrary nodes, e.g. edge-to-edge, reservations between arbitrary nodes, e.g. edge-to-edge,
end-to-access, etc. On the other hand, there is no support for IP end-to-access, etc. On the other hand, there is no support for IP
multicast. multicast.
QoS-NSLP does not mandate any specific 'QoS Model', i.e. a particular QoS-NSLP does not mandate any specific 'QoS Model', i.e. a
QoS provisioning method or QoS architecture; this is similar to (but particular QoS provisioning method or QoS architecture; this is
stronger than) the decoupling between RSVP and the IntServ similar to (but stronger than) the decoupling between RSVP and the
architecture [5]. It should be able to carry information for various IntServ architecture [4]. It should be able to carry information for
QoS models; the specification of Integrated Services for use with various QoS models; the specification of Integrated Services for use
RSVP given in [7] could form the basis of one QoS model. with RSVP given in [6] could form the basis of one QoS model.
1.2 Model of operation 1.2 Model of operation
This section presents a logical model for the operation of the QoS- This section presents a logical model for the operation of the QoS-
NSLP and associated provisioning mechanisms within a single node. It NSLP and associated provisioning mechanisms within a single node. It
is adapted from the discussion in section 1 of [6]. The model is is adapted from the discussion in section 1 of [5]. The model is
shown in Figure 1. shown in Figure 1.
+---------------+ +---------------+
| Local | | Local |
|Applications or| |Applications or|
|Management (e.g| |Management (e.g|
|for aggregates)| |for aggregates)|
+---------------+ +---------------+
^ ^
^ ^
V V
V V
+----------+ +----------+ +---------+ +----------+ +----------+ +---------+
| QoS-NSLP | | Resource | | Policy | | QoS-NSLP | | Resource | | Policy |
|Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control | |Processing|<<<<<<>>>>>>>|Management|<<<>>>| Control |
+----------+ +----------+ +---------+ +----------+ +----------+ +---------+
. ^ | * ^ . ^ | * ^
| V . * ^ | V . * ^
+----------+ * ^ +----------+ * ^
| NTLP | * ^ | GIMPS | * ^
|Processing| * V |Processing| * V
+----------+ * V +----------+ * V
| | * V | | * V
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
. . * V . . * V
| | * ............................. | | * .............................
. . * . Traffic Control . . . * . Traffic Control .
| | * . +---------+. | | * . +---------+.
. . * . |Admission|. . . * . |Admission|.
| | * . | Control |. | | * . | Control |.
skipping to change at page 6, line 48 skipping to change at page 7, line 48
+----------+ +------------+ .+----------+ +---------+. +----------+ +------------+ .+----------+ +---------+.
............................. .............................
<.-.-> = signaling flow <.-.-> = signaling flow
=====> = data flow (sender --> receiver) =====> = data flow (sender --> receiver)
<<<>>> = control and configuration operations <<<>>> = control and configuration operations
****** = routing table manipulation ****** = routing table manipulation
Figure 1: QoS-NSLP in a Node Figure 1: QoS-NSLP in a Node
This diagram shows an example implementation scenario where QoS This diagram shows an example implementation scenario where QoS
conditioning is performed on the output interface. However, this does conditioning is performed on the output interface. However, this
not limit the possible implementations. For example, in some cases does not limit the possible implementations. For example, in some
traffic conditioning may be performed on the incoming interface, or cases traffic conditioning may be performed on the incoming
it may be split over the input and output interfaces. interface, or it may be split over the input and output interfaces.
From the perspective of a single node, the request for QoS may result From the perspective of a single node, the request for QoS may result
from a local application request, or from processing an incoming QoS- from a local application request, or from processing an incoming QoS-
NSLP message. NSLP message.
o The 'local application case' includes not only user applications o The 'local application case' includes not only user applications
(e.g. multimedia applications) but also network management (e.g. (e.g. multimedia applications) but also network management (e.g.
initiating a tunnel to handle an aggregate, or interworking with initiating a tunnel to handle an aggregate, or interworking with
some other reservation protocol - such as RSVP). In this sense, some other reservation protocol - such as RSVP) and the policy
the model does not distinguish between hosts and routers. control module (e.g. for explicit teardown triggered by AAA). In
this sense, the model does not distinguish between hosts and
routers.
o The 'incoming message' case requires NSIS messages to be captured o The 'incoming message' case requires NSIS messages to be captured
during input packet processing and handled by the NTLP. Only during input packet processing and handled by GIMPS. Only
messages related to QoS are passed to the QoS-NSLP. The NTLP may messages related to QoS are passed to the QoS-NSLP. GIMPS may
also generate triggers to the QoS-NSLP (e.g. indications that a also generate triggers to the QoS-NSLP (e.g. indications that a
route change has occurred). route change has occurred).
The QoS request is handled by a local 'resource management' function, The QoS request is handled by a local 'resource management' function,
which coordinates the activities required to grant and configure the which coordinates the activities required to grant and configure the
resource. resource.
o The grant processing involves two local decision modules, 'policy o The grant processing involves two local decision modules, 'policy
control' and 'admission control'. Policy control determines control' and 'admission control'. Policy control determines
whether the user has administrative permission to make the whether the user has administrative permission to make the
reservation. Admission control determines whether the node has reservation. Admission control determines whether the node has
sufficient available resources to supply the requested QoS. sufficient available resources to supply the requested QoS.
o If both checks succeed, parameters are set in the packet o If both checks succeed, parameters are set in the packet
classifier and in the link layer interface (e.g., in the packet classifier and in the link layer interface (e.g., in the packet
scheduler) to obtain the desired QoS. Error notifications are scheduler) to obtain the desired QoS. Error notifications are
passed back to the request originator. The resource management passed back to the request originator. The resource management
function may also manipulate the forwarding tables at this stage, function may also manipulate the forwarding tables at this stage,
to select (or at least pin) a route; this must be done before to select (or at least pin) a route; this must be done before
interface-dependent actions are carried out (including forwarding interface-dependent actions are carried out (including forwarding
outgoing messages over any new route), and is in any case outgoing messages over any new route), and is in any case
invisible to the operation of the protocol. invisible to the operation of the protocol.
Policy control is expected to make use of a AAA service external to Policy control is expected to make use of a AAA service external to
the node itself. Some discussion can be found in [16] and [17]. More the node itself. Some discussion can be found in [16] and [17].
generally, the processing of policy and resource management functions More generally, the processing of policy and resource management
may be outsourced to an external node leaving only 'stubs' co-located functions may be outsourced to an external node leaving only 'stubs'
with the NSLP; this is not visible to the protocol operation, co-located with the NSLP; this is not visible to the protocol
although it may have some influence on the detailed design of operation, although it may have some influence on the detailed design
protocol messages to allow the stub to be minimally complex. of protocol messages to allow the stub to be minimally complex. A
more detailed discussion on authentication and authorization can be
found in Section 4.8. The definition of the POLICY_DATA class is
given in Appendix A.7.
The group of user plane functions, which implement QoS for a flow The group of user plane functions, which implement QoS for a flow
(admission control, packet classification, and scheduling) is (admission control, packet classification, and scheduling) is
sometimes known as 'traffic control'. sometimes known as 'traffic control'.
Admission control, packet scheduling, and any part of policy control Admission control, packet scheduling, and any part of policy control
beyond simple authentication have to be implemented using specific beyond simple authentication have to be implemented using specific
definitions for types and levels of QoS; we refer to this as a QoS definitions for types and levels of QoS; we refer to this as a QoS
model. Our assumption is that the QoS-NSLP is independent of the QoS model. Our assumption is that the QoS-NSLP is independent of the QoS
model, that is, QoS parameters (e.g. IntServ service elements) are model, that is, QoS parameters (e.g. IntServ service elements) are
interpreted only by the resource management and associated functions, interpreted only by the resource management and associated functions,
and are opaque to the QoS-NSLP itself. QoS Models are discussed and are opaque to the QoS-NSLP itself. QoS Models are discussed
further in Section 3.1. further in Section 3.1.
The final stage of processing for a resource request is to indicate The final stage of processing for a resource request is to indicate
to the QoS-NSLP protocol processing that the required resources have to the QoS-NSLP protocol processing that the required resources have
been configured. The QoS-NSLP may generate an acknowledgement message been configured. The QoS-NSLP may generate an acknowledgement
in one direction, and may propagate the resource request forwards in message in one direction, and may propagate the resource request
the other. Message routing is (by default) carried out by the NTLP forwards in the other. Message routing is (by default) carried out
module. Note that while Figure 1 shows a unidirectional data flow, by GIMPS module. Note that while Figure 1 shows a unidirectional
the signaling messages can pass in both directions through the node, data flow, the signaling messages can pass in both directions through
depending on the particular message and orientation of the the node, depending on the particular message and orientation of the
reservation. reservation.
2. Terminology 2. Terminology
The terminology defined in [3] applies to this draft. In addition, The terminology defined in [3] applies to this draft. In addition,
the following terms are used: the following terms are used:
QNE: an NSIS Entity (NE), which supports the QoS-NSLP. QNE: an NSIS Entity (NE), which supports the QoS-NSLP.
QNI: the first node in the sequence of QNEs that issues a reservation QNI: the first node in the sequence of QNEs that issues a reservation
request. request for a session.
QNR: the last node in the sequence of QNEs that receives a QNR: the last node in the sequence of QNEs that receives a
reservation request. reservation request for a session.
Source or message source: The one of two adjacent NSLP peers that is Source or message source: The one of two adjacent NSLP peers that is
sending a signalling message (maybe the upstream or the downstream sending a signalling message (maybe the upstream or the downstream
peer). NB: this is not necessarily the QNI. peer). NB: this is not necessarily the QNI.
QoS NSLP nodes QoS NSLP nodes
IP address (QoS unware NSIS nodes are IP address IP address (QoS unware NSIS nodes are IP address
= Flow not shown) = Flow = Flow not shown) = Flow
Source | | | Destination Source | | | Destination
Address | | | Address Address | | | Address
V V V V V V
+--------+ Data +------+ +------+ +------+ +--------+ +--------+ Data +------+ +------+ +------+ +--------+
| Flow |-------|------|------|------|-------|------|---->| Flow | | Flow |-------|------|------|------|-------|------|---->| Flow |
| Sender | Flow | | | | | | |Receiver| | Sender | Flow | | | | | | |Receiver|
+--------+ | QNI | | QNE | | QNR | +--------+ +--------+ | QNI | | QNE | | QNR | +--------+
| | | | | | | | | | | |
+------+ +------+ +------+ +------+ +------+ +------+
=====================> =====================>
<===================== <=====================
Signaling Signaling
Flow Flow
3. Protocol Overview 3. Protocol Overview
The QoS NSLP uses four message types: RESERVE, QUERY, RESPONSE and The QoS NSLP uses four message types: RESERVE, QUERY, RESPONSE and
NOTIFY. These contain three types of objects: Control Information NOTIFY. These contain three types of objects: Control Information
(CI), QSpecs, and Policy objects. The set of objects permissible (CI), QSpecs, and Policy objects. The set of objects permissible
depends on the message type. depends on the message type.
Messages are passed to the NTLP to be delivered to neighbouring NSIS An interface exists between the NSLP processing and GIMPS processing
nodes. Similarly, QoS NSLP data from NTLP messages is passed to the for sending/receiving NSIS messages. In addition to the NSLP message
QoS NSLP component for processing. Additional meta-data (e.g. session data itself, other meta-data (e.g. session identifier, flow routing
identifier, NSLP identifier) can also be sent in both directions. information) can be transferred across this interface.
The QoS NSLP separates the actual description of resources from the
QoS signalling protocol used to transport them. It uses
interchangeable QoS Models that allow the resource specification to
be performed in various ways, and to provide different processing
models (including reserve/commit models, measurement based models,
etc).
Control information objects carry general information for the QoS Control information objects carry general information for the QoS
NSLP processing, such as sequence numbers or whether a response is NSLP processing, such as sequence numbers or whether a response is
required. required.
QSpec objects describe the actual resources that are required and are QSpec objects describe the actual resources that are required and are
specific to the QoS Model being used. Besides any resource specific to the QoS Model being used. Besides any resource
description they may also contain QoS Model specific control description they may also contain QoS Model specific control
information used by the QoS Model's processing. information used by the QoS Model's processing.
The Policy objects contain data used to authorise the reservation of The Policy objects contain data used to authorise the reservation of
resources. resources.
3.1 QoS Models 3.1 QoS Models
A QoS model is a defined mechanism for achieving QoS as a whole. The 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 specification of a QoS model includes a description of its QoS
parameter information, as well as how that information should be parameter information, as well as how that information should be
treated or interpreted in the network. In that sense, the QoS model treated or interpreted in the network. In that sense, the QoS model
goes beyond the QoS-NSLP protocol level in that it could also goes beyond the QoS-NSLP protocol level in that it could also
describe underlying assumptions, conditions and/or specific describe underlying assumptions, conditions and/or specific
provisioning mechanisms appropriate for it. provisioning mechanisms appropriate for it.
A QoS model provides a specific set of parameters to be carried in A QoS model provides a specific set of parameters to be carried in
the QSpec, or restricts the values these parameters can take. the QSpec, or restricts the values these parameters can take.
Integrated Services [5], Differentiated Services [9] and RMD [22] are Integrated Services [4], Differentiated Services [8] and RMD [22] are
all examples that could provide the basis of an NSIS QoS model. There all examples that could provide the basis of an NSIS QoS model.
is no restriction on the number of QoS models. QoS models may be There is no restriction on the number of QoS models. QoS models may
local (private to one network), implementation/vendor specific, or be local (private to one network), implementation/vendor specific, or
global (implementable by different networks and vendors). The authors global (implementable by different networks and vendors). The
are currently aware of three efforts related to QoS model authors are currently aware of three efforts related to QoS model
specification: [18], [19] and [20]. This specification will not specification: [18], [19] and [20]. This specification will not
attempt to select between the moppling number of possible QoS models. attempt to select between the moppling number of possible QoS models.
The QSpec contains a set of parameters and values describing the The QSpec contains a set of parameters and values describing the
requested resources. It is opaque to the QoS-NSLP and similar in requested resources. It is opaque to the QoS-NSLP and similar in
purpose to the TSpec, RSpec and AdSpec specified in [6][7]. At each purpose to the TSpec, RSpec and AdSpec specified in [5][6]. At each
QNE, its content is interpreted by the resource management function QNE, its content is interpreted by the resource management function
for the purposes of policy control and traffic control (including for the purposes of policy control and traffic control (including
admission control and configuration of the packet classifier and admission control and configuration of the packet classifier and
scheduler). scheduler).
3.2 NTLP Interactions 3.2 GIMPS Interactions
The QoS NSLP uses the NTLP for delivery of all its messages. Messages The QoS NSLP uses GIMPS for delivery of all its messages. Messages
are normally passed from the NSLP to the NTLP via an API, which also are normally passed from the NSLP to the GIMPS via an API, which also
specifies additional information, including an identifier for the specifies additional information, including an identifier for the
signaling application (e.g. 'QoS-NSLP'), the flow/session identifier, signaling application (e.g. 'QoS-NSLP'), the flow/session
and an indication of the intended direction - towards data sender or identifier, and an indication of the intended direction - towards
receiver. On reception, the NTLP provides the same information to the data sender or receiver. On reception, GIMPS provides the same
QoS-NSLP. information to the QoS-NSLP.
The QoS NSLP does not provide any method of interacting with The QoS NSLP does not provide any method of interacting with
firewalls or Network Address Translators (NATs). It assumes that a firewalls or Network Address Translators (NATs). It assumes that a
basic NAT traversal service is provided by the NTLP (as described in basic NAT traversal service is provided by the GIMPS.
the requirement given in Section 7.10).
3.3 Authentication and authorization 3.3 Authentication and authorization
The QoS signaling protocol needs to exchange information which is The QoS signaling protocol needs to exchange information which is
subsequently used as input to the AAA infrastructure. The response subsequently used as input to the AAA infrastructure. The response
from the AAA infrastructure must also returned and processed by the from the AAA infrastructure must also returned and processed by the
respective entities. respective entities.
+-------------+ +-------------+
| Entity | | Entity |
| authorizing | | authorizing |
| resource | | resource |
| request | | request |
+-----+-------+ +-----+-------+
| |
skipping to change at page 11, line 29 skipping to change at page 12, line 27
|| || || ||
\\\\ //// \\\\ ////
\-------+-----/ \-------+-----/
| |
+-------------+ QoS signaling +---+--+ +-------------+ QoS signaling +---+--+
| Entity |<=================>| |<=========> | Entity |<=================>| |<=========>
| requesting | Data Flow | QNE | | requesting | Data Flow | QNE |
| resource |-------------------|------|----------> | resource |-------------------|------|---------->
+-------------+ +------+ +-------------+ +------+
3.4 Aggregation 3.4 Aggregation
In some cases it is desirable to create reservations for an In some cases it is desirable to create reservations for an
aggregate, rather than on a per-flow basis, in order to reduce the aggregate, rather than on a per-flow basis, in order to reduce the
amount of reservation state needed as well as the processing load for amount of reservation state needed as well as the processing load for
signalling messages. signalling messages.
The QoS NSLP, therefore, provides facilities to provide similar The QoS NSLP, therefore, provides facilities to provide similar
aggregation facilities to [11]. However, the aggregation scenarios aggregation facilities to [10]. However, the aggregation scenarios
supported are wider than that proposed there. supported are wider than that proposed there. Aggregate reservations
are further described in Section 4.3.3.
3.5 Examples of QoS NSLP Operation 3.5 Examples of QoS NSLP Operation
The QoS NSLP can be used in a number ways. The examples given here The QoS NSLP can be used in a number ways. The examples given here
give an indication of some of the basic processing. However, they are give an indication of some of the basic processing. However, they
not exhaustive and do not attempt to cover the details of the are not exhaustive and do not attempt to cover the details of the
protocol processing. protocol processing.
3.5.1 Simple Resource Reservation 3.5.1 Simple Resource Reservation
NI NF NF NR NI NF NF NR
| | | | | | | |
| RESERVE | | | | RESERVE | | |
+--------->| | | +--------->| | |
| | RESERVE | | | | RESERVE | |
| +--------->| | | +--------->| |
| | | RESERVE | | | | RESERVE |
| | +--------->| | | +--------->|
| | | | | | | |
skipping to change at page 12, line 31 skipping to change at page 13, line 31
|<---------+ | | |<---------+ | |
| | | | | | | |
| | | | | | | |
Figure 4: Basic Sender Initiated Reservation Figure 4: Basic Sender Initiated Reservation
To make a new reservation, the QNI constructs a RESERVE message To make a new reservation, the QNI constructs a RESERVE message
containing a QSpec object, from its chosen QoS model, which describes containing a QSpec object, from its chosen QoS model, which describes
the required QoS parameters. the required QoS parameters.
The RESERVE message is passed to the NTLP which transports it to the The RESERVE message is passed to GIMPS which transports it to the
next QoS NSLP node. There it is delivered to the QoS NSLP processing next QoS NSLP node. There it is delivered to the QoS NSLP processing
which examines the message. Policy control and admission control which examines the message. Policy control and admission control
decisions are made. The exact processing also takes into account the decisions are made. The exact processing also takes into account the
QoS Model being used. The node performs appropriate actions (e.g. QoS Model being used. The node performs appropriate actions (e.g.
installing reservation) based on the QSpec object in the message. installing reservation) based on the QSpec object in the message.
The QoS NSLP then generates a new RESERVE message (usually based on The QoS NSLP then generates a new RESERVE message (usually based on
the one received). This is passed to the NTLP, which forwards it to the one received). This is passed to the GIMPS, which forwards it to
the next QNE. the next QNE.
The same processing is performed at further QNEs along the path, up The same processing is performed at further QNEs along the path, up
to the QNR. The determination that a node is the QNR may be made to the QNR. The determination that a node is the QNR may be made
directly (e.g. that node is the destination for the data flow), or directly (e.g. that node is the destination for the data flow), or
using some NTLP functionality to determine that there are no more using some GIMPS functionality to determine that there are no more
QNEs between this node and the data flow destination. QNEs between this node and the data flow destination.
Any node may include a request for a RESPONSE in its RESERVE Any node may include a request for a RESPONSE in its RESERVE
messages. One such use is to confirm the installation of state, which messages. One such use is to confirm the installation of state,
allows the use of summary refreshes that later refer to that state. which allows the use of summary refreshes that later refer to that
The RESPONSE is forwarded peer-to-peer along the reverse of the path state. The RESPONSE is forwarded peer-to-peer along the reverse of
that the RESERVE message took (using NTLP path state), and so is seen the path that the RESERVE message took (using GIMPS path state), and
by all the QNEs on the reverse-path. It is only forwarded as far as so is seen by all the QNEs on the reverse-path. It is only forwarded
the node which requested the RESPONSE. A RESPONSE message can also as far as the node which requested the RESPONSE. A RESPONSE message
indicate an error when, for example, a reservation has failed to be can also indicate an error when, for example, a reservation has
installed. failed to be installed.
The reservation can subsquently be refreshed by sending further The reservation can subsquently be refreshed by sending further
RESERVE messages containing the complete reservation information, as RESERVE messages containing the complete reservation information, as
for the initial reservation. The reservation can also be modified in for the initial reservation. The reservation can also be modified in
the same way, by changing the QoS model specific data to indicate a the same way, by changing the QoS model specific data to indicate a
different set of resources to reserve. different set of resources to reserve.
The overhead required to perform refreshes can be reduced, in a The overhead required to perform refreshes can be reduced, in a
similar way to that proposed for RSVP in [10]. Once a RESPONSE similar way to that proposed for RSVP in [9]. Once a RESPONSE
message has been received indicating the successful installation of a message has been received indicating the successful installation of a
reservation, subsequent refreshing RESERVE messages can simply refer reservation, subsequent refreshing RESERVE messages can simply refer
to the existing reservation, rather than including the complete to the existing reservation, rather than including the complete
reservation specification. reservation specification.
3.5.2 Sending a Query 3.5.2 Sending a Query
QUERY messages can be used to gather information from QNEs along to QUERY messages can be used to gather information from QNEs along to
path. For example, it can be used to find out what resources are path. For example, it can be used to find out what resources are
available before a reservation is made. available before a reservation is made.
In order to perform a query along a path, the QNE constructs a QUERY In order to perform a query along a path, the QNE constructs a QUERY
message. This message includes QoS model specific objects containing message. This message includes QoS model specific objects containing
the actual query to be performed at QoS NSLP nodes along the path. It the actual query to be performed at QoS NSLP nodes along the path.
also contains an object used to match the response back to the query, It also contains an object used to match the response back to the
and an indicator of the query scope (next node, whole path). query, and an indicator of the query scope (next node, whole path).
The QUERY message is passed to the NTLP to forward it along the path. The QUERY message is passed to GIMPS to forward it along the path.
The NTLP may use datagram mode or connection mode for forwarding the
QUERY message.
A QNE (including the QNR) receiving a QUERY message should inspect it A QNE (including the QNR) receiving a QUERY message should inspect it
and create a new message, based on that received with the query and create a new message, based on that received with the query
objects modified as required. For example, the query may request objects modified as required. For example, the query may request
information on whether a flow can be admitted, and so a node information on whether a flow can be admitted, and so a node
processing the query might record the available bandwidth. The new processing the query might record the available bandwidth. The new
message is then passed to the NTLP for further forwarding (unless it message is then passed to GIMPS for further forwarding (unless it
knows it is the QNR, or is the limit for the scope in the QUERY). knows it is the QNR, or is the limit for the scope in the QUERY).
At the QNR, a RESPONSE message is generated. Into this is copied At the QNR, a RESPONSE message must be generated if the QUERY
various objects from the received QUERY message. It is then passed to includes a RESPONSE_REQUEST object. Into this is copied various
the NTLP to be forwarded peer-to-peer back along the path. This makes objects from the received QUERY message. It is then passed to GIMPS
use of the neighbour state retained by the NTLP, and may use datagram to be forwarded peer-to-peer back along the path.
or connection mode.
Each QNE receiving the RESPONSE message should inspect the Each QNE receiving the RESPONSE message should inspect the
ResponseRequest object to see if it 'belongs' to it (i.e. it was the RESPONSE_REQUEST object to see if it 'belongs' to it (i.e. it was
one that originally created it). If it does not then it simply passes the one that originally created it). If it does not then it simply
the message back to the NTLP to be forwarded back down the path. passes the message back to GIMPS to be forwarded back down the path.
3.5.3 Use of Local QoS Models 3.5.3 Basic Receiver Initiated Reservation
In some cases it may be required to use a different QoS Model along a As described in [15] in some signaling applications, a node at one
particular segment of the signalling. In this case a node at the edge end of the data flow takes responsibility for requesting special
of this region needs to map between the two resource descriptions treatment - such as a resource reservation - from the network. Both
(and any auxiliary data). ends then agree whether sender or receiver initiated reservation is
to be done. In case of a receiver initiated reservation, both ends
agree whether a "One Pass With Advertising" (OPWA) [23] model is
being used. This negotiation can be accomplished using mechanisms
that are outside the scope of NSIS, see Section 9.7.
+--------+ +----+----+ +--------+ +----+----+ +--------+ To make a receiver initiated reservation, see Figure 5, the QNI
| QM1 | |QM1 | QM2| | QM2 | |QM2 | QM1| | QM1 | constructs a QUERY message containing a QSpec object, from its chosen
+--------+ +----+----+ +--------+ +----+----+ +--------+ QoS model, which describes, among others, the required QoS
|QoS-NSLP| |QoS-NSLP | |QoS-NSLP| |QoS-NSLP | |QoS-NSLP| parameters. This QUERY message does not need to trigger a RESPONSE
+--------+ +---------+ +--------+ +---------+ +--------+ message and therefore, the QNI must not include the RESPONSE_REQUEST
| NTLP |===| NTLP |===| NTLP |===| NTLP |===| NTLP | object, see Section 5.4.2, into the QUERY message. The QUERY message
+--------+ +---------+ +--------+ +---------+ +--------+ may be used to to gather information along the path, which is carried
by the QSPEC object. An example of such information is the "One Pass
With Advertising" (OPWA) [23]. This QUERY message is instructing the
QoS-NSLP process running on each QNE's located on the path followed
by this QUERY message to install GIMPS reverse-path state.
<-------> <--------------------> <-------> NI NF NF NR
RESV{QSpec1} RESV{QSpec1,QSpec2} RESV{QSpec1} | | | |
| QUERY | | |
+--------->| | |
| | QUERY | |
| +--------->| |
| | | QUERY |
| | +--------->|
| | | |
| | | RESERVE |
| | |<---------+
| | RESERVE | |
| |<---------+ |
| RESERVE | | |
|<---------+ | |
| | | |
| RESPONSE | | |
+--------->| | |
| | RESPONSE | |
| +--------->| |
| | | RESPONSE |
| | +--------->|
| | | |
Figure 5: Reservation with local QoS Models Figure 5: Basic Receiver Initiated Reservation
The QUERY message is transported by the NTLP to the next downstream
QoS NSLP node. There it is delivered to the QoS NSLP processing
which examines the message. The exact processing also takes into
account the QoS Model being used. The node performs appropriate
actions, such as installing GIMPS reverse path state. Another action
that may be performed by the node is to gather advertising
information that may be used to predict the end-to-end QoS.
The QoS NSLP then generates a new QUERY message (usually based on the
one received). This is passed to the NTLP, which forwards it to the
next QNE. The same processing is performed at further QNEs along the
path, up to the receiver, which in this situation is the QNR. The
QNR detects that this QUERY message does not carry a RESPONSE_REQUEST
object and by using the information contained in the received QUERY
message, such as the QSPEC, constructs a RESERVE message, which can
be used as a reservation request.
The RESERVE message must follow the same path that has been followed
by the QUERY message. Therefore, the NTLP is informed, over the
NSLP/NTLP API, to pass the message upstream, i.e., by setting the
GIMPS "D" flag, see [3].
The RESERVE is forwarded peer-to-peer along the reverse of the path
that the QUERY message took (using the NTLP reverse path state). It
is only forwarded as far as the QNI. The RESERVE message received by
a QNE is delivered to the QoS-NSLP processing, which examines the
message. The NTLP includes the value of the 'D' flag in the
information it passes with the message over the NTLP/NSLP API
(Section 7.10). The exact processing of this message is accomplished
in the same way as for the processing of a RESERVE message received
by a QNE in a sender initiated approach. The main difference is that
the RESERVE message has to be forwarded peer-to-peer along the
reverse of the path that the QUERY message took. Therefore, the
QoS-NSLP functionality of each QNE requires the NTLP, over the NSLP/
NTLP API, to pass the message upstream, i.e.,by setting the GIMPS "D"
flag.
Similar to the sender initiated approach, any node may include a
request for a RESPONSE in its RESERVE messages. The RESPONSE is
forwarded peer-to-peer along the path that the initial QUERY message
took (using NTLP path state). It is only forwarded as far as the
node which requested the RESPONSE. Note that the use of RESPONSE is
optional.
The reservation can subsquently be refreshed in the same was as for
the refresh procedure of a reservation in a sender initiated
approach, by sending further RESERVE messages containing the complete
reservation information, as for the initial reservation. This
RESERVE message may be also used to refresh the NTLP reverse path
state. Additionally, refreshing the NTLP reverse path state could be
performed by sending periodic QUERY messages. However, it might
potentially also be done by the NTLP, without needing any downstream
NSLP messages. This is an open issue (see Section 9.6), and it will
be worked out in a future version of this draft.
3.5.4 Bidirectional Reservations
A bi-directional reservation combines the reservations for a pair of
coupled flows going in opposite directions. The main difficulty here
is that the two flows, although between the same end points, may
traverse different paths across the Internet.
We distinguish two types of bi-directional reservations:
o sender+sender: where a sender-initiated reservation is done in one
direction, e.g., from QNE A towards QNE B, and then another
sender-initiated reservation that is done back, the opposite
direction, i.e., from QNE B towards QNE A,
o sender+receiver: where a sender-initiated reservation is done in
one direction, e.g., from QNE A towards QNE B, and a
receiver-initiated reservation that is done for the opposite
direction, i.e., a reservation from QNE A towards QNE B for the
data flow from QNE B to QNE A.
Both ends have to agree on which bi-directional reservation type they
need to use. This negotiation/agreement can be accomplished using
mechanisms that are outside the scope of NSIS, see Section 9.7.
In the sender+sender bi-directional reservation scenario (see Figure
6) the QNI, i.e., QNE A, generates a sender initiated reservation by
creating and sending a RESERVE message towards the QNR, i.e., QNE B.
When performing this type of bi-directional reservation, there are
situations where the QNR, i.e., QNE B, is not able to retrieve the
QoS parameter set required to perform a reservation in the downstream
direction from QNE B to QNE A, while the QNI, i.e., QNE A, is able to
retrieve and maintain the Qos parameter sets required to perform the
reservation in both downstream directions. In these situations there
is a need to carry both QoS parameter sets in QoS-NSLP messages from
the QNI, i.e., QNE A, to the QNR, i.e., QNE B.
The RESERVE is passed to the NTLP, which forwards it to the next QNE.
The same processing is performed at further QNEs along the path, up
to the receiver, which in this situation is the QNR, i.e., QNE B.
Considering that the QNE B, knows that it has to start a
sender-initiated reservation, the QNE B creates and sends a RESERVE
message downstream towards the QNE A. This RESERVE message carries
among others the QoS parameter set required to perform the sender
initiated reservation in the downstream direction from QNE B to QNE
A. Furthermore, the QNI, (i.e., QNE A), and QNR, (i.e., QNE B),
might be willing to bind the two sessions. In this situation the
QoS-NSLP messages that are used in the direction from QNE B to QNE A,
may carry information that identifies the two bound sessions. This
can be accomplished by using the BOUND_SESSION_ID object.
Note that any node may generate RESPONSE messages as answer to the
received RESERVE messages, but this is optional.
A NF1 NF2 NF3 NF4 B
| RESERVE | | | | |
+--------->|RESERVE | | | |
| +-------------------->| RESERVE | |
| | | +-------------------->|
| | | | | RESERVE |
| | | RESERVE | |<---------|
| RESERVE | |<--------------------| |
|<--------------------| | | |
| | | | | |
Figure 6: Bi-directional reservation for sender+sender scenario
In the sender+receiver bi-directional reservation scenario (see
Figure 7) the QNI, i.e., QNE A, generates both a sender initiated and
a receiver-initiated reservation. Note that before that the QNI,
i.e., QNE A, is starting this procedure it must receive a QUERY
message from the QNR, i.e., QNE B, that requires from the QNI a
receiver initiated reservation, see Section 3.5.3. Note that the
QUERY message is carrying the QSPEC that can be used by the receiver
initiated reservation.
The QNI, i.e., QNE A, creates two RESERVE messages. One RESERVE
message that is used for the sender initiated reservation (session
A->B), see Section [(reference to the sender initiated section)] and
another RESERVE message that is used for the receiver initiated
reservation (session B->A), see Section 3.5.3. Furthermore, the
QNI, (i.e., QNE A), and QNR, (i.e., QNE B), might be willing to bind
the two sessions. In this situation the QoS-NSLP messages that are
used in the bi-directional scenario may carry information that
identifies the two bound sessions. This can be accomplished by using
the BOUND_SESSION_ID object. When these two RESERVE messages follow
exactly the same path, then it should be possible that these two
RESERVE messages are bundled at the NTLP level, by using the GIMPS
message bundling feature.
Note that any node may generate RESPONSE messages as answer to the
received RESERVE messages, but this is optional.
A NF1 NF2 B
| | | QUERY |
| | QUERY |<--------------------|
| QUERY |<--------------------| |
|<---------+ | |
| RESERVE | | |
+--------->|RESERVE | |
| +-------------------->| RESERVE |
| | +-------------------->|
| RESERVE | | |
+--------->|RESERVE | |
| +-------------------->| RESERVE |
| | +-------------------->|
| | | |
Figure 7: Bi-directional reservation for sender+receiver scenario
3.5.5 Use of Local QoS Models
In some cases it may be required to use a different QoS Model along a
particular segment of the signalling. In this case a node at the
edge of this region needs to map between the two resource
descriptions (and any auxiliary data).
| | | | |
| RESERVE | | | |
| {QSpec1} | | | |
+-------------->| | | |
| | RESERVE | | |
| |{QSpec2,QSpec1}| | |
| +-------------->| | |
| | | RESERVE | |
| | |{QSpec2,QSpec1}| |
| | +-------------->| |
| | | | RESERVE |
| | | | {QSpec1} |
| | | +-------------->|
| | | | |
Figure 8: Reservation with local QoS Models
This initially proceeds as for the basic example, with peer-to-peer This initially proceeds as for the basic example, with peer-to-peer
installation of reservations. However, within a region of the network installation of reservations. However, within a region of the
a different QoS Model needs to be used. At the edge of this region network a different QoS Model needs to be used. At the edge of this
the QNEs support both the end-to-end and local QoS models. When the region the QNEs support both the end-to-end and local QoS models.
RESERVE message reaches the QNE at the ingress, the initial
processing of the RESERVE proceeds as normal. However, the QNE also When the RESERVE message reaches the QNE at the ingress, the initial
processing of the RESERVE proceeds as normal. However, the QNE also
determines the appropriate description using the second QoS model. determines the appropriate description using the second QoS model.
The RESERVE message to be sent out is constructed mostly as usual but The RESERVE message to be sent out is constructed mostly as usual but
with a second QSpec object added, which becomes the 'current' one. with a second QSpec object added, which becomes the 'current' one.
When this RESERVE message is received at the next node the QoS NSLP When this RESERVE message is received at the next node the QoS NSLP
only uses the QSpec at the top of the stack (i.e. the 'current' one), only uses the QSpec at the top of the stack (i.e. the 'current'
rather than the end-to-end QSpec. Otherwise, processing proceeds as one), rather than the end-to-end QSpec. Otherwise, processing
usual. The RESERVE message that it generates should include the proceeds as usual. The RESERVE message that it generates should
complete stack of QSpecs from the message it received. include the complete stack of QSpecs from the message it received.
At the QNE at the egress of the region the local QSpec is removed At the QNE at the egress of the region the local QSpec is removed
from the message so that subsequent QNEs receive only the end-to-end from the message so that subsequent QNEs receive only the end-to-end
QSpec. QSpec.
QSpecs can be stacked in this way to an arbitrary depth. QSpecs can be stacked in this way to an arbitrary depth.
3.5.4 Aggregate Reservations 3.5.6 Aggregate Reservations
In order to reduce signalling and per-flow state in the network, the In order to reduce signalling and per-flow state in the network, the
reservations for a number of flows may be aggregated together. reservations for a number of flows may be aggregated together.
NI NF NF/NI' NF' NR'/NF NR NI NF NF/NI' NF' NR'/NF NR
aggregator deaggregator aggregator deaggregator
| | | | | | | | | | | |
| RESERVE | | | | | | RESERVE | | | | |
+--------->| | | | | +--------->| | | | |
| | RESERVE | | | | | | RESERVE | | | |
skipping to change at page 15, line 36 skipping to change at page 22, line 31
| | | | | RESPONSE | | | | | | RESPONSE |
| | | | RESPONSE |<---------+ | | | | RESPONSE |<---------+
| | |<--------------------+ | | | |<--------------------+ |
| | RESPONSE | | | | | | RESPONSE | | | |
| |<---------+ | | | | |<---------+ | | |
| RESPONSE | | | | | | RESPONSE | | | | |
|<---------+ | | | | |<---------+ | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
Figure 6: Sender Initiated Reservation with Aggregation Figure 9: Sender Initiated Reservation with Aggregation
An end-to-end per-flow reservation is initiated as normal (with An end-to-end per-flow reservation is initiated as normal (with
messages shown in Figure 6 as "RESERVE"). messages shown in Figure 9 as "RESERVE").
At the aggregator a reservation for the aggregated flow is initiated At the aggregator a reservation for the aggregated flow is initiated
(shown in Figure 6 as "RESERVE'"). This may use the same QoS model as (shown in Figure 9 as "RESERVE'"). This may use the same QoS model
the end-to-end reservation but has a flow identifier for the as the end-to-end reservation but has a flow identifier for the
aggregated flow (e.g. tunnel) instead of for the individual flows. aggregated flow (e.g. tunnel) instead of for the individual flows.
Markings are used so that intermediate routers do not need to inspect Markings are used so that intermediate routers do not need to inspect
the individual flow reservations. This might be done by creating an the individual flow reservations. The deaggregator then becomes the
NTLP connection mode association between the aggregator and next hop QoS NSLP node for the end-to-end per-flow reservation.
deaggregator for the end-to-end reservation.
Aggregator Deaggregator Aggregator Deaggregator
+---+ +---+ +---+ +---+ +---+ +---+ +---+ +---+
|QNI|-----|QNE|-----|QNE|-----|QNR| aggregate |QNI|-----|QNE|-----|QNE|-----|QNR| aggregate
+---+ +---+ +---+ +---+ reservation +---+ +---+ +---+ +---+ reservation
+---+ +---+ ..... ..... +---+ +---+ +---+ +---+ ..... ..... +---+ +---+
|QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end |QNI|-----|QNE|-----. .-----. .-----|QNE|-----|QNR| end-to-end
+---+ +---+ ..... ..... +---+ +---+ reservation +---+ +---+ ..... ..... +---+ +---+ reservation
The deaggregator acts as the QNR for the aggregate reservation. The deaggregator acts as the QNR for the aggregate reservation.
Information is carried in the reservations to enable the deaggregator Information is carried in the reservations to enable the deaggregator
to associate the end-to-end and aggregate reservations with one to associate the end-to-end and aggregate reservations with one
another. For example, this is necessary so that the size of the another. For example, this is necessary so that the size of the
aggregate reservation can be reduced when the end-to-end reservation aggregate reservation can be reduced when the end-to-end reservation
is removed. is removed.
The key difference between this example, and previous ones is that The key difference between this example, and previous ones is that
the flow identifier for the aggregate is expected to be different to the flow identifier for the aggregate is expected to be different to
that for the end-to-end reservation. The aggregate reservation can be that for the end-to-end reservation. The aggregate reservation can
updated independently of the per-flow end-to-end reservations. be updated independently of the per-flow end-to-end reservations.
3.5.5 Reduced State or stateless Interior Nodes 3.5.7 Reduced State or Stateless Interior Nodes
This example uses a different QoS model within a domain, in This example uses a different QoS model within a domain, in
conjunction with NTLP and NSLP functionality which allows the conjunction with GIMPS and NSLP functionality which allows the
interior nodes to avoid storing NTLP and QoS NSLP state. As a result interior nodes to avoid storing GIMPS and QoS NSLP state. As a
the interior nodes only store the QoS model specific reservation result the interior nodes only store the QoS model specific
state, or even no state at all. This allows the QoS model to use a reservation state, or even no state at all. This allows the QoS
form of "reduced-state" operation, where reservation states with a model to use a form of "reduced-state" operation, where reservation
coarser granularity (e.g. per-class) are used, or a "stateless" states with a coarser granularity (e.g. per-class) are used, or a
operation where no reservation state is needed (or created). "stateless" operation where no reservation state is needed (or
created).
The key difference between this example and the use of different QoS The key difference between this example and the use of different QoS
Models in Section 3.5.3 is that the transport characteristics for the Models in Section 3.5.5 is that the transport characteristics for the
'local' reservation can be different from that of the end-to-end 'local' reservation can be different from that of the end-to-end
reservation, i.e. the NTLP can be used in a different way for the reservation, i.e. GIMPS can be used in a different way for the
edge-to-edge and hop-by-hop sessions. The reduced state reservation edge-to-edge and hop-by-hop sessions. The reduced state reservation
can be updated independently of the per-flow end-to-end reservations. can be updated independently of the per-flow end-to-end reservations.
NF NF NF NF NF NF NF NF
ingress interior interior egress ingress interior interior egress
NTLP stateful NTLP stateless NTLP stateless NTLP stateful GIMPS stateful GIMPS stateless GIMPS stateless GIMPS stateful
| | | | | | | |
RESERVE | | | | RESERVE | | | |
-------->| RESERVE | | | -------->| RESERVE | | |
+--------------------------------------------->| +--------------------------------------------->|
| RESERVE' | | | | RESERVE' | | |
+-------------->| | | +-------------->| | |
| | RESERVE' | | | | RESERVE' | |
| +-------------->| | | +-------------->| |
| | | RESERVE' | | | | RESERVE' |
| | +------------->| | | +------------->|
| | | | RESERVE | | | | RESERVE
| | | +--------> | | | +-------->
| | | | RESPONSE | | | | RESPONSE
| | | |<-------- | | | |<--------
| | | RESPONSE | | | | RESPONSE |
|<---------------------------------------------+ |<---------------------------------------------+
RESPONSE| | | | RESPONSE| | | |
<--------| | | | <--------| | | |
Figure 8: Reservation with Reduced State Interior Nodes Figure 11: Reservation with Reduced State Interior Nodes
The QNI performs the same processing as before to generate the The QNI performs the same processing as before to generate the
initial RESERVE message, and it is forwarded by the NTLP as usual. At initial RESERVE message, and it is forwarded by GIMPS as usual. At
the QNEs at the edges of the stateless or reduced-state region the the QNEs at the edges of the stateless or reduced-state region the
processing is different and the nodes support two QoS models. processing is different and the nodes support two QoS models.
At the ingress the original RESERVE message is forwarded but using At the ingress the original RESERVE message is forwarded but ignored
facilities provided by the NTLP to bypass the stateless or by the stateless or reduced-state nodes. The egress node is the next
reduced-state nodes. After the initial discovery phase using datagram QoS NSLP hop for that session. After the initial discovery phase
mode, connection mode between the ingress and egress can be used. At using datagram mode, connection mode between the ingress and egress
the egress node the RESERVE message is then forwarded normally. can be used. At the egress node the RESERVE message is then
forwarded normally.
At the ingress a second RESERVE' message is also built. This makes At the ingress a second RESERVE' message is also built. This makes
use of a QoS model suitable for a reduced state or stateless form of use of a QoS model suitable for a reduced state or stateless form of
operation (such as the RMD per hop reservation). When processed by operation (such as the RMD per hop reservation). When processed by
interior (stateless) nodes the QoS NSLP processing excercises its interior (stateless) nodes the QoS NSLP processing excercises its
options to not keep state wherever possible, so that no QoS NSLP options to not keep state wherever possible, so that no per flow QoS
state is stored. Some state, e.g. per class, for the QoS model NSLP state is stored. Some state, e.g. per class, for the QoS model
related data may be held at these interior nodes. The QoS NSLP also related data may be held at these interior nodes. The QoS NSLP also
requests that the NTLP use different transport characteristics (i.e. requests that GIMPS use different transport characteristics (i.e.
sending of messages in datagram mode, and not retaining optional path sending of messages in datagram mode, and not retaining optional
state). reverse path state).
Nodes, such as those in the interior of the stateless or Nodes, such as those in the interior of the stateless or
reduced-state domain, that do not retain reservation state (and so reduced-state domain, that do not retain reservation state cannot
cannot use summary refreshes) cannot send back RESPONSE messages. send back RESPONSE messages (and so cannot use summary refreshes).
At the egress node the RESERVE' message is interpreted in conjunction At the egress node the RESERVE' message is interpreted in conjunction
with the reservation state from the end-to-end RESERVE message (using with the reservation state from the end-to-end RESERVE message (using
information carried in the message to correlate the signalling information carried in the message to correlate the signalling
flows). The RESERVE message is only forwarded further if the flows). The RESERVE message is only forwarded further if the
processing of the RESERVE' message was successful at all nodes in the processing of the RESERVE' message was successful at all nodes in the
local domain, otherwise the end-to-end reservation is regarded as local domain, otherwise the end-to-end reservation is regarded as
having failed to be installed. having failed to be installed.
Since NTLP neighbour relations are not maintained in the Since GIMPS neighbour relations are not maintained in the
reduced-state region, only sender initiated signalling can be reduced-state region, only sender initiated signalling can be
supported. If a bi-directional reservation is required then the supported. If a bi-directional reservation is required then the
interior QoS model must provide an object that requests the egress end-to-end QoS model must provide an object that requests the last
node to generate a sender initiated session in the reverse direction. node to generate a sender initiated session in the reverse direction.
4. Design decisions 3.6 Authorization Model Examples
4.1 Message types Various authorization models can be used in conjunction with the QoS
NSLP.
3.6.1 Authorization for the two party approach
The two party approach is conceptually the simplest authorization
model.
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
financial establishment
Figure 12: Two party approach
In this example the the authorization decision only involves the two
entities, or makes use of previous authorisation using an out-of-band
mechanism to avoid the need for active participation of an external
entity during the NSIS protocol execution.
This type of model may be applicable, for example, between two
neighboring networks (inter-domain signaling) where a long-term
contract (or other out-of-band mechanisms) exist to manage charging
and provide sufficient information to authorize individual requests.
3.6.2 Token based three party approach
An alternative approach makes use of authorization tokens, such as
those described in [11] and [12] or used as part of the Open
Settlement protocol [27]. The former ('authorization tokens') are
used to associate two different signaling protocols (i.e. SIP and
NSIS) and their authorization with each other whereas the latter is a
form of digital money. As an example, with the authorization token
mechanism, some form of authorization is provided by the SIP proxy,
which acts as the resource authorizing entity in Figure 13. If the
request is authorized, then the SIP signaling returns an
authorization token which can be included in the QoS signaling
protocol messages to refer to the previous authorization decision.
The tokens themselves may take a number of different forms, some of
which may require the entity performing the QoS reservation to query
external state.
Authorization
Token Request +--------------+
+-------------->| Entity C | financial settlement
| | authorizing | <..................+
| | resource | .
| +------+ request | .
| | +--------------+ .
| | .
| |Authorization .
| |Token .
| | .
| | .
| | .
| | QoS request .
+-------------+ + Authz. Token +--------------+ .
| Entity |----------------->| Entity B | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <..+
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 13: Token based three party approach
For the digital money type of systems (e.g. OSP tokens), the token
represents a limited amount of credit. So, new tokens must be sent
with later refresh messages once the credit is exhausted.
3.6.3 Generic three party approach
Another method is for the node performing the QoS reservation to
delegate the authorization decision to a third party, as illustrated
in Figure 14.
+--------------+
| Entity C |
| authorizing |
| resource |
| request |
+-----------+--+
^ |
| |
QoS | | QoS
authz| |authz
req.| | res.
| |
QoS | v
+-------------+ request +--+-----------+
| Entity |----------------->| Entity B |
| requesting | | performing |
| resource |granted / rejected| QoS |
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 14: Three party approach
Authorization may be performed on a per-request basis, periodically,
or on a per-session basis. The authorization request might make use
of EAP authentication between entities A and C, and a subsequent
protocol exchange between A and B to create a secure channel for
further communications. Such a technique gives flexibility in terms
of the authentication and key exchange protocols used.
A further extension to this model is to allow Entity C to reference a
AAA server in the user's home network when making the authorization
decision.
4. Design decisions
4.1 Message types
The QoS-NSLP specifies four message types: RESERVE, QUERY, RESPONSE The QoS-NSLP specifies four message types: RESERVE, QUERY, RESPONSE
and NOTIFY. and NOTIFY.
The fundamental properties of each message determine how it is The fundamental properties of each message determine how it is
analyzed from the perspective of re-ordering, loss, end-to-end analyzed from the perspective of re-ordering, loss, end-to-end
reliability and so on. It is important for applications to know reliability and so on. It is important for applications to know
whether NSLP messages can be repeated, discarded or merged and so on whether NSLP messages can be repeated, discarded or merged and so on
(e.g. for edge mobility support, rerouting, etc). Indeed, the (e.g. for edge mobility support, rerouting, etc). Indeed, the
ordering of messages that do not manipulate state at QNEs matters ordering of messages that do not manipulate state at QNEs does not
little, whereas the way that messages that manipulate state are matter, whereas the way that messages that manipulate state are
interleaved matters very much. Therefore NSLP is designed such that interleaved matters very much. Therefore NSLP is designed such that
the message type identifies whether a message is manipulating state the message type identifies whether a message is manipulating state
(in which case it is idempotent) or not (it is impotent). (in which case it is idempotent) or not (it is impotent).
4.1.1 RESERVE 4.1.1 RESERVE
The RESERVE message is the only message that manipulates QoS The RESERVE message is the only message that manipulates QoS
reservation state. It is used to create, refresh, modify and remove reservation state. It is used to create, refresh, modify and remove
such state. The common message header contains a TEAR flag that such state. The common message header contains a TEAR flag that
indicates complete QoS NSLP state removal (as opposed to a indicates complete QoS NSLP state removal (as opposed to a
reservation of zero resources). The TEAR flag indicates to the NTLP reservation of zero resources). This QoS NSLP state comprises
that the corresponding NTLP (reverse) state is not required. The NTLP reservation state and QoS NSLP operation state. The QoS NSLP
the autonomously decides whether to keep such state or not. indicates to GIMPS that it is no longer interested in the
corresponding GIMPS state. The GIMPS then autonomously decides
whether or not to keep this state.
The RESERVE message opaquely transports one or more QSPEC objects, The RESERVE message opaquely transports one or more QSPEC objects,
describing the desired service level and a POLICY_DATA object, describing the desired service level and a POLICY_DATA object,
authorizing the requestor of the service. It carries the lifetime of authorizing the requestor of the service. It carries the lifetime of
the reservation in the Common Control Information. the reservation in the Common Control Information.
RESERVE messages are sent peer-to-peer. This means that a QNE RESERVE messages are sent peer-to-peer. This means that a QNE
considers its adjacent upstream or downstream peer to be the source considers its adjacent upstream or downstream peer to be the source
of the RESERVE message. of the RESERVE message.
The RESERVE message is idempotent; the resultant effect is the same The RESERVE message is idempotent; the resultant effect is the same
whether a message is received once or many times. In addition, the whether a message is received once or many times. In addition, the
ordering of RESERVE messages matters - an old RESERVE message should ordering of RESERVE messages matters - an old RESERVE message should
not replace a newer one. Both of these features are required for not replace a newer one. Both of these features are required for
protocol robustness - messages may be re-ordered on route (e.g. protocol robustness - messages may be re-ordered on route (e.g.
because of mobility, or at intermediate NTLP nodes) or spuriously because of mobility, or at intermediate GIMPS nodes) or spuriously
retransmitted. Message re-ordering is supported by the inclusion of retransmitted. Handling of message re-ordering is supported by the
the Reservation Sequence Number (RSN) in the RESERVE message. inclusion of the Reservation Sequence Number (RSN) in the RESERVE
message.
The sender of a RESERVE message may want to receive confirmation of The sender of a RESERVE message may want to receive confirmation of
successful state installation from a downstream node. Therefore, a successful state installation from a downstream node. Therefore, a
RESERVE message optionally contains a RESPONSE_REQUEST object RESERVE message optionally contains a RESPONSE_REQUEST object
(Section 4.2.2). (Section 4.2.2).
4.1.2 QUERY 4.1.2 QUERY
A QUERY message is used to request information about the data path A QUERY message is used to request information about the data path
without making a reservation. This functionality can be used to without making a reservation. This functionality can be used to
'probe' the network for path characteristics or for support of 'probe' the network for path characteristics or for support of
certain QoS models. The information obtained from a QUERY may be used certain QoS models. The information obtained from a QUERY may be
in the admission control process of a QNE (e.g. in case of used in the admission control process of a QNE (e.g. in case of
measurement-based admission control). Note that a QUERY does not measurement-based admission control). Note that a QUERY does not
change existing reservation state, nor does it cause state to be change existing reservation state, nor does it cause state to be
installed in nodes other than the one that generated the QUERY. installed in nodes other than the one that generated the QUERY.
A QUERY message contains one or more QSPEC objects and a POLICY_DATA A QUERY message contains one or more QSPEC objects and a POLICY_DATA
object. The QSPEC object describes what is being queried for and may object. The QSPEC object describes what is being queried for and may
contain objects that gather information along the data path. The contain objects that gather information along the data path. The
POLICY_DATA object authorizes the requestor of the QUERY message. POLICY_DATA object authorizes the requestor of the QUERY message.
A QUERY message may be scoped if a RESPONSE message from some other A QUERY message may be scoped if a RESPONSE message from some other
node than the QNR is desired. node than the QNR is desired.
A QUERY message must contain a RESPONSE_REQUEST object (Section A QUERY message may contain a RESPONSE_REQUEST object (Section
4.2.2), the contents of which allow matching back RESPONSE messages 4.2.2), the contents of which allow matching back RESPONSE messages
to the QUERY request. The RESPONSE_REQUEST object is transported to the QUERY request. The RESPONSE_REQUEST object is transported
unchanged along the data path and may be used to scope the RESPONSE unchanged along the data path and may be used to scope the RESPONSE
to a QUERY message (Section 4.2.3). to a QUERY message (Section 4.2.3).
4.1.3 RESPONSE 4.1.3 RESPONSE
The REPONSE message is used to provide information about the result The REPONSE message is used to provide information about the result
of a previous QoS-NSLP message. This includes explicit confirmation of a previous QoS-NSLP message. This includes explicit confirmation
of the state manipulation signaled in the RESERVE message, the of the state manipulation signaled in the RESERVE message, the
response to a QUERY message or an error code if the QNE or QNR is response to a QUERY message or an error code if the QNE or QNR is
unable to provide the requested information or if the response is unable to provide the requested information or if the response is
negative. For this purpose, the RESPONSE message carries one or more negative. For this purpose, the RESPONSE message carries one or more
QSPEC objects. QSPEC objects.
The RESPONSE message is impotent, it does not cause any state to be The RESPONSE message is impotent, it does not cause any reservation
installed or modified. state to be installed or modified.
The forwarding of the RESPONSE message along the path does not
necessarily imply the existence of NTLP reverse-path state at every
node. For example, the NTLP may have a mechanism to pass a message
directly from the egress to the ingress of a region of QNEs that do
not store per-flow reverse-path state.
4.1.4 NOTIFY 4.1.4 NOTIFY
NOTIFY messages are used to convey information to a QNE. NOTIFY NOTIFY messages are used to convey information to a QNE. NOTIFY
messages are impotent (they do not cause a change in state directly). messages are impotent (they do not cause a change in state directly).
They may carry one or more QSPEC objects. An example use of NOTIFY They may carry one or more QSPEC objects. An example use of NOTIFY
would be to indicate when a reservation has been pre-empted. would be to indicate when a reservation has been pre-empted.
NOTIFY messages differ from RESPONSE messages in that they need not NOTIFY messages differ from RESPONSE messages in that they need not
refer to any particular state or previously received message. They refer to any particular state or previously received message. They
are sent asynchronously. The NOTIFY message itself does not trigger are sent asynchronously. The NOTIFY message itself does not trigger
or mandate any action in the receiving QNE. or mandate any action in the receiving QNE.
The information conveyed by a NOTIFY message is typically related to The information conveyed by a NOTIFY message is typically related to
error conditions. One example would be notification to an upstream error conditions. One example would be notification to an upstream
peer about state being torn down. peer about state being torn down.
4.2 Control information 4.2 Control information
Control information conveys information on how specific messages Control information conveys information on how specific messages
should be handled by a QNE, e.g. sequencing of messages. This may should be handled by a QNE, e.g. sequencing of messages. This may
include some mechanisms that are useful for many QoS models (Common include some mechanisms that are useful for many QoS models (Common
Control Information) and some that are for a particular QoS model Control Information) and some that are for a particular QoS model
only (QoS-model specific Control Information). QoS-model specific only (QoS-model specific Control Information). QoS-model specific
Control Information is specified together with a QoS model. This Control Information is specified together with a QoS model. This
specification only defines Common Control Information. Currently, specification only defines Common Control Information. Currently,
Common Control Information is defined for session identification, Common Control Information is defined for session identification,
message sequencing, response request, message scoping and session message sequencing, response request, message scoping and session
lifetime. lifetime.
4.2.1 Message sequencing 4.2.1 Message sequencing
RESERVE messages affect the installed reservation state. Unlike RESERVE messages affect the installed reservation state. Unlike
NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE NOTIFY, QUERY and RESPONSE messages, the order in which RESERVE
messages are received influences the eventual reservation state that messages are received influences the eventual reservation state that
will be stored at a QNE. Therefore, a QNE may need to detect will be stored at a QNE. Therefore, a QNE may need to detect
re-ordered or duplicated RESERVE messages. re-ordered or duplicated RESERVE messages.
Detection of RESERVE message re-ordering or duplication is supported Detection of RESERVE message re-ordering or duplication is supported
by the Reservation Sequence Number (RSN). The RSN is a counter, by the Reservation Sequence Number (RSN). The RSN is a counter,
locally chosen to be unique (on a hop-by-hop basis) within a session. locally chosen to be unique (on a hop-by-hop basis) within a session.
The RSN has local significance only, i.e. between QNEs. Attempting to The RSN has local significance only, i.e. between QNEs. Attempting
make an identifier that was unique in the context of a SESSION_ID but to make an identifier that was unique in the context of a SESSION_ID
the same along the complete path would be very hard. Since RESERVE but the same along the complete path would be very hard. Since
messages can be sent by any node on the path that maintains RESERVE messages can be sent by any node on the path that maintains
reservation state (e.g. for path repair) we would have the difficult reservation state (e.g. for path repair) we would have the difficult
task of attempting to keep the identifier synchronized along the task of attempting to keep the identifier synchronized along the
whole path. Since message ordering only ever matters between a pair whole path. Since message ordering only ever matters between a pair
of peer QNEs, this means that we can make the Reservation Sequence of peer QNEs, this means that we can make the Reservation Sequence
Number unique just between a pair of neighboring stateful QNEs. By Number unique just between a pair of neighboring stateful QNEs. By
managing the sequence numbers in this manner, the source of the managing the sequence numbers in this manner, the source of the
RESERVE does not need to determine how the next NSLP node will RESERVE does not need to determine how the next NSLP node will
process the message. process the message.
The RSN refers to a particular instance of the RESERVE state. This The RSN refers to a particular instance of the RESERVE state. This
allows explicit acknowledgment of state installation actions (by allows explicit acknowledgment of state installation actions (by
including the RSN in a RESPONSE). It also allows an abbreviated form including the RSN in a RESPONSE). It also allows an abbreviated form
of refreshing RESERVE message ("summary refresh"). In this case, the of refreshing RESERVE message ("summary refresh"). In this case, the
refreshing RESERVE references the reservation using the RSN (and the refreshing RESERVE references the reservation using the RSN (and the
SESSION_ID), rather than including the full reservation specification SESSION_ID), rather than including the full reservation specification
(including QSPEC, ...). Note that summary refreshes require an (including QSPEC, ...). Note that summary refreshes require an
explicit acknowledgment of state installation to ensure that the RSN explicit acknowledgment of state installation to ensure that the RSN
reference will be understood. It is up to a QNE that receives a reference will be understood. It is up to a QNE that receives a
RESPONSE_REQUEST to decide whether it wants to accept summary RESPONSE_REQUEST to decide whether it wants to accept summary
refreshes and provide this explicit acknowledgment. refreshes and provide this explicit acknowledgment.
4.2.2 Requesting responses 4.2.2 Requesting responses
Some QNEs may require explicit responses to messages they send. A QNE Some QNEs may require explicit responses to messages they send. A
which sends a QUERY message (Section 4.1), for instance, will require QNE which sends a QUERY message (Section 4.1), for instance, will
a response with the requested information to be sent to it. A QNE require a response with the requested information to be sent to it.
which sends a RESERVE message may want explicit confirmation that the A QNE which sends a RESERVE message may want explicit confirmation
requested reservation state was installed. that the requested reservation state was installed.
A QNE that desires an explicit response includes a RESPONSE_REQUEST A QNE that desires an explicit response includes a RESPONSE_REQUEST
object in its message. RESPONSE_REQUEST objects are used in RESERVE object in its message. RESPONSE_REQUEST objects are used in RESERVE
and QUERY messages. The RESPONSE_REQUEST object may be used in and QUERY messages. The RESPONSE_REQUEST object may be used in
combination with message scoping (Section 4.2.3) to influence which combination with message scoping (Section 4.2.3) to influence which
QNE will respond. QNE will respond.
A message contains at most one RESPONSE_REQUEST object. The A message contains at most one RESPONSE_REQUEST object. The
RESPONSE_REQUEST object contains Request Identification Information RESPONSE_REQUEST object contains Request Identification Information
(RII) that is unique within a session and different for each message, (RII) that is unique within a session and different for each message,
in order to allow responses to be matched back to requests (without in order to allow responses to be matched back to requests (without
incorrectly matching at other nodes). Downstream nodes that desire incorrectly matching at other nodes). Downstream nodes that desire
responses may keep track of this RII to identify the RESPONSE when it responses may keep track of this RII to identify the RESPONSE when it
passes back through them. passes back through them.
A message containing a RESPONSE_REQUEST object causes a RESPONSE A message containing a RESPONSE_REQUEST object causes a RESPONSE
message to be sent back. The RESPONSE message contains the original message to be sent back. The RESPONSE message contains the original
RESPONSE_REQUEST object and may be scoped, e.g. using the RII RESPONSE_REQUEST object and may be scoped, e.g. using the RII
(Section 4.2.3), to influence which (upstream) QNEs will receive the (Section 4.2.3), to influence which (upstream) QNEs will receive the
RESPONSE. RESPONSE.
4.2.3 Message scoping 4.2.3 Message scoping
For some messages, QNEs may want to restrict message propagation. For For some messages, QNEs may want to restrict message propagation.
a RESERVE message, this may be the case when state installation is For a RESERVE message, this may be the case when state installation
required on part of the path towards the destination only. For a is required on part of the path towards the destination only. For a
QUERY message, it allows limiting the nodes that can respond to the QUERY message, it allows limiting the nodes that can respond to the
QUERY. For a RESPONSE message, it allows limiting the nodes that QUERY. For a RESPONSE message, it allows limiting the nodes that
receive the RESPONSE. receive the RESPONSE.
Message scoping is supported by a SCOPING object. Different scopes Message scoping is supported by a SCOPING object. Different scopes
are supported. By default, no SCOPING object is present which are supported. By default, no SCOPING object is present which
indicates that the scope is either "whole path" or limited by indicates that the scope is either "whole path" or limited by
configuration (and therefore not signalled). Other supported scopes configuration (and therefore not signalled). Other supported scopes
are "single hop" and "back to me". The latter is supported by copying are "single hop" and "back to me". The latter is supported by
the RII from the RESPONSE_REQUEST object into the SCOPING object that copying the RII from the RESPONSE_REQUEST object into the SCOPING
is put in the RESPONSE message, so that its forwarding can be object that is put in the RESPONSE message, so that its forwarding
terminated by the node that requested the RESPONSE. can be terminated by the node that requested the RESPONSE.
It is currently an open issue whether a "region" should be supported This specification does not support an explicit notion of a region
as a separate scope or whether its application is sufficiently scope or "to the CRN". If needed, this can be easily proposed as an
supported by configuration and/or aggregation. extension later on.
4.2.4 State timers 4.2.4 State handling
The default behaviour of a QNE that receives a RESERVE with a
SESSION_ID for which it already has state installed but with a
different flow ID is to replace the existing reservation (and tear
down the reservation on the old branch if the RESERVE is received
with a different SII).
In some cases, this may not be the desired behaviour. In that case,
the QNI or a QNE may set the NO_REPLACE flag in the common header to
indicate that the new session does not replace the existing one. A
QNE that receives a RESERVE with the NO_REPLACE flag set but with the
same SII will update the flow ID and indicate NO_REPLACE to the RMF
(where it will be used for the resource handling). If the SII is
different, this means that the QNE is a merge point. In that case,
the NO_REPLACE also indicates that a tearing RESERVE SHOULD NOT be
sent on the old branch.
At a QNE, resource handling is performed by the RMF. For sessions
with the NO_REPLACE flag set, we assume that the QoS-model specific
control information includes directions to deal with resource
sharing. This may include, adding the reservations, or taking the
maximum of the two or more complex mathematical operations.
This resource handling mechanism in the QoS model is also applicable
to sessions with different SESSION_ID but related through the
BOUND_SESSION_ID object. Session replacement is not an issue here,
but the QoS model may specify whether to let the sessions that are
bound together share resources on common links or not.
Finally, it is possible that a RESERVE is received with no QSPEC at
all. This is the case of a summary refresh. In this case, rather
than sending a refreshing RESERVE with the full QSPEC, only the
SESSION_ID and the SII are sent to refresh the reservation. Note
that this mechanism just reduces the message size (and probably eases
processing). One RESERVE per session is still needed. The
combination of different SESSION_IDs (and SIIs) in the same
refreshing RESERVE message is currently an open issue.
4.2.5 State timers
The NSIS protocol suite takes a soft-state approach to state The NSIS protocol suite takes a soft-state approach to state
management. This means that reservation state in QNEs must be management. This means that reservation state in QNEs must be
periodically refreshed. The frequency with which state installation periodically refreshed. The frequency with which state installation
is refreshed is expressed in the REFRESH_PERIOD object. This object is refreshed is expressed in the REFRESH_PERIOD object. This object
contains a value in seconds indicating how long the state that is contains a value in seconds indicating how long the state that is
signalled for remains valid. Maintaining the reservation beyond this signalled for remains valid. Maintaining the reservation beyond this
lifetime can be done by sending a ("refreshing") RESERVE message. lifetime can be done by sending a ("refreshing") RESERVE message.
The REFRESH_PERIOD has local significance only. At the expiration of The REFRESH_PERIOD has local significance only. At the expiration of
a "refresh timeout" period, each QNE independently examines its state a "refresh timeout" period, each QNE independently examines its state
and sends a refreshing RESERVE message to the next QNE peer where it and sends a refreshing RESERVE message to the next QNE peer where it
is absorbed. This peer-to-peer refreshing (as opposed to the QNI is absorbed. This peer-to-peer refreshing (as opposed to the QNI
initiating a refresh which travels all the way to the QNR) allows initiating a refresh which travels all the way to the QNR) allows
QNEs to choose refresh intervals as appropriate for their QNEs to choose refresh intervals as appropriate for their
environment. For example, it is conceivable that refreshing intervals environment. For example, it is conceivable that refreshing
in the backbone, where reservations are relatively stable, are much intervals in the backbone, where reservations are relatively stable,
larger than in an access network. The "refresh timeout" is calculated are much larger than in an access network. The "refresh timeout" is
within the QNE and is not part of the protocol; however, it must be calculated within the QNE and is not part of the protocol; however,
chosen to be compatible with the reservation lifetime as expressed by it must be chosen to be compatible with the reservation lifetime as
the REFRESH_PERIOD, and an assessment of the reliability of message expressed by the REFRESH_PERIOD, and an assessment of the reliability
delivery. of message delivery.
The details of timer management and timer changes (slew handling and The details of timer management and timer changes (slew handling and
so on) are given in Section 5. so on) are given in Section 5.
4.2.5 Session binding 4.2.6 Session binding
Some QNEs may need to have knowledge of session binding. With session Session binding is defined as the enforcement of a relation between
binding we mean that a relation exists between signalled sessions different QoS NSLP sessions (i.e. signalling flows with different
with potentially different SESSION_IDs and/or flow IDs. The SESSION_ID (SID) as defined in [3]).
SESSION_ID is defined in [4] This situation can occur in case of
layering or aggregation where multiple reservations are aggregated
together (and the flow ID changes) or when some local properties
(e.g. connection mode) for the session change.
Layering or aggregation may cause loss of information. If the edge A relation between two sessions is indicated by including the
QNEs of the aggregation domain want to maintain some end-to-end BOUND_SESSION_ID object in the messages. A session with SID_A (the
properties, they may establish a peering relation by sending the binding session) can express its relation to another session with
end-to-end message transparantly over the domain. Updating the SID_B (the bound session) by including a BOUND_SESSION_ID object
end-to-end properties in this message may require some knowledge of containing SID_B in its messages. Note that the session with SID_B
the aggregated session (e.g. for updating delay values). For this may or may not carry a BOUND_SESSION_ID object containing SID_A.
purpose, a session (e.g., end to end session), may contain a
BOUND_SESSION_ID (the SESSION_ID of another session (e.g., the
aggregate one) in addition to its own SESSION_ID to indicate session
binding. This BOUND_SESSION_ID is called the session binding object.
4.3 Layering Three examples where session binding can be used for aggregate
reservation, bi-directional reservation and fate sharing are
described below.
The QoS NSLP supports layered reservations. Layered reservations may Aggregated sessions may have a different flow ID from the end-to-end
message. If the edge QNEs of the aggregation domain want to maintain
some end-to-end properties, they may establish a peering relation by
sending the end-to-end message transparantly over the domain.
Updating the end-to-end properties in this message may require some
knowledge of the aggregated session (e.g. for updating delay
values). For this purpose, the end-to-end session contains a
BOUND_SESSION_ID carrying the SESSION_ID of the aggregate session.
Including the BOUND_SESSION_ID object in a session indicates a
dependency relation. By default, a session that is bound to another
session with the BOUND_SESSION_ID object shares fate with it. This
means that if a bound session is torn down, every binding session
should be torn down as well. The reverse is not true. If a binding
session is torn down, the bound session and other binding sessions
remain. A QNE that wants to prevent fate sharing sets a flag in the
common header (NO_FATE_SHARING).
Bi-directional reservations are a special case of fate sharing. In
this case, a reservation in one direction only makes sense if the
reservation in the reverse direction is also up. In some cases
bi-directional reservations also allow local optimizations.
Therefore, when a reverse reservation is set up, it should carry a
BOUND_SESSION_ID containing the SESSION_ID of the forward direction.
This SESSION_ID is copied from the sender-initiated (forward) RESERVE
or from the QUERY message triggering the sender-initiated (reverse)
RESERVE message. Alternatively, it can be inserted by the QNE that
sets up both the sender-initiated RESERVE and the receiver-initiated
RESERVE.
4.3 Layering
The QoS NSLP supports layered reservations. Layered reservations may
occur when certain parts of the network (domains) implement one or occur when certain parts of the network (domains) implement one or
more local QoS models, or when they locally apply specific control more local QoS models, or when they locally apply specific control
plane characteristics (e.g. datagram mode instead of connection plane characteristics (e.g. datagram mode instead of connection
mode). They may also occur when several per-flow reservations are mode). They may also occur when several per-flow reservations are
locally combined into an aggregate reservation. locally combined into an aggregate reservation.
4.3.1 Local QoS models 4.3.1 Local QoS models
Parameters of the QoS model that is being signalled for are carried Parameters of the QoS model that is being signalled for are carried
in the QSPEC object. A domain may have local policies regarding QoS in the QSPEC object. A domain may have local policies regarding QoS
model implementation, i.e. it may map incoming traffic to its own model implementation, i.e. it may map incoming traffic to its own
locally defined QoS models. The QoS NSLP supports this by allowing locally defined QoS models. The QoS NSLP supports this by allowing
QSPEC objects to be stacked. QSPEC objects to be stacked.
When a domain wants to apply a certain QoS model to an incoming When a domain wants to apply a certain QoS model to an incoming
per-flow reservation request, each edge of the domain is configured per-flow reservation request, each edge of the domain is configured
to map the incoming QSPEC object to a local QSPEC object and push to map the incoming QSPEC object to a local QSPEC object and push
that object onto the stack of QSPEC objects (typically immediately that object onto the stack of QSPEC objects (typically immediately
following the Common Control Information, i.e. the first QSPEC that following the Common Control Information, i.e. the first QSPEC that
is found in the message). QNEs inside the domain look at the top of is found in the message). QNEs inside the domain look at the top of
the QSPEC object stack to determine which QoS model to apply for the the QSPEC object stack to determine which QoS model to apply for the
reservation. reservation.
The position of the local QSPEC object in the stack implies a The position of the local QSPEC object in the stack implies a
tradeoff between the speed with which incoming messages can be tradeoff between the speed with which incoming messages can be
processed and the time it takes to construct the outgoing message (if processed and the time it takes to construct the outgoing message (if
any). By mandating the locally valid object to be on top of the stack any). By mandating the locally valid object to be on top of the
we value ease of processing over ease of message construction. stack we value ease of processing over ease of message construction.
A QNE that knows it is the last QNE to understand a local QSPEC A QNE that knows it is the last QNE to understand a local QSPEC
object (e.g. by configuration of the egress QNEs of a domain) SHOULD object (e.g. by configuration of the egress QNEs of a domain) SHOULD
remove the topmost QSPEC object from the stack. It SHOULD update the remove the topmost QSPEC object from the stack. It SHOULD update the
underlying QoS model parameters if needed. underlying QoS model parameters if needed.
A QNE that receives a message with a QSPEC object stack of which the A QNE that receives a message with a QSPEC object stack of which the
topmost object is not understood SHOULD send an error indication to topmost object is not understood MUST NOT forward the message and
its upstream neighbour. It is currently an open issue whether this MUST send an error indication to its upstream neighbour. It MUST NOT
QNE MAY search the stack for a QSPEC object it understands to recover attempt local recovery by inspecting the stack for a QSPEC object it
from this situation. It is also an open issue if such a message can understands.
be forwarded and if and how the QSPEC object stack should be updated.
4.3.2 Local control plane properties 4.3.2 Local control plane properties
The way signalling messages are handled is mainly determined by the The way signalling messages are handled is mainly determined by the
parameters that are sent over the NTLP-NSLP API and by the Common parameters that are sent over GIMPS-NSLP API and by the Common
Control Information. A domain may have a policy to implement local Control Information. A domain may have a policy to implement local
control plane behaviour. It may, for instance, elect to use datagram control plane behaviour. It may, for instance, elect to use an
mode locally in the domain while still keeping e2e reliability unreliable transport locally in the domain while still keeping
intact. end-to-end reliability intact.
The QoS NSLP supports this situation by allowing two sessions to be The QoS NSLP supports this situation by allowing two sessions to be
set up for the same reservation. The local session has the desired set up for the same reservation. The local session has the desired
local control plane properties and is interpreted in internal QNEs. local control plane properties and is interpreted in internal QNEs.
This solution poses two requirements: the end-to-end session must be This solution poses two requirements: the end-to-end session must be
able to bypass intermediate nodes and the egress QNE needs to bind able to bypass intermediate nodes and the egress QNE needs to bind
both sessions together. both sessions together.
The local session and the end-to-end session are bound at the egress The local session and the end-to-end session are bound at the egress
QNE by means of the BOUND_SESSION_ID object. One approach could be QNE by means of the BOUND_SESSION_ID object. One approach could be
that the end-to-end session carries the SESSION_ID of the local that the end-to-end session carries the SESSION_ID of the local
session in its session binding object. Another approach could be that session in its session binding object. Another approach could be
the local session carries the SESSION_ID of the end-to-end session in that the local session carries the SESSION_ID of the end-to-end
its BOUND_SESSION_ID object. This allows the QNE that performs session in its BOUND_SESSION_ID object. This allows the QNE that
session binding to maintain end-to-end connection mode. performs session binding to maintain end-to-end connection mode.
4.3.3 Aggregate reservations 4.3.3 Aggregate reservations
For scalability reasons, a domain MAY want to combine two or more For scalability reasons, a domain may want to combine two or more
end-to-end reservations into a single local aggregate reservation. end-to-end reservations into a single local aggregate reservation.
The domain over which the aggregation is done is limited by The domain over which the aggregation is done is limited by
configuration. configuration.
The essential difference with the layering approaches described in The essential difference with the layering approaches described in
Section 4.3.1 and Section 4.3.2 is that the aggregate reservation Section 4.3.1 and Section 4.3.2 is that the aggregate reservation
needs a FlowID that describes all traffic carried in the aggregate needs a FlowID that describes all traffic carried in the aggregate
(e.g. a DSCP in case of IntServ over DiffServ). (e.g. a DSCP in case of IntServ over DiffServ).
The need for a different FlowID mandates the use of two different The need for a different FlowID mandates the use of two different
sessions, similar to Section 4.3.2 and to the RSVP aggregation sessions, similar to Section 4.3.2 and to the RSVP aggregation
solution (reference to 3175). In addition to the different FlowID, solution [10]. In addition to the different FlowID, the aggregate
the aggregate session may specify a local QoS model and local control session may specify a local QoS model and local control plane
plane parameters as explained above. parameters as explained above.
The aggregate reservation may or may not change source and The aggregate reservation may or may not change source and
destination IP addresses, i.e. either the end-to-end adresses may be destination IP addresses, i.e. either the end-to-end adresses may be
used (if possible) or the IP address of ingress and egress of the used (if possible) or the IP address of ingress and egress of the
domain may be used as source and destination IP address. In some domain may be used as source and destination IP address. In some
cases, the latter option may cause data plane divergence between both cases, the latter option may cause data plane divergence between both
sessions. RSVP solves this by using tunnelling between the edges of sessions. RSVP solves this by using tunnelling between the edges of
the domain. the domain.
In any case, session binding and a solution for intermediate node In any case, session binding and a solution for intermediate node
bypass (as explained before) are required in this case as well. bypass (as explained before) are required in this case as well.
4.4 Extensibility 4.4 Extensibility
The QoS NSLP specification foresees future specification of new error The QoS NSLP specification foresees future specification of new error
codes and new Common Control Information objects. Specification of codes and new Common Control Information objects. Specification of
new messages is not foreseen but not explicitly precluded. new messages is not foreseen but not explicitly precluded.
Specification of new error codes and Common Control Information Specification of new error codes and Common Control Information
objects is subject to IANA approval and assignment of ClassNum and objects is subject to IANA approval and assignment of ClassNum and
CType. ClassNum and CType of currently existing objects and error CType. ClassNum and CType of currently existing objects and error
codes are described in Section 6. New Common Control Information codes are described in Section 6. New Common Control Information
objects need to specify whether they are mandatory or optional to objects need to specify whether they are mandatory or optional to
implement. Mandatory CCI that is not understood by a QNE needs to implement. Mandatory CCI that is not understood by a QNE needs to
generate an error. Optional CCI that is not understood by a QNE needs generate an error. Optional CCI that is not understood by a QNE
to be passed transparantly. needs to be passed transparantly.
The QoS NSLP specification allows future QoS model specific The QoS NSLP specification allows future QoS model specific
extensions, including the definition of new QoS models, the extensions, including the definition of new QoS models, the
specification of new objects for existing QoS models, the specification of new objects for existing QoS models, the
specification of new processing rules for new or existing objects and specification of new processing rules for new or existing objects and
the specification of new QoS model specific error codes. the specification of new QoS model specific error codes.
Different types of QoS models are foreseen: standardized QoS models, Different types of QoS models are foreseen: standardized QoS models,
well-known QoS models and QoS models for private use. We assume the well-known QoS models and QoS models for private use. We assume the
IANA registry of QoS models to distinguish between those. Apart from IANA registry of QoS models to distinguish between those. Apart from
the QoS model ID, all QoS model specific extensions are opaque to the the QoS model ID, all QoS model specific extensions are opaque to the
QoS NSLP (and have no impact on its IANA considerations section). QoS NSLP (and have no impact on its IANA considerations section).
4.5 Priority 4.5 Priority
This specification acknowledges the fact that in some situations, This specification acknowledges the fact that in some situations,
some messages or some reservations may be more important than others some messages or some reservations may be more important than others
and therefore foresees mechanisms to give these messages or and therefore foresees mechanisms to give these messages or
reservations priority. reservations priority.
Priority of certain signalling messages over others may be required Priority of certain signalling messages over others may be required
in mobile scenarios when a message loss during call set-up is less in mobile scenarios when a message loss during call set-up is less
harmful then during handover. This situation only occurs when the harmful then during handover. This situation only occurs when GIMPS
GIMPS or QoS NSLP processing is the congested part or scarce or QoS NSLP processing is the congested part or scarce resource.
resource. This specification requests the NTLP design to foresee a This specification requests GIMPS design to foresee a mechanism to
mechanism to support a number of levels of message priority that can support a number of levels of message priority that can be requested
be requested over the NSLP-NTLP API. over the NSLP-GIMPS API.
Priority of certain reservations over others may be required when QoS Priority of certain reservations over others may be required when QoS
resources are oversubscribed. In that case, existing reservations may resources are oversubscribed. In that case, existing reservations
be preempted in other to make room for new higher-priority may be preempted in other to make room for new higher-priority
reservations. A typical approach to deal with priority and preemption reservations. A typical approach to deal with priority and
is through the specification of a setup priority and holding priority preemption is through the specification of a setup priority and
for each reservation. The resource management function at each QNE holding priority for each reservation. The resource management
then keeps track of the resource consumption at each priority level. function at each QNE then keeps track of the resource consumption at
Reservations are established when resource at their setup priority each priority level. Reservations are established when resource at
level are still available. They may cause preemption of reservations their setup priority level are still available. They may cause
with a lower holding priority than their setup priority. preemption of reservations with a lower holding priority than their
setup priority.
Support of reservation priority is a QoS model specific issue and Support of reservation priority is a QoS model specific issue and
therefore outside the scope of this specification. However, the therefore outside the scope of this specification. However, the
concepts of setup and holding priority are widely accepted and we concepts of setup and holding priority are widely accepted and we
expect the specification of a Priority object in the QSPEC template expect the specification of a Priority object in the QSPEC template
to be useful for a wide range of QoS models. to be useful for a wide range of QoS models.
4.6 Rerouting 4.6 Rerouting
The QoS NSLP needs to adapt to route changes in the data path. This The QoS NSLP needs to adapt to route changes in the data path. This
assumes the capability to detect rerouting events, perform QoS assumes the capability to detect rerouting events, perform QoS
reservation on the new path and optionally tear down reservations on reservation on the new path and optionally tear down reservations on
the old path. the old path.
Rerouting detection can be performed at three levels. First, routing Rerouting detection can be performed at three levels. First, routing
modules may detect route changes through their interaction with modules may detect route changes through their interaction with
routing protocols. Certain QNEs or NTLP implementations may interact routing protocols. Certain QNEs or GIMPS implementations may
with local routing module to receive quick notification of route interact with local routing module to receive quick notification of
changes. This is largely implementation-specific and outside of the route changes. This is largely implementation-specific and outside
scope of NSIS. Second, route changes may be detected at the NTLP of the scope of NSIS. Second, route changes may be detected at GIMPS
layer. This specification requests the NTLP design to foresee layer. This specification requests GIMPS design to foresee
notification of this information over the API. This is outside the notification of this information over the API. This is outside the
scope of the QoS NSLP specification. Third, rerouting may be detected scope of the QoS NSLP specification. Third, rerouting may be
at the NSLP layer. A QoS NSLP node is able to detect changes in its detected at the NSLP layer. A QoS NSLP node is able to detect
QoS NSLP peers by keeping track of a Source Identification changes in its QoS NSLP peers by keeping track of a Source
Information (SII) object that is similar in nature to the RSVP_HOP Identification Information (SII) object that is similar in nature to
object described in [6]. When a RESERVE message with an existing the RSVP_HOP object described in [5]. When a RESERVE message with an
SESSION_ID and a different SII is received, the QNE knows its existing SESSION_ID and a different SII is received, the QNE knows
upstream peer has changed. its upstream peer has changed.
Reservation on the new path automatically happens when a refreshing Reservation on the new path automatically happens when a refreshing
RESERVE message arrives at the QNE where the old and the new path RESERVE message arrives at the QNE where the old and the new path
diverge. Rapid recovery at the NSLP layer therefore requires short diverge. Rapid recovery at the NSLP layer therefore requires short
refresh periods. Detection before the next RESERVE message arrives is refresh periods. Detection before the next RESERVE message arrives
only possible at the IP layer or through monitoring of the NTLP is only possible at the IP layer or through monitoring of GIMPS
peering relations (e.g. by TTL counting the number of NTLP hops peering relations (e.g. by TTL counting the number of GIMPS hops
between NSLP peers or the observing changes in the outgoing interface between NSLP peers or the observing changes in the outgoing interface
towards the NTLP peer). These mechanisms are outside the scope of towards GIMPS peer). These mechanisms are outside the scope of this
this specification. specification.
When the QoS NSLP is aware of the route change, it needs to set up When the QoS NSLP is aware of the route change, it needs to set up
the reservation on the new path. This is done by sending a RESERVE the reservation on the new path. This is done by sending a RESERVE
message with RSN+2. On links that are common to the old and the new message with RSN+1. On links that are common to the old and the new
path, this RESERVE message is interpreted as a refreshing RESERVE. On path, this RESERVE message is interpreted as a refreshing RESERVE.
new links, it creates the reservation. On new links, it creates the reservation.
After the reservation on the new path is set up, the branching node After the reservation on the new path is set up, the branching node
or the merging node may want to tear down the reservation on the old or the merging node may want to tear down the reservation on the old
path (faster than what would result from normal soft-state time-out). path (faster than what would result from normal soft-state time-out).
This functionality is supported by keeping track of the old SII. This This functionality is supported by keeping track of the old SII.
specification requests the NTLP design to provide support for an SII This specification requests GIMPS design to provide support for an
that is interpreted as a random identifier at the QoS NSLP but that SII that is interpreted as a random identifier at the QoS NSLP but
allows, when passed over the API, to forward QoS NSLP messages to the that allows, when passed over the API, to forward QoS NSLP messages
QNE identified by that SII. Then, a RESERVE message with the TEAR to the QNE identified by that SII.
flag set (tearing RESERVE) and RSN+1 can be sent over the old branch
of the path. Setting the RSN+1 ensures that the reservation will not
be torn down if the neighbouring QNE has not, in fact, changed.
4.7 State storage A QNE that has detected the route change via the SII change sends a
RESERVE with the TEAR flag set. A QNE that is notified of the route
change in another way and want to tear down the old branch needs to
send the RESERVE on the new path with a RESPONSE_REQUEST. When it
receives the RESPONSE message back, it can check whether its peer has
effectively changed and send a RESERVE with the TEAR flag set if it
has. Otherwise, teardown is not needed. A QNE that is unable to
perform RESPONSE_REQUEST or does not receive a RESPONSE needs to rely
on sof-state timeout on the old branch.
For each flow, the QoS NSLP stores QoS reservation state. This state A QNI or a branch node may wish to keep the reservation on the old
includes QoS model specific state which is different for each QoS branch. This could for instance be the case when a mobile node has
model and QoS NSLP operation state which includes non-persistent experienced a mobility event and wishes to keep reservation to its
state (e.g. the API parameters while a QNE is processing a message) old attachment point in case it moves back there. In that case, it
and persistent state which is kept as long as the session is active. sets the NO_REPLACE flag in the common header.
4.7 State storage
For each flow, a QNE stores (QoS model specific) reservation state
which is different for each QoS model and QoS NSLP operation state
which includes non-persistent state (e.g. the API parameters while a
QNE is processing a message) and persistent state which is kept as
long as the session is active.
The persistent QoS NSLP state is conceptually organised in a table The persistent QoS NSLP state is conceptually organised in a table
with the following structure. The primary key (index) for the table with the following structure. The primary key (index) for the table
is the Session ID: is the Session ID:
SESSION_ID SESSION_ID
A large identifier provided by the NTLP. A large identifier provided by GIMPS or set locally.
The state information for a given key includes: The state information for a given key includes:
Flow ID Flow ID
Copied from the NTLP. Several entries are possible in case of Copied from GIMPS. Several entries are possible in case of
mobility events. mobility events.
QoS model ID QoS model ID
8 bit identification of the QoS model. 8 bit identification of the QoS model.
SII for each upstream and downstream peer SII for each upstream and downstream peer
The SII is a 128 bit identifier generated by the NTLP and passed The SII is a large identifier (minimum 128 bits) generated by the
over the API. GIMPS and passed over the API.
RSN from each upstream peer RSN from each upstream peer
The RSN is a 32 bit counter. The RSN is a 32 bit counter.
Current own RSN Current own RSN
A 32 bit random number. A 32 bit random number.
List of RII for outstanding responses with processing information List of RII for outstanding responses with processing information
the RII is a 32 bit number. the RII is a 32 bit number.
State lifetime State lifetime
The state lifetime indicates how long the state that is being
signalled for remains valid.
BOUND_SESSION_ID BOUND_SESSION_ID
The BOUND_SESSION_ID is a 128 bit random number. The BOUND_SESSION_ID is a 128 bit random number.
Adding the state requirements of all these items gives an upper bound Adding the state requirements of all these items gives an upper bound
on the state to be kept by a QNE. The need to keep state depends on on the state to be kept by a QNE. The need to keep state depends on
the desired functionality at the NSLP layer. the desired functionality at the NSLP layer.
4.8 Authentication and authorization 4.8 Authentication and authorization
QoS NSLP requests allow particular user(s) to obtain preferential QoS NSLP requests allow particular user(s) to obtain preferential
access to network resources. To prevent abuse, some form of an access access to network resources. To prevent abuse, some form of an
control (or also known as policy based admission control) will access control (also known as policy based admission control) will
generally be required on users who make reservations. Typically, such generally be required on users who make reservations. Typically,
authorization is expected to make use of an AAA service external to such authorization is expected to make use of an AAA service external
the node itself. In any case, cryptographic user identification and to the node itself. In any case, cryptographic user identification
selective admission will generally be needed when a reservation is and selective admission will generally be needed when a reservation
requested. is requested.
The QoS NSLP request is handled by a local 'resource management' The QoS NSLP request is handled by a local 'resource management'
function, which coordinates the activities required to grant and function, which coordinates the activities required to grant and
configure the resource. The grant processing involves two local configure the resource. The grant processing involves two local
decision modules, 'policy control' and 'admission control'. Policy decision modules, 'policy control' and 'admission control'. Policy
control determines whether the user is sufficiently authorized to control determines whether the user is sufficiently authorized to
make the reservation. Admission control determines whether the node make the reservation. Admission control determines whether the node
has sufficient available resources to offer the requested QoS. has sufficient available resources to offer the requested QoS.
4.8.1 Policy Ignorant Nodes 4.8.1 Policy Ignorant Nodes
It is generally assumed that policy enforcement is likely to It is generally assumed that policy enforcement is likely to
concentrate on border nodes between autonomous systems. Figure 9 concentrate on border nodes between administrative domains. Figure
below illustrates a simple autonomous domain with: 15 below illustrates a simple administrative domain with:
o two boundary nodes (A, C), which represent QNEs authorized by AAA o two boundary nodes (A, C), which represent QNEs authorized by AAA
entities. entities.
o A core node (B) represents an Policy Ignorant QN (PIN) with o A core node (B) represents an Policy Ignorant QNE (PIN) with
capabilities limited to default admission control handling. capabilities limited to default admission control handling.
Authorizing Entity 1 Authorizing Entity 2 Authorizing Entity 1 Authorizing Entity 2
| | | |
| | | |
+---+ +---+ +---+ +---+ +---+ +---+
| A +---------+ B +---------+ C | | A +---------+ B +---------+ C |
+---+ +---+ +---+ +---+ +---+ +---+
QN1 PIN QN2 QNE1 PIN QNE2
Figure 9: Autonomous Domain scenario Figure 15: Administrative Domain scenario
Here, policy objects transmitted across the domain traverse an Here, policy objects transmitted across the domain traverse an
intermediate PIN node (B) that is allowed to process QoS NSLP message intermediate PIN node (B) that is allowed to process QoS NSLP message
but considered non-trusted for handling policy information. but considered non-trusted for handling policy information.
4.8.2 Policy Data 4.8.2 Policy Data
The input to policy control is referred to as "Policy data", which The input to policy control is referred to as "Policy data", which
QoS NSLP carries in the Policy object. Policy data may include QoS NSLP carries in the Policy object. Policy data may include
credentials identifying entities and traits depending on the credentials identifying entities and traits depending on the
authorization model in use (2-party, 3-party, token-based 3-party). authorization model in use (2-party, 3-party, token-based 3-party).
There are no requirements for all nodes to process this object. There are no requirements for all nodes to process this object.
Policy data itself is opaque to NSIS, which simply passes it to Policy data itself is opaque to the QoS NSLP, which simply passes it
policy control when required. The policy data is independent from the to policy control when required. The policy data is independent from
QoS model in use. the QoS model in use.
Policy control depends on successful user authentication and Policy control depends on successful user authentication and
authorization of a QoS NSLP reservation request. The authorization authorization of a QoS NSLP reservation request. The authorization
decision might be valid for a certain amount of time or even for the decision might be valid for a certain amount of time or even for the
entire lifetime of the session. It is a decision of the involved entire lifetime of the session. It is a decision of the involved
party to trigger a re-authorization procedure. This feature is party to trigger a re-authorization procedure. This feature is
supported by the Policy Refresh Timer (PRT) option of the Policy supported by the Policy Refresh Timer (PRT) option of the Policy
object. object.
Policy objects are carried by QoS NSLP messages and contain policy Policy objects are carried by QoS NSLP messages and contain policy
information. All policy-capable nodes (at any location in the information. All policy-capable nodes (at any location in the
network) can generate, modify, or remove policy objects, even when network) can generate, modify, or remove policy objects, even when
senders or receivers do not provide, and may not even be aware of senders or receivers do not provide, and may not even be aware of
policy data objects. policy data objects.
The exchange of Policy objects between policy-capable QNEs along the The exchange of Policy objects between policy-capable QNEs along the
data path, supports the generation of consistent end-to-end policies. data path, supports the generation of consistent end-to-end policies.
Furthermore, such policies can be successfully deployed across Furthermore, such policies can be successfully deployed across
multiple administrative domains when border nodes manipulate and multiple administrative domains when border nodes manipulate and
translate Policy objects according to established sets of bilateral translate Policy objects according to established sets of bilateral
agreements. agreements.
5. QoS-NSLP Functional specification 5. QoS-NSLP Functional specification
5.1 QoS-NSLP Message Formats 5.1 QoS-NSLP Message and Object Formats
An QoS-NSLP message consists of a common header, followed by a body A QoS-NSLP message consists of a common header, followed by a body
consisting of a variable number of variable-length, typed "objects". consisting of a variable number of variable-length, typed "objects".
The following subsections define the formats of the common header, The following subsections define the formats of the common header,
the standard object header, and each of the QoS-NSLP message types. the standard object header, and each of the QoS-NSLP message types.
For each QoS-NSLP message type, there is a set of rules for the For each QoS-NSLP message type, there is a set of rules for the
permissible choice of object types. These rules are specified using permissible choice of object types. These rules are specified using
Backus-Naur Form (BNF) augmented (see [2]). with square brackets the Augmented Backus-Naur Form (BNF) specified in [2]. The BNF
surrounding optional sub-sequences. The BNF implies an order for the implies an order for the objects in a message. However, in many (but
objects in a message. However, in many (but not all) cases, object not all) cases, object order makes no logical difference. An
order makes no logical difference. An implementation should create implementation should create messages with the objects in the order
messages with the objects in the order shown here, but accept the shown here, but accept the objects in any permissible order.
objects in any permissible order.
5.1.1 Common header 5.1.1 Common header
0 1 0 1 2 3
+---------------------------+---------------------------+ +-------------+-------------+-------------+-------------+
| Msg Type | Flags | | Message Type | Flags |
+---------------------------+---------------------------+ +-------------+-------------+-------------+-------------+
The fields in the common header are as follows: The fields in the common header are as follows:
Msg Type: 8 bits Msg Type: 16 bits
1 = RESERVE 1 = RESERVE
2 = QUERY 2 = QUERY
3 = RESPONSE 3 = RESPONSE
4 = NOTIFY 4 = NOTIFY
Flags: 16 bits
The set of appropriate flags depend on the particular message
being processed. Any bit not defined as a flag for a
particular message MUST be set to zero on sending and MUST
ignored on receiving.
Flags: 8 bits 5.1.2 Object Formats
1 = TEAR flag
2 = BIDIRECTIONAL flag
Other flags have to be defined.
5.1.2 Object Formats
Every object consists of one or more 32-bit words with a one-word Every object consists of one or more 32-bit words with a one-word
header, with the following format: header, with the following format:
0 1 2 3 0 1 2 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length (bytes) | Class-Num | C-Type | | Length (bytes) | Class-Num | C-Type |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
// (Object contents) // // (Object contents) //
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
An object header has the following fields: An object header has the following fields:
Length: Length:
A 16-bit field containing the total object length in bytes.
A 16-bit field containing the total object length in bytes. Must Must always be a multiple of 4, and at least 4.
always be a multiple of 4, and at least 4. Class-Num:
Identifies the object class; values of this field are defined
Class-Num: in Appendix A. Each object class has a name, which is always
capitalized in this document. An QoS-NSLP implementation must
Identifies the object class; values of this field are defined in recognize the following classes:
Appendix A. Each object class has a name, which is always RESPONSE_REQUEST:
capitalized in this document. An QoS-NSLP implementation must Contains the request for the generation of a response
recognize the following classes: message and the Request Identification Information (RII).
RSN:
RESPONSE_REQUEST: The Reservation Sequence Number (RSN) contains an
incrementing sequence number that indicates the order in
Contains the request for the generation of a response message which state modifying actions are performed by a QNE.
and the Request Identification Information (RII). The RSN has local significance only, i.e. between a pair
of neighbouring stateful QNEs. RSN is a common control
RSN: information object.
REFRESH_PERIOD:
Contains the value for the refresh period R used by the
creator of the message. Required in every RESERVE
message. REFRESH_PERIOD is a common control information
object.
BOUND_SESSION_ID:
It represents the Session ID as specified in [15] of the
session that must be bound to the session associated to
the message carrying this object.
SCOPING:
contains information that limits the scope of the message
carrying this object. When no SCOPING object is
available in a message it means that its scoping is
either the whole path or it is defined by configuration.
SCOPING is a common control information object.
ERROR_SPEC:
Contains an error code and can be carried by a Response
or a NOTIFY message. ERROR_SPEC is a common control
information object.
The Reservation Sequence Number (RSN) contains an incrementing POLICY_DATA:
sequence number that indicates the order in which state Carries authentication, authorization and accounting
modifying actions are performed by a QNE. The RSN has local information.
significance only, i.e. between a pair of neighbouring stateful QSPEC:
QNEs. RSN is a common control information object. Carries the information that is QoS model specific. This
information consists of the QoS model specific control
information and the QoS specification parameters.
C-Type:
Object type, unique within Class-Num. Values are defined in
Appendix A.
REFRESH_PERIOD The maximum object content length is 65528 bytes. The Class-Num and
C-Type fields may be used together as a 16-bit number to define a
unique type for each object.
Contains the value for the refresh period R used by the creator The high-order two bits of the Class-Num are used to determine what
of the message. Required in every RESERVE message. action a node should take if it does not recognize the Class-Num of
REFRESH_PERIOD is a common control information object. an object. The first two bits of the Class-Num take one of the
following three values:
00 - Abort processing and send error back
01 - Ignore object, and do not forward it in onward message
10 - Ignore object, but forward it in onward message
SESSION_ID 5.2 General Processing Rules
It represents the SESSION_ID as specified in [3] of the session 5.2.1 State Manipulation
that must be bound to the session associated to the message
carrying this object.
SCOPING The processing of a message and its component objects involves
manipulating the QoS NSLP and reservation state of a QNE.
contains information that limits the scope of the message The state used by the QoS NSLP is listed in Section 4.7.
carrying this object. When no SCOPING object is available in a
message it means that its scoping is either the whole path or
it is defined by configuration. SCOPING is a common control
information object.
ERROR_SPEC 5.2.2 Message Forwarding
Contains an error code and can be carried by a Response or a QoS NSLP messages are sent peer-to-peer along the path. The QoS NSLP
NOTIFY message. ERROR_SPEC is a common control information does not have the concept of a message being sent along the entire
object. path. Instead, messages are received by a QNE, which may then send
another message (which may be identical to the received message, or
contain some subset of objects from it) to continue in the same
direction (i.e. towards NI or NR) as the message received.
POLICY_DATA The decision on whether to generate a message to forward may be
affected by the presence of a SCOPING object.
Carries authentication, authorization and accounting 5.2.3 Standard Message Processing Rules
information.
QSPEC If a mandatory object is missing from a message then the receiving
QNE MUST NOT propagate the message any further. It MUST construct an
RESPONSE message indicating the error condition and send it back to
the peer QNE that sent the message.
Carries the information that is QoS model specific. This If a message contains an object of an unrecognised type, then the
information consists of the QoS model specific control behaviour depends on the first two bits in the type value.
information and the QoS specification parameters.
C-Type: 5.3 Object Processing
Object type, unique within Class-Num. Values are defined in 5.3.1 Reservation Sequence Number
Appendix A.
The maximum object content length is 65528 bytes. The Class- Num and A QNE's own RSN is a sequence number which applies to a particular
C-Type fields may be used together as a 16-bit number to define a NSIS signalling session (i.e. with a particular GIMPS Session ID).
unique type for each object. It MUST be incremented for each new RESERVE message where the
reservation for the session changes. Once the RSN has reached its
maximum value, the next value it takes is zero.
The high-order two bits of the Class-Num are used to determine what When receiving a RESERVE message a QNE uses the RSN given in the
action a node should take if it does not recognize the Class-Num of message to determine whether the state being requested is different
an object; to that already stored. If the RSN is the same as for the current
reservation the current state MUST be refreshed. If the RSN is
greater than the current stored value, the current reservation MUST
be modified appropriately (provided that admission control and policy
control succeed), and the stored RSN value updated to that for the
new reservation. If the RSN is less than the current value, then it
indicates an out-of-order message and the RESERVE message MUST be
discarded.
5.1.3 RESERVE Messages If the QNE does not store per-session state (and so not keep any
previous RSN values) then it MAY ignore the value of the RSN. It
MUST also copy the same RSN into the RESERVE message (if any) it
sends as a consequence of receiving this one.
The RESERVE message is used to manipulate QoS reservation state in 5.3.2 Response Request
QNEs. A RESERVE message may create, refresh, modify or remove such
state.
The format of a RESERVE message is as follows: A QNE sending some types of message may require a response to be
sent. It does so by including a RESPONSE_REQUEST object.
RESERVE = COMMON_HEADER When creating a RESPONSE_REQUEST object the sender MUST select the
value for the RII such that it is probabilistically unique within the
given session.
RSN [ SCOPING ] [ RESPONSE_REQUEST ] A number of choices are available when implementing this.
Possibilities might include using a totally random value, or a node
identifier together with a counter. If the value is selected by
another QNE then RESPONSE messages may be incorrectly terminated, and
not passed back to the node that requested them.
REFRESH_PERIOD [ BOUND_SESSION_ID ] When sending a RESPONSE_REQUEST the sending node MUST remember the
value used in the RII to match back any RESPONSE received. It SHOULD
use a timer to identify situations where it has taken too long to
receive the expected RESPONSE. If the timer expires without
receiving a RESPONSE it MAY perform a retransmission.
POLICY_DATA QSPEC [ *QSpec ] When receiving a message containing a RESPONSE_REQUEST object the
node MUST send a RESPONSE if either
o The message contained a SCOPING object with a value of 'next hop',
or
o This QNE is the last one on the path for the given session.
and the QNE keeps per-session state for the given session.
The QSPEC object(s) must occur at the end of the message. There are 5.3.3 Bound Session ID
no other requirements on transmission order, although the above order
is recommended.
The SESSION_ID object must be included in the RESERVE message only if As shown in the examples in Section 3.5, the QoS NSLP can relate
the session associated to this message has to be bound to another multiple sessions together. It does this by including the Session ID
session. The content of the SESSION_ID object represents the from one session in a BOUND_SESSION_ID object in messages in another
SESSION_ID of the session that must be bound to the session session.
associated to the RESERVE message carrying this object. The binding
of these two sessions is only possible in stateful QNEs.
The RESERVE message opaquely must transport a QSPEC object, 5.3.4 Refresh Period
describing the desired service level and a POLICY_DATA object,
authorizing the requestor of the service. Based on configured local
policy, a node may ignore the content of the POLICY_DATA object.
Refresh timer management values are carried by the TIMER_VALUES Refresh timer management values are carried by the REFRESH_PERIOD
object. The details of timer management and timer changes (slew object. The details of timer management and timer changes (slew
handling and so on) are identical to the ones specified in Section handling and so on) are identical to the ones specified in Section
3.7 of [6]. There are two time parameters relevant to each QoS-NSLP 3.7 of [5]. There are two time parameters relevant to each QoS-NSLP
state in a node: the refresh period R between generation of state in a node: the refresh period R between generation of
successive refreshes for the state by the neighbor node, and the successive refreshes for the state by the neighbor node, and the
local state's lifetime L. Each RESERVE message may contain a local state's lifetime L. Each RESERVE message may contain a
REFRESH_PERIOD object specifying the R value that was used to REFRESH_PERIOD object specifying the R value that was used to
generate this (refresh) message. This R value is then used to generate this (refresh) message. This R value is then used to
determine the value for L when the state is received and stored. The determine the value for L when the state is received and stored. The
values for R and L may vary from peer to peer. This peer-to-peer values for R and L may vary from peer to peer. This peer-to-peer
refreshing (as opposed to the QNI initiating a refresh which travels refreshing (as opposed to the QNI initiating a refresh which travels
all the way to the QNR) allows QNEs to choose refresh intervals as all the way to the QNR) allows QNEs to choose refresh intervals as
appropriate for their environment. For example, it is conceivable appropriate for their environment. For example, it is conceivable
that refreshing intervals in the backbone, where reservations are that refreshing intervals in the backbone, where reservations are
relatively stable, are much larger than in an access network. relatively stable, are much larger than in an access network.
In more detail: In more detail:
1. Floyd and Jacobson [25] have shown that periodic messages 1. Floyd and Jacobson [26] have shown that periodic messages
generated by independent network nodes can become synchronized. generated by independent network nodes can become synchronized.
This can lead to disruption in network services as the periodic This can lead to disruption in network services as the periodic
messages contend with other network traffic for link and messages contend with other network traffic for link and
forwarding resources. Since QoS-NSLP sends periodic refresh forwarding resources. Since QoS-NSLP sends periodic refresh
messages, it must avoid message synchronization and ensure that messages, it must avoid message synchronization and ensure that
any synchronization that may occur is not stable. any synchronization that may occur is not stable. For this
For this reason, it is recommended that the the refresh timer reason, it is recommended that the the refresh timer should be
should be randomly set to a value in the range [0.5R, 1.5R]. randomly set to a value in the range [0.5R, 1.5R].
2. To avoid premature loss of state, L must satisfy L >= (K +
0.5)*1.5*R, where K is a small integer. Then in the worst case,
K-1 successive messages may be lost without state being deleted.
To compute a lifetime L for a collection of state with different
R values R0, R1, ..., replace R by max(Ri).
Currently K = 3 is suggested as the default. However, it may be
necessary to set a larger K value for hops with high loss rate.
K may be set either by manual configuration per interface, or by
some adaptive technique that has not yet been specified.
3. Each RESERVE message carries a REFRESH_PERIOD object containing
the refresh time R used to generate refreshes. The recipient node
uses this R to determine the lifetime L of the stored state
created or refreshed by the message.
4. The refresh time R is chosen locally by each node. If the node
does not implement local repair of reservations disrupted by
route changes, a smaller R speeds up adaptation to routing
changes, while increasing the QOS-NSLP overhead. With local
repair, a router can be more relaxed about R since the periodic
refresh becomes only a backstop robustness mechanism. A node may
therefore adjust the effective R dynamically to control the
amount of overhead due to refresh messages.
The current suggested default for R is 30 seconds. However, the
default value Rdef should be configurable per interface.
5. When R is changed dynamically, there is a limit on how fast it
may increase. Specifically, the ratio of two successive values
R2/R1 must not exceed 1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be lost
without state timeout while R is increasing 30 percent per
refresh cycle.
6. To improve robustness, a node may temporarily send refreshes more 2. To avoid premature loss of state, L must satisfy L >= (K +
often than R after a state change (including initial state 0.5)*1.5*R, where K is a small integer. Then in the worst case,
establishment). K-1 successive messages may be lost without state being deleted.
7. The values of Rdef, K, and Slew.Max used in an implementation To compute a lifetime L for a collection of state with different R
should be easily modifiable per interface, as experience may lead values R0, R1, ..., replace R by max(Ri).
to different values. The possibility of dynamically adapting K Currently K = 3 is suggested as the default. However, it may be
and/or Slew.Max in response to measured loss rates is for future necessary to set a larger K value for hops with high loss rate. K
study. may be set either by manual configuration per interface, or by
some adaptive technique that has not yet been specified.
3. Each RESERVE message carries a REFRESH_PERIOD object
containing the refresh time R used to generate refreshes. The
recipient node uses this R to determine the lifetime L of the
stored state created or refreshed by the message.
4. The refresh time R is chosen locally by each node. If the
node does not implement local repair of reservations disrupted by
route changes, a smaller R speeds up adaptation to routing
changes, while increasing the QOS-NSLP overhead. With local
repair, a router can be more relaxed about R since the periodic
refresh becomes only a backstop robustness mechanism. A node may
therefore adjust the effective R dynamically to control the amount
of overhead due to refresh messages.
The current suggested default for R is 30 seconds. However, the
default value Rdef should be configurable per interface.
5. When R is changed dynamically, there is a limit on how fast it
may increase. Specifically, the ratio of two successive values
R2/R1 must not exceed 1 + Slew.Max.
Currently, Slew.Max is 0.30. With K = 3, one packet may be lost
without state timeout while R is increasing 30 percent per refresh
cycle.
6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial state
establishment).
7. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may lead
to different values. The possibility of dynamically adapting K
and/or Slew.Max in response to measured loss rates is for future
study.
Each node may insert a local QSPEC object provided it has a way of 5.3.5 Scoping
scoping this information (e.g. at the boundary of a domain or by
using the SCOPING object).
In some cases, a QNE needs to be able to distinguish between newly When sending some types of message, the node may wish to limit the
created, modified state or refreshed state based on the RESERVE distance that the message should travel along the path (the default
message alone (not in combination with state information obtained being the whole path). To do so a node MUST include a SCOPING
from previous messages). Therefore, one or more additional flags that object.
provide this differentiation may be needed. The specifictaion of
these flags are QoS model specific. Therefore, the contents and
encoding rules for this object are given in those QoS model
specifications.
In order to clearly distinguish between a RESERVE message that sets When receiving a message, before sending the message further, the QNE
the reserved resources to zero and a RESERVE message that tears down MUST inspect any scoping object to determine if it has reached the
QoS-NSLP state completely, a TEAR flag is foreseen that is carried in end of the scoped region. If so, it MUST NOT pass it further, and
the common header. Note that the potential initiation of (reverse MUST generate a RESPONSE if a RESPONSE_REQUEST object is present.
path) state removal at the NTLP is a separate issue. This will be
signaled over the API between NTLP and QoS-NSLP.
RESERVE messages are sent peer-to-peer. This means that a QNE 5.3.6 Error Spec
considers its adjacent upstream or downstream peer to be the source
of the RESERVE message. Note that two nodes that are adjacent at the
QoS-NSLP layer may in fact be separated by several NTLP hops. A QoS-
NSLP node may want to be able to detect changes in its QoS-NSLP
peers, or send a message to an explicitly identified node, e.g. for
tearing down a reservation on an old path. This functionality can be
provided by keeping track of a Source Identification Information
(SII) object that is similar in nature to the RSVP_HOP object
described in [6]. We assume such an SII (section 7.2) to be available
as a service from the NTLP.
The RESERVE message is idempotent; the resultant effect is the same The ERROR_SPEC object contains a value which indicates the condition
whether a message is received once or many times. In addition, the that occurred. Error values are to be specified for various
ordering of RESERVE messages matters - an old RESERVE message does conditions, such as:
not replace a newer one. Both of these features are required for o OK
protocol robustness - messages may be re-ordered on route (e.g. o Message type not supported
because of mobility, or at intermediate NTLP nodes) or spuriously o Object type not supported
retransmitted. o Insufficient resources
o Authentication failure
o Authorisation denied
o QoS model specific condition occurred
o ...
In order to tackle these issues, the RESERVE message contains a 5.3.7 Policy Data
Reservation Sequence Number (RSN) object. An RSN is an incrementing
sequence number that indicates the order in which state modifying
actions are performed by a QNE. The RSN has local significance only,
i.e. between QNEs. Attempting to make an identifier that was unique
in the context of a session identifier but the same along the
complete path would be very hard. Since RESERVE messages can be sent
by any node on the path that maintains reservation state (e.g. for
path repair) we would have the difficult task of attempting to keep
the identifier synchronized along the whole path. Since message
ordering only ever matters between a pair of peer QNEs, this means
that we can make the Reservation Sequence Number unique just between
a pair of neighboring stateful QNEs. Note that an alternative might
be for the NTLP to guarantee in-order delivery between the NSLP
peers.
A Flow identifier groups together state items for a single flow. The POLICY_DATA objects may contain various items to authenticate the
RSN is one of these state items, and is used to identify reordering user and allow the reservation to be authorised. Some possible
of messages and to allow the use of partial refresh messages. The contents are given in Appendix A.7, and some issues are also
state items for a number of flows can be linked together and discussed in Section 3.3.
identified as part of a single reservation using a Session
Identifier. The identifiers play complementary roles in the
management of QoS NSLP state. The flow identifier is carried by the
NTLP and it is augmented by additional flow identifying information
in the QSPEC, which is QoS model specific.
The sender of a RESERVE message may want to receive some confirmation 5.3.8 QSpec
from a downstream node. In this case the RESERVE message must contain
a RESPONSE_REQUEST object. The RESPONSE_REQUEST object contains the
Request Identification Information (RII) value used to match back a
RESPONSE to a request in a RESERVE message.
5.1.4 QUERY Messages The contents of the QSpec depends on the QoS model being used. It
may be that parts of the QSpec are standardised across multiple QoS
models. This topic is currently the topic of further study.
5.4 Message Processing Rules
5.4.1 RESERVE Messages
The RESERVE message is used to manipulate QoS reservation state in
QNEs. A RESERVE message may create, refresh, modify or remove such
state.
The format of a RESERVE message is as follows:
RESERVE = COMMON_HEADER
RSN [ SCOPING ] [ RESPONSE_REQUEST ]
[ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] [ *QSPEC ]
If any QSPEC objects are present, they MUST occur at the end of the
message. There are no other requirements on transmission order,
although the above order is recommended.
Three flags are defined for use in the common header with the RESERVE
message. These are:
TEAR - when set, indicates that reservation state and QoS NSLP
operation state should be torn down. This is indicated to the
RMF.
NO_REPLACE - when set, indicates that a RESERVE with different
Flow Routing Information (FRI) does not replace an existing one,
so the old one should not be torn down immediately
NO_FATE_SHARING - when set, indicates that sessions in the bundle
should not share fate with one another
An RSN MUST be present.
RESERVE messages MUST only be sent towards the NR.
If the QNE sending a RESERVE message wishes to use the reduced
overhead refresh mechanism described in Section 4.2.1, then it SHOULD
include a RESPONSE_REQUEST in the RESERVE message. It MUST NOT send
a reduced overhead refresh message (i.e. a RESERVE with a
non-incremented RSN and no QSPEC) unless it has received a RESPONSE
message for that RESERVE message.
If the session of this message is bound to another session, then the
RESERVE message MUST include the SESSION_ID of that other session in
a BOUND_SESSION_ID object.
Before admitting a reservation a QNE MUST determine whether the
request is authorized. It SHOULD exercise its local policy in
conjunction with the POLICY_DATA object to do this.
When a QNE receives a RESERVE message, its processing may involve
sending out a RESERVE message. When doing so, the QNE may insert or
remove 'local' QSPEC objects from the top of the stack. If there are
one or more QSPECs in the received RESERVE message, the last QSPEC
MUST NOT be removed when sending on the RESERVE message.
When a reservation is no longer required the QNI SHOULD send a
RESERVE message with the TEAR bit set in the header. On receiving
such a RESERVE message the QNE MUST remove any reservation state for
that session. It SHOULD remove the QoS NSLP state. It MAY signal to
the NTLP that it is no longer interested in NTLP state for that
session.
5.4.2 QUERY Messages
A QUERY message is used to request information about the data path A QUERY message is used to request information about the data path
without making a reservation. This functionality can be used to without making a reservation. This functionality can be used to
'probe' the network for path characteristics or for support of 'probe' the network for path characteristics or for support of
certain QoS models. The information obtained from a QUERY may be used certain QoS models. The information obtained from a QUERY may be
in the admission control process of a QNE (e.g. in case of used in the admission control process of a QNE (e.g. in case of
measurement-based admission control). Note that a QUERY does not measurement-based admission control). Note that a QUERY does not
change existing reservation state, nor does it cause state to be change existing reservation state, nor does it cause state to be
installed in nodes other than the one that generated the QUERY. installed in nodes other than the one that generated the QUERY.
The format of a QUERY message is as follows: The format of a QUERY message is as follows:
QUERY = COMMON_HEADER QUERY = COMMON_HEADER
[ SCOPING ] [ RESPONSE_REQUEST ]
[ SCOPING ] RESPONSE_REQUEST [ BOUND_SESSION_ID ]
[ POLICY_DATA ] [ *QSPEC ]
[ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] If any QSPEC objects are present, they MUST occur at the end of the
message. There are no other requirements on transmission order,
although the above order is recommended.
POLICY_DATA QSPEC [ *QSPEC ] No flags are defined are defined for use with the QUERY message.
The QSPEC object(s) must occur at the end of the message. There are A QUERY message MAY be scoped using the SCOPING object.
no other requirements on transmission order, although the above order
is recommended.
A QUERY message may be scoped using the SCOPING object. A QUERY message MUST contain a RESPONSE_REQUEST object, unless the
QUERY is being used to initiate reverse-path state for a
receiver-initiated reservation.
A QUERY message must contain a RESPONSE_REQUEST object, that carries If the session of this message is bound to another session, then the
the Request Identification Information (RII) that allows matching RESERVE message MUST include the SESSION_ID of that other session in
back RESPONSE to the QUERY request. It is transported unchanged along a BOUND_SESSION_ID object.
the data path and should be used in combination with the SCOPING
object to scope the RESPONSE to a QUERY message.
The QUERY message can gather information along the data path in a On receiving a QUERY message, the QoS model specific QUERY processing
number of objects. Some of these objects may be part of the QoS MAY cause the QSpec to be modified, to provide the answer to the
model. Others may be generic to the QoS-NSLP protocol. query. Future QoS NSLP objects may be added to the protocol with
similar properties in this respect.
The QUERY message opaquely must transport a QSPEC object, describing If this is last node to process this QUERY message (either because it
the desired service level and a POLICY_DATA object, authorizing the is the last node on the path, or because of scoping), and a
requestor of the service. Based on configured local policy, a node RESPONSE_REQUEST object is present, then a RESPONSE message MUST be
may ignore the content of the POLICY_DATA object. generated and passed back along the reverse of the path used by the
QUERY.
The QUERY message may carry the REFRESH_PERIOD object. It is If this is the last node and a RESPONSE_REQUEST object is not present
RECOMMENDED that in case of a receiver initiated reservation, the then the QUERY is a trigger to initiate a reservation in the reverse
QUERY message carries the REFRESH_PERIOD object. direction. If this node was not expecting to perform a
receiver-initiated reservation then an error MUST be sent back along
the path.
The SESSION_ID object must be included in the QUERY message only if When generating a QUERY to send out to pass the query further along
the session associated to this message has to be bound to another the path, the QNE MUST copy the RESPONSE_REQUEST (if present) into
session. The content of the SESSION_ID object represents the the new QUERY message unchanged.
SESSION_ID of the session that must be bound to the session
associated to the QUERY message carrying this object. The binding of
these two sessions is only possible in stateful QNEs.
5.1.5 RESPONSE Messages 5.4.3 RESPONSE Messages
The RESPONSE message is used to provide information about the result The RESPONSE message is used to provide information about the result
of a previous QoS-NSLP message, e.g. confirmation, error or of a previous QoS-NSLP message, e.g. confirmation of a reservation
information resulting from a query. The RESPONSE message is impotent, or information resulting from a query. The RESPONSE message is
it does not cause any state to be installed or modified. impotent, it does not cause any state to be installed or modified.
The format of a RESPONSE message is as follows: The format of a RESPONSE message is as follows:
RESPONSE = COMMON_HEADER RESPONSE = COMMON_HEADER
[ SCOPING / RSN ] ERROR_SPEC
[ RSN ] [ SCOPING ] [ ERROR_SPEC ] [ *QSPEC ]
QSPEC [ *QSPEC]
The QSPEC object(s) must occur at the end of the message. There are
no other requirements on transmission order, although the above order
is recommended.
A QNE may want to receive a RESPONSE message to inform it that the If any QSPEC objects are present, they MUST occur at the end of the
reservation has been successfully installed. A RESERVE or a QUERY message. There are no other requirements on transmission order,
message may contain a RESPONSE_REQUEST object for this purpose. Such although the above order is recommended.
a RESPONSE_REQUEST object can be used to request an explicit
confirmation of the state manipulation signaled in the RESERVE
message.
The forwarding of the RESPONSE message along the path does not No flags are defined are defined for use with the RESPONSE message.
necessarily imply the existence of NTLP reverse-path state at every
node. For example, the NTLP may have a mechanism to pass a message
directly from the egress to the ingress of a region of QNEs that do
not store per-flow reverse-path state.
A RESPONSE message may be scoped using the SCOPING object. A QUERY A RESPONSE message MUST be sent where the QNE is the last node to
always causes a RESPONSE to be sent. Therefore, a QUERY message will process a RESERVE or QUERY message containing a RESPONSE_REQUEST
always contain a RESPONSE_REQUEST object. A RESERVE may cause a object (based on scoping of the RESERVE or QUERY, or because this is
RESPONSE to be sent if this is explicitly requested, by using a the last node on the path). In this case, the RESPONSE MUST contain
RESPONSE_REQUEST object or when an error occurs. The RESPONSE a SCOPING object of type RII. The contents of the RESPONSE_REQUEST
Identification Information (RII) included in the RESPONSE_REQUEST object in the received RESERVE or QUERY message MUST be copied into
object should be included in the SCOPING object of a RESPONSE this SCOPING object in the RESPONSE.
message.
A RESPONSE message may carry an RSN object. The content of this In addition, a RESPONSE message MUST be sent when an error occurs
object must be identical to the content of the RSN object contained while processing a received message message. If the received message
in the RESERVE message that generated this RESPONSE message. contains a RESPONSE_REQUEST object, then an RII SCOPING object MUST
be put in the RESPONSE, as described above. If the RESPONSE is sent
as a result of the receipt of a RESERVE message without a
RESPONSE_REQUEST object, then the RSN of the received RESERVE message
MUST be copied into the RESPONSE message.
If a QNE or the QNR is unable to provide the requested information or A RESPONSE message MUST contain an ERROR_SPEC object which indicates
if the response is negative, the RESPONSE message must carry an the success of a reservation installation or an error condition.
ERROR_SPEC object. Depending on the value of the ERROR_SPEC, the RESPONSE MAY also
contain a QSPEC object.
The RESPONSE message opaquely must transport a QSPEC object(s), On receipt of a RESPONSE message containing an RII SCOPING object,
describing the desired service level. the QNE MUST attempt to match it to the outstanding response requests
for that signalling session. If the match succeeds, then the
RESPONSE MUST NOT be forwarded further along the path. If the match
fails, then the QNE MUST attempt to forward the RESPONSE to the next
peer QNE.
5.1.6 NOTIFY Messages On receipt of a RESPONSE message containing an RSN object, the QNE
MUST compare the RSN to that of the appropriate signalling session.
If the match succeeds then the error MUST be processed. The RESPONSE
message MUST NOT be forwarded further along the path whether or not
the match succeeds.
NOTIFY messages are used to convey information to a QNE. NOTIFY 5.4.4 NOTIFY Messages
messages are impotent (they do not cause a change in state directly).
NOTIFY messages differ from RESPONSE messagess in that they need not NOTIFY messages are used to convey information to a QNE
refer to any particular state or previously received message. They asynchronously. NOTIFY messages are impotent (they do not cause a
are sent asynchronously. The NOTIFY message itself does not trigger change in state directly).
or mandate any action in the receiving QNE.
The format of a NOTIFY message is as follows: The format of a NOTIFY message is as follows:
NOTIFY = COMMON_HEADER NOTIFY = COMMON_HEADER
ERROR_SPEC [ QSPEC ]
[ ERROR_SPEC ] QSPEC
The QSPEC object must occur at the end of the message. There are no No flags are defined are defined for use with the NOTIFY message.
other requirements on transmission order, although the above order is
recommended.
The information conveyed by a NOTIFY message may be related to error A NOTIFY message MUST contain an ERROR_SPEC object indicating the
conditions. In this case the ERROR_SPEC object must be carried by the reason for the notification. Depending on the ERROR_SPEC value, it
NOTIFY message. MAY contain a QSpec providing additional information.
The NOTIFY message opaquely must transport a QSPEC object, describing NOTIFY messages are sent asynchronously, rather than in response to
the desired service level. other messages. They may be sent in either direction (upstream or
downstream).
6. IANA considerations 6. IANA considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
Authority (IANA) regarding registration of values related to the Authority (IANA) regarding registration of values related to the
QoS-NSLP, in accordance with BCP 26 [8]. QoS-NSLP, in accordance with BCP 26 [7].
The QoS NSLP requires IANA to create two registries. One for QoS NSLP The QoS NSLP requires IANA to create two registries. One for QoS
message types, the other for QoS NSLP objects. NSLP message types, the other for QoS NSLP objects.
This specification defines four message types: RESERVE=1, QUERY=2, This specification defines four message types: RESERVE=1, QUERY=2,
RESPONSE=3 and NOTIFY=4. Values are taken from the Message type name RESPONSE=3 and NOTIFY=4. Values are taken from the Message type name
space (8 bits). New Message types may be defined and assigned values space (8 bits). New Message types may be defined and assigned values
by IANA. For this, standards action is required. by IANA. For this, standards action is required.
Common Control Information has a Class and C-type assigned by IANA. Common Control Information has a Class and C-type assigned by IANA.
This specification defines the following Common Control Information This specification defines the following Common Control Information
objects objects
RESPONSE_REQUEST: Class=1 RESPONSE_REQUEST: Class=1
C-type=1: empty C-type=1: empty
C-type=2: Request Identification Information C-type=2: Request Identification Information
RSN: Class=2 RSN: Class=2
C-type=1: RSN C-type=1: RSN
REFRESH_PERIOD: Class=3 REFRESH_PERIOD: Class=3
C-type=1: REFRESH_PERIOD C-type=1: REFRESH_PERIOD
skipping to change at page 41, line 32 skipping to change at page 53, line 30
C-type=1: single hop C-type=1: single hop
C-type=2: Region scoping C-type=2: Region scoping
C-type=3: RII scoping C-type=3: RII scoping
ERROR_SPEC: Class=6 ERROR_SPEC: Class=6
C-type=1: empty C-type=1: empty
IANA will assign new ClassNum values and/or C-type for Common Control IANA will assign new ClassNum values and/or C-type for Common Control
Information upon specification. The required specification needs to Information upon specification. The required specification needs to
indicate what the correct behaviour is in case the new ClassNum or indicate what the correct behaviour is in case the new ClassNum or
C-type is not understood. C-type is not understood.
This specification defines a QSPEC object with assigned class = 8. This specification defines a QSPEC object with assigned class = 8.
The C-type identifies the QoS model, which can be standardized, The C-type identifies the QoS model, which can be standardized,
well-known or private. well-known or private.
Standardized Standardized
Standardized QoS models have a C-type value in the range of 1-64. Standardized QoS models have a C-type value in the range of 1-64.
C-type values for standardized QoS models are assigned by IANA and C-type values for standardized QoS models are assigned by IANA and
skipping to change at page 42, line 9 skipping to change at page 54, line 5
Well-known Well-known
Well-known QoS models have a C-type value in the range of 65-128. Well-known QoS models have a C-type value in the range of 65-128.
They are assigned by IANA and require IETF consensus. They are assigned by IANA and require IETF consensus.
Private Private
C-type values from the range 129-256 are for private use. C-type values from the range 129-256 are for private use.
7. Requirements for the NSIS Transport Layer Protocol (NTLP) 7. Requirements for the NSIS Transport Layer Protocol (GIMPS)
For the moment this section will merely describe what we assume and/ For the moment this section will merely describe what we assume and/
or request to be available from the NTLP. This section will later be or request to be available from GIMPS. This section will later be
updated to describe the eventual interface when NTLP work gets updated to describe the eventual interface when GIMPS work gets
finalized. finalized.
7.1 Session identification 7.1 Session identification
The QoS NSLP keeps message and reservation state per session. A The QoS NSLP keeps message and reservation state per session. A
session is identified by a Session Identifier (SESSION_ID). The session is identified by a Session Identifier (SESSION_ID). The
SESSION_ID is the primary index for stored NSLP state and needs to be SESSION_ID is the primary index for stored NSLP state and needs to be
constant and unique (with a sufficiently high probability) along a constant and unique (with a sufficiently high probability) along a
path through the network. We rely on the NTLP to pick a value for the path through the network. QoS NSLP will pick a value for the
Session ID and pass it over the API. SESSION_ID and pass it over the API.
7.2 Support for bypassing intermediate nodes 7.2 Support for bypassing intermediate nodes
The QoS NSLP may want to restrict the handling of its messages to The QoS NSLP may want to restrict the handling of its messages to
specific nodes. This functionality is needed to support layering specific nodes. This functionality is needed to support layering
(explained in Section 4.3), when only the edge QNEs of a domain (explained in Section 4.3), when only the edge QNEs of a domain
process the message. This requires a mechanism at the NTLP level process the message. This requires a mechanism at GIMPS level (which
(which can be invoked by the QoS NSLP) to bypass intermediates nodes can be invoked by the QoS NSLP) to bypass intermediates nodes between
between the edges of the domain. the edges of the domain.
As a suggestion, we identified two ways for bypassing intermediate As a suggestion, we identified two ways for bypassing intermediate
nodes. One solution is for the end-to-end session to carry a nodes. One solution is for the end-to-end session to carry a
different protocol ID (QoS-NSLP-E2E-IGNORE protocol ID, similar to different protocol ID (QoS-NSLP-E2E-IGNORE protocol ID, similar to
the RSVP-E2E-IGNORE that is used for RSVP aggregation ([11]). Another the RSVP-E2E-IGNORE that is used for RSVP aggregation ([10]).
solution is based on the use of multiple levels of the router alert Another solution is based on the use of multiple levels of the router
option. In that case, internal routers are configured to handle only alert option. In that case, internal routers are configured to
certain levels of router alerts. The choice between both approaches handle only certain levels of router alerts. The choice between both
or another approach that fulfills the requirement is left to the NTLP approaches or another approach that fulfills the requirement is left
design. to GIMPS design.
7.3 Support for peer change identification 7.3 Support for peer change identification
There are several circumstances where it is necessary for a QNE to There are several circumstances where it is necessary for a QNE to
identify the adjacent QNE peer, which is the source of a signaling identify the adjacent QNE peer, which is the source of a signaling
application message; for example, it may be to apply the policy that application message; for example, it may be to apply the policy that
"state can only be modified by messages from the node that created "state can only be modified by messages from the node that created
it" or it might be that keeping track of peer identity is used as a it" or it might be that keeping track of peer identity is used as a
(fallback) mechanism for rerouting detection at the NSLP layer. (fallback) mechanism for rerouting detection at the NSLP layer.
We rely on the NTLP to provide this functionality and suggest it be We rely on GIMPS to provide this functionality and suggest it be
implemented as an opaque identifier (Source Identification implemented as an opaque identifier (Source Identification
Information (SII)) which, by default, all outgoing QoS-NSLP messages Information (SII)) which, by default, all outgoing QoS-NSLP messages
are tagged with at the NTLP layer. This identifier is propagated to are tagged with at GIMPS layer. This identifier is propagated to the
the next QNE, where it can be used to identify the state associated next QNE, where it can be used to identify the state associated with
with the message; The SII is logically similar to the RSVP_HOP object the message; The SII is logically similar to the RSVP_HOP object of
of [6]; however, any IP (and possibly higher level) addressing [5]; however, any IP (and possibly higher level) addressing
information is not interpreted in the QoS-NSLP. Indeed, the information is not interpreted in the QoS-NSLP. Indeed, the
intermediate NTLP nodes could enforce topology hiding by masking the intermediate GIMPS nodes could enforce topology hiding by masking the
content of the SII (provided this is done in a stable way). content of the SII (provided this is done in a stable way).
Keeping track of the SII of a certain reservation also provides a Keeping track of the SII of a certain reservation also provides a
means for the QoS-NSLP to detect route changes. When a QNE receives a means for the QoS-NSLP to detect route changes. When a QNE receives
RESERVE referring to existing state but with a different SII, it a RESERVE referring to existing state but with a different SII, it
knows that its upstream peer has changed. It can then use the old SII knows that its upstream peer has changed. It can then use the old
to send initiate a teardown along the old section of the path. This SII to send initiate a teardown along the old section of the path.
functionality would require the NTLP to be able to route based on the This functionality would require GIMPS to be able to route based on
SII. We would like this functionality to be available as a service the SII. We would like this functionality to be available as a
from the NTLP. service from GIMPS.
7.4 Support for stateless operation 7.4 Support for stateless operation
Stateless or reduced state QoS-NSLP operation makes the most sense Stateless or reduced state QoS-NSLP operation makes the most sense
when some nodes are able to operate in a stateless way at the NTLP when some nodes are able to operate in a stateless way at GIMPS level
level as well. Such nodes should not worry about keeping reverse as well. Such nodes should not worry about keeping reverse state,
state, message fragmentation and reassembly (at the NTLP), congestion message fragmentation and reassembly (at GIMPS), congestion control
control or security associations. A stateless or reduced state QNE or security associations. A stateless or reduced state QNE will be
will be able to inform the underlying NTLP of this situation. We rely able to inform the underlying GIMPS of this situation. We rely on
on the NTLP design to allow for a mode of operation that can take GIMPS design to allow for a mode of operation that can take advantage
advantage of this information. of this information.
7.5 Last node detection 7.5 Last node detection
There are situations in which a QNE needs to determine whether it is There are situations in which a QNE needs to determine whether it is
the last QNE on the data path (QNR), e.g. to construct and send a the last QNE on the data path (QNR), e.g. to construct and send a
RESPONSE message. RESPONSE message.
A number of conditions may result in a QNE determining that it is the A number of conditions may result in a QNE determining that it is the
QNR: QNR:
o the QNE may be the flow destination o the QNE may be the flow destination
o the QNE have some other prior knowledge that it should act as the o the QNE have some other prior knowledge that it should act as the
QNR QNR
o the QNE may be the last NSIS-capable node on the path o the QNE may be the last NSIS-capable node on the path
o the QNE may be the last NSIS-capable node on the path supporting o the QNE may be the last NSIS-capable node on the path supporting
the QoS NSLP the QoS NSLP
Of these four conditions, the last two can only be detected by the Of these four conditions, the last two can only be detected by GIMPS.
NTLP. We rely on the NTLP to inform the QoS-NSLP about these cases by We rely on GIMPS to inform the QoS-NSLP about these cases by
providing a trigger to the QoS-NSLP when it determines that it is the providing a trigger to the QoS-NSLP when it determines that it is the
last NE on the path, which supports the QoS-NSLP. It requires the last NE on the path, which supports the QoS-NSLP. It requires GIMPS
NTLP to have an error message indicating that no more NSLPs of a to have an error message indicating that no more NSLPs of a
particular type are available on the path. particular type are available on the path.
7.6 Re-routing detection 7.6 Re-routing detection
Route changes may be detected at the NTLP layer or the information Route changes may be detected at the GIMPS layer or the information
may be obtained by the NTLP through local interaction with or may be obtained by GIMPS through local interaction with or
notification from routing protocols or modules. This specification notification from routing protocols or modules. This specification
requests the NTLP design to foresee notification of this information requests the GIMPS design to foresee notification of a route change
over the API. (over the API) to the QNEs upstream of the NE where the route change
is detected.
7.7 Priority of signalling messages 7.7 Priority of signalling messages
The QoS-NSLP will generate messages with a range of performance The QoS-NSLP will generate messages with a range of performance
requirements for the NTLP. These requirements may result from a requirements for GIMPS. These requirements may result from a
prioritization at the QoS-NSLP (Section 4.3) or from the prioritization at the QoS-NSLP (Section 4.3) or from the
responsiveness expected by certain applications supported by the responsiveness expected by certain applications supported by the
QoS-NSLP. QoS-NSLP.
The NTLP design should be able to ensure that performance for one GIMPS design should be able to ensure that performance for one class
class of messages was not degraded by aggregation with other classes of messages was not degraded by aggregation with other classes of
of messages. It is currently an open issue how many priority levels messages. It is currently an open issue how many priority levels are
are required. required.
7.8 Knowledge of intermediate QoS NSLP unaware nodes 7.8 Knowledge of intermediate QoS NSLP unaware nodes
In some cases it is useful to know that a reservation has not been In some cases it is useful to know that a reservation has not been
installed at every router along the path. It is not possible to installed at every router along the path. It is not possible to
determine this using only NSLP functionality. determine this using only NSLP functionality.
The NTLP should be able to provide information to the NSLP about GIMPS should be able to provide information to the NSLP about whether
whether the message has passed through nodes that did not provide the message has passed through nodes that did not provide support for
support for this NSLP. this NSLP.
This might be realised by the NTLP by a mixture of NTLP node This might be realised by GIMPS by a mixture of GIMPS node counting,
counting, and examination of the IP TTL or Hop Limit. The QoS NSLP, and examination of the IP TTL or Hop Limit. The QoS NSLP, however,
however, does not need to know the number of intermediate nodes, only does not need to know the number of intermediate nodes, only that one
that one or more exists. or more exists.
7.9 NSLP Data Size 7.9 NSLP Data Size
When GIMPS passes the QoS NSLP data to the NSLP for processing, it
must also indicate the size of that data. (It is assumed that GIMPS
message structure will indicate how long this part of GIMPS message
is.)
7.10 Notification of NTLP 'D' flag value
When the NTLP passes the QoS NSLP data to the NSLP for processing, it When the NTLP passes the QoS NSLP data to the NSLP for processing, it
must also indicate the size of that data. (It is assumed that the must also indicate the value of the 'D' (Direction) flag for that
NTLP message structure will indicate how long this part of the NTLP message.
message is.)
7.10 NAT Traversal 7.11 NAT Traversal
The QoS NSLP relies on the NTLP for NAT traversal. The QoS NSLP relies on GIMPS for NAT traversal.
8. Open issues 8. Assumptions on the QoS model
8.1 Aggregation error handling 8.1 Resource sharing
QSPEC objects may be stacked to allow aggregation and layering. In This specification assumes that resource sharing is possible between
error-free conditions, the top of the QSPEC stack has the QSPEC flows with the same SESSION_ID that originate from the same QNI or
object that is locally valid. between flows with a different SESSION_ID that are related through
the BOUND_SESSION_ID object. For flows with the same SESSION_ID,
resource sharing is only applicable when the existing reservation is
not just replaced (which is indicated by the NO_REPLACE flag in the
common header.
A QNE may receive a QoS NSLP message with a QSPEC stack of which the The Resource Management Function (RMF) reserves resources for each
top object is not recognised. This can occur under error conditions, flow. We assume that the QoS model supports resource sharing between
e.g. when a domain boundary is misconfigured, or it me be the result flows. A QoS model may elect to implement a more general behaviour
from a policy to detect domain boundaries by encountering of supporting relative operations on existing reservations, such as
unrecognised QSPEC objects. ADDING or SUBTRACTING a certain amount of resources from the current
reservation. A QoS model may also elect to allow resource sharing
more generally, e.g. between all flows with the same DSCP.
In some situations, a QNE may be able to recover from the error 8.2 Reserve/commit support
condition by inspecting a larger portion of the stack.It is currently
an open question whether
o A QNE should be allowed to do that instead of or in addition to
sending an error.
o How far the stack can be inspected.
o If and how the QNE should update the stack in case it finds a
QSPEC it recognises.
8.2 Region scoping Reserve/commit behaviour means that the time at which the reservation
is made may be different from the time when the reserved resources
are actually set aside for the requesting session. This
specification acknowledges the usefulness of such a mechanism but
assumes that its implementation is opaque to QoS NSLP and is fully
handled by the QoS model. A COMMIT flag in the QoS-model specific
control information is suggested as a way to support this
functionality.
This specification allows QNEs to scope their messages, i.e. to 9. Open issues
9.1 Region scoping
This specification allows QNEs to scope their messages, i.e. to
restrict the extent to which messages may travel along and be restrict the extent to which messages may travel along and be
interpreted on the path. For this, the scopes of whole path, single interpreted on the path. For this, the scopes of whole path, single
hop and back to me (RII) are defined. Also, a region can be hop and back to me (RII) are defined. Also, a region can be
configured administratively or it can be derived from some other configured administratively or it can be derived from some other
means (e.g. RAO levels) in case of aggregation. means (e.g. RAO levels) in case of aggregation.
It is currently an open question whether this specification should This specification currently does not define and support a more
define and support a more generic notion of region (e.g. to implement generic notion of region (e.g. to implement region policies
region policies independent from aggregation regions,...). independent from aggregation regions,...). It is proposed to use the
concept of Localized RSVP for regions.
8.3 Priority of reservations 9.2 Priority of reservations
Priority of certain reservations over others may be required when QoS Priority of certain reservations over others may be required when QoS
resources are oversubscribed. In that case, existing reservations may resources are oversubscribed. In that case, existing reservations
be preempted in other to make room for new higher-priority may be preempted in other to make room for new higher-priority
reservations. A typical approach to deal with priority and preemption reservations. A typical approach to deal with priority and
is through the specification of a setup priority and holding priority preemption is through the specification of a setup priority and
for each reservation. The resource management function at each QNE holding priority for each reservation. The resource management
then keeps track of the resource consumption at each priority level. function at each QNE then keeps track of the resource consumption at
Reservations are established when resource at their setup priority each priority level. Reservations are established when resource at
level are still available. They may cause preemption of reservations their setup priority level are still available. They may cause
with a lower holding priority than their setup priority. preemption of reservations with a lower holding priority than their
setup priority.
Support of reservation priority is a QoS model specific issue and Support of reservation priority is a QoS model specific issue and
therefore outside the scope of this specification. However, the therefore outside the scope of this specification. However, the
concepts of setup and holding priority are widely accept and we concepts of setup and holding priority are widely accept and we
expect the specification of a Priority object in the QSPEC template expect the specification of a Priority object in the QSPEC template
to be useful for a wide range of QoS models. to be useful for a wide range of QoS models.
It is an open question to the NSIS community whether the concepts of It is an open question to the NSIS community whether the concepts of
setup and holding priority are useful enough to define a priority setup and holding priority are useful enough to define a priority
object in this specification. Alternatively, this could be left as object in this specification. Alternatively, this could be left as
QoS model specific. QoS model specific.
9. Security Considerations 9.3 Peering agreements on interdomain links
9.1 Introduction and Threat Overview This specification proposes ways to carry AAA information that may be
used at the edges of a domain to check whether the requestor is
allowed to use the requested resources. It is less likely that the
AAA information will be used inside a domain. In practice, there may
be peering relations between domains that allow for a certain amount
of traffic to be sent on an interdomain link without the need to
check the authorization of each individual session (effectively
making the peering domain the requestor of the resources). The
per-session authorization check may be avoided by setting up an
aggregate reservation on the inter-domain link for a specified amount
of resources and relating the end-to-end sessions to it using the
BOUND_SESSION_ID. In this way, the aggregate session is authorized
once (and infrequently updated). An alternative is for the edge node
of a domain to insert a token that authorizes the flow for the next
domain.
9.4 GIMPS Modifications for Refresh Overhead Reduction
As described in Section 4.2.4 a mechanism is available to reduce the
overhead of refresh messages. As currently specified, GIMPS may opt
to bundle several NSLP messages together. However, this still has
some additional overhead, particularly due to the requirement to
include Flow Routing Information (FRI) in every message. This may
not be strictly necessary for a message going only to the next GIMPS
hop.
It is an open issue to examine what additional optimisations are
possible and appropriate for refresh overhead reduction.
9.5 Path state maintenance implementation at NSLP
As currently described in Section 3.5.3, a QoS NSLP message is
required to create the necessary GIMPS reverse path state so that the
receiver-initiated RESERVE message can be sent upstream. (This must
be an NSLP message so that it visits the correct subset of GIMPS
nodes on the path.) This message may also be used to refresh the
GIMPS path state (see Section 9.6).
In this version, we have implemented this functionality by making the
RESPONSE_REQUEST object in QUERY optional. Basically, this means
that we send an empty QUERY message along the path. It is not clear
whether this path state maintenance functionality is sufficiently
different from QUERY to warrant the definition of a separate (NULL)
message.
It is also worth investigating whether other NSLPs have a similar
need and whether in that case it would be better to define a separate
NULL message across all NSLPs.
9.6 GIMPS Path State Maintenance
As currently described in Section 3.5.3, when performing
receiver-initiated reservations the QoS NSLP sends periodic
downstream QUERY messages to ensure that GIMPS reverse path state is
refreshed.
It is unclear how often such messages need to be sent, since the
lifetime of the path state is a matter for GIMPS. It, therefore, may
be necessary for GIMPS to inform the NSLP about this state lifetime.
An alternative solution to the refreshing of GIMPS path state by NSLP
messages is for GIMPS to refresh (and, where necessary, detect
changes in) its path state automatically, by sending periodic probe/
refresh messages of its own. The transmission of upstream messages
(such as the RESERVE in a receiver-initiated QoS NSLP reservation)
can be used to indicate that the reverse path state is still needed.
Whether such a technique is appropriate is for further consideration.
9.7 Protocol Operating Environment Assumptions
For receiver initiated and bidirectional reservations the question
arises of what assumptions to make about what end-to-end information
should be determined outside the NSIS protocols and what should be
carried end-to-end in NSLP messages in order to initiate signalling.
The NSIS protocol is not used alone. It is used in conjunction with
a variety of applications. The question arises of what the
interactions between NSIS (and the NSLP in particular) and these
applications is.
For a receiver initiated reservation, the we have the questions: How
do the sender and receiver determine that a receiver initiated
reservation is to be performed? And, how does information needed by
the receiver to perform the reservation, but only available at the
sender, be made transferred to the receiver so that the RESERVE
message can be sent?
In the bi-directional reservation case, we can either perform this as
a pair of two sender-initiated reservations or as a combination of
sender-initiated and receiver-initiated reservations. The latter
case has the same issues as for the general receiver initiated
reservation problem. The former raises similar questions: How does
the remote end know that a reservation is needed? And, how does it
know what resources to request?
Is it reasonable to assume that the decision that an end should
initiate a reservation is made totally outside the QoS NSLP itself
(e.g. through prior configuration, or application end-to-end
signalling such as SIP) or, should the QoS NSLP messages include some
method to trigger the other end to perform a reservation (whether
that be a receiver initiated reservation, or a sender initiated
reservation for the first bidirectional reservation case)?
In addition, should the QoS NSLP messages be able to carry extra data
(e.g. a QSpec object for the reverse direction) end-to-end that is
needed by the remote end to perform its reservation? (And, should
this be in the QoS NSLP, or through individual QoS models?) The
alternative to providing support in the QoS NSLP for this is to leave
it to application signalling to transfer any required information.
10. Security Considerations
10.1 Introduction and Threat Overview
The security requirement for the QoS NSLP is to protect the signaling The security requirement for the QoS NSLP is to protect the signaling
exchange for establishing QoS reservations against identified exchange for establishing QoS reservations against identified
security threats. For the signaling problem as a whole, these threats security threats. For the signaling problem as a whole, these
have been outlined in [21]; the NSIS framework [3] assigns a subset threats have been outlined in [21]; the NSIS framework [15] assigns a
of the responsibility to the NTLP and the remaining threats need to subset of the responsibility to GIMPS and the remaining threats need
be addressed by NSLPs. The main issues to be handled can be to be addressed by NSLPs. The main issues to be handled can be
summarised as: summarised as:
Authorization: Authorization:
The QoS NSLP must assure that the network is protected against The QoS NSLP must assure that the network is protected against
theft-of-service by offering mechanisms to authorize the QoS theft-of-service by offering mechanisms to authorize the QoS
reservation requestor. A user requesting a QoS reservation might reservation requestor. A user requesting a QoS reservation might
want proper resource accounting and protection against spoofing want proper resource accounting and protection against spoofing
and other security vulnerabilities which lead to denial of service and other security vulnerabilities which lead to denial of service
and financial loss. In many cases authorization is based on the and financial loss. In many cases authorization is based on the
authenticated identity. The authorization model must provide authenticated identity. The authorization model must provide
guarantees that replay attacks are either not possible or limited guarantees that replay attacks are either not possible or limited
to a certain extent. Authorization can also be based on traits to a certain extent. Authorization can also be based on traits
which enables the user to remain anonymous. Support for user which enables the user to remain anonymous. Support for user
identity confidentiality can be accomplished. identity confidentiality can be accomplished.
Message Protection: Message Protection:
Signaling message content should be protected against Signaling message content should be protected against
modification, replay, injection and eavesdropping while in modification, replay, injection and eavesdropping while in
transit. Authorization information, such as authorization tokens, transit. Authorization information, such as authorization tokens,
need protection. This type of protection at the NSLP layer is need protection. This type of protection at the NSLP layer is
neccessary to protect messages between NSLP nodes which includes neccessary to protect messages between NSLP nodes which includes
end-to-middle, middle-to-middle and even end-to-end protection. end-to-middle, middle-to-middle and even end-to-end protection.
In addition to the above-raised issues we see the following In addition to the above-raised issues we see the following
functionality provided at the NSLP layer: functionality provided at the NSLP layer:
Prevention of Denial of Service Attacks: Prevention of Denial of Service Attacks:
GIMPS and QoS NSLP nodes have finite resources (state storage, GIMPS and QoS NSLP nodes have finite resources (state storage,
processing power, bandwidth). The protocol mechanisms suggested in processing power, bandwidth). The protocol mechanisms suggested
this document should try to minimise exhaustion attacks against in this document should try to minimise exhaustion attacks against
these resources when performing authentication and authorization these resources when performing authentication and authorization
for QoS resources. for QoS resources.
To some extent the QoS NSLP relies on the security mechanisms To some extent the QoS NSLP relies on the security mechanisms
provided by GIMPS which by itself relies on existing authentication provided by GIMPS which by itself relies on existing authentication
and key exchange protocols. Some signaling messages cannot be and key exchange protocols. Some signaling messages cannot be
protected by GIMPS and hence should be used with care by the QoS protected by GIMPS and hence should be used with care by the QoS
NSLP. An API must ensure that the QoS NSLP implementation is aware of NSLP. An API must ensure that the QoS NSLP implementation is aware
the underlying security mechanisms and must be able to indicate which of the underlying security mechanisms and must be able to indicate
degree of security is provided between two GIMPS peers. If a level of which degree of security is provided between two GIMPS peers. If a
security protection for QoS NSLP messages is required which goes level of security protection for QoS NSLP messages is required which
beyond the security offered by GIMPS or underlying security goes beyond the security offered by GIMPS or underlying security
mechanisms, additional security mechanisms described in this document mechanisms, additional security mechanisms described in this document
must be used. The different usage environments and the different must be used. The different usage environments and the different
scenarios where NSIS is used make it very difficult to make general scenarios where NSIS is used make it very difficult to make general
statements without reducing its flexibility. statements without reducing its flexibility.
9.2 Trust Model 10.2 Trust Model
For this version of the document we will rely on a model which For this version of the document we will rely on a model which
requires trust between neighboring NSLP nodes to establish a requires trust between neighboring NSLP nodes to establish a
chain-of-trust along the QoS signaling path. This model is simple to chain-of-trust along the QoS signaling path. This model is simple to
deploy, was used in previous QoS authorization environments (such as deploy, was used in previous QoS authorization environments (such as
RSVP) and seems to provide sufficiently strong security properties. RSVP) and seems to provide sufficiently strong security properties.
We refer to this model as the 'New Jersey Turnpike' model. We refer to this model as the 'New Jersey Turnpike' model.
On the New Jersey Turnpike, motorists pick up a ticket at a toll On the New Jersey Turnpike, motorists pick up a ticket at a toll
booth when entering the highway. At the highway exit the ticket is booth when entering the highway. At the highway exit the ticket is
presented and payment is made at the toll booth for the distance presented and payment is made at the toll booth for the distance
driven. For QoS signaling in the Internet this procedure is roughly driven. For QoS signaling in the Internet this procedure is roughly
similar. In most cases the data sender is charged for transmitted similar. In most cases the data sender is charged for transmitted
data traffic whereby charging is provided only between neighboring data traffic where charging is provided only between neighboring
entities. entities.
+------------------+ +------------------+ +------------------+ +------------------+ +------------------+ +------------------+
| Network | | Network | | Network | | Network | | Network | | Network |
| X | | Y | | Z | | X | | Y | | Z |
| | | | | | | | | | | |
| -----------> -----------> | | -----------> -----------> |
| | | | | | | | | | | |
| | | | | | | | | | | |
+--------^---------+ +------------------+ +-------+----------+ +--------^---------+ +------------------+ +-------+----------+
skipping to change at page 48, line 31 skipping to change at page 63, line 31
Legend: Legend:
----> Peering relationship which allows neighboring ----> Peering relationship which allows neighboring
networks/entities to charge each other for the networks/entities to charge each other for the
QoS reservation and data traffic QoS reservation and data traffic
====> Data flow ====> Data flow
..... Communication to the end host ..... Communication to the end host
Figure 16: New Jersey Turnpike Model Figure 22: New Jersey Turnpike Model
The model shown in Figure 16 uses peer-to-peer relationships between The model shown in Figure 22 uses peer-to-peer relationships between
different administrative domains as a basis for accounting and different administrative domains as a basis for accounting and
charging. As mentioned above, based on the peering relationship a charging. As mentioned above, based on the peering relationship a
chain-of-trust is established. There are several issues which come to chain-of-trust is established. There are several issues which come
mind when considering this type of model: to mind when considering this type of model:
o This model allows authorization on a request basis or on a o This model allows authorization on a request basis or on a
per-session basis. Authorization mechanisms will be elaborated in per-session basis. Authorization mechanisms will be elaborated in
Section 9.3. The duration for which the QoS authorization is valid Section 3.6. The duration for which the QoS authorization is
needs to be controlled. Combining the interval with the soft-state valid needs to be controlled. Combining the interval with the
interval is possible. Notifications from the networks also seem to soft-state interval is possible. Notifications from the networks
be viable approach. also seem to be viable approach.
o The price for a QoS reservation needs to be determined somehow and o The price for a QoS reservation needs to be determined somehow and
communicated to the charged entity and to the network where the communicated to the charged entity and to the network where the
charged entity is attached. Price distribution protocols are not charged entity is attached. Price distribution protocols are not
covered in this version of the document. This model assumes, per covered in this version of the document. This model assumes, per
default, that the data sender is authorizing the QoS reservation. default, that the data sender is authorizing the QoS reservation.
Please note that this is only a simplification and further Please note that this is only a simplification and further
extensions are possible and left for a future version of this extensions are possible and left for a future version of this
document. document.
o This architecture seems to be simple enough to allow a scalable o This architecture seems to be simple enough to allow a scalable
solution (ignoring reverse charging, multicast issues and price solution (ignoring reverse charging, multicast issues and price
distribution). distribution).
Charging the data sender as performed in this model simplifies Charging the data sender as performed in this model simplifies
security handling by demanding only peer-to-peer security protection. security handling by demanding only peer-to-peer security protection.
Node A would perform authentication and key establishment. The Node A would perform authentication and key establishment. The
established security association (together with the session key) established security association (together with the session key)
would allow the user to protect QoS signaling messages. The identity would allow the user to protect QoS signaling messages. The identity
used during the authentication and key establishment phase would be used during the authentication and key establishment phase would be
used by Network X (see Figure 16) to perform the so-called used by Network X (see Figure 22) to perform the so-called
policy-based admission control procedure. In our context this user policy-based admission control procedure. In our context this user
identifier would be used to establish the necessary infrastructure to identifier would be used to establish the necessary infrastructure to
provide authorization and charging. Signaling messages later provide authorization and charging. Signaling messages later
exchanged between the different networks are then also subject to exchanged between the different networks are then also subject to
authentication and authorization. The authenticated entity thereby authentication and authorization. The authenticated entity thereby
is, however, the neighboring network and not the end host. is, however, the neighboring network and not the end host.
The New Jersey Turnpike model is attractive because of its The New Jersey Turnpike model is attractive because of its
simplicity. S. Schenker et. al. [23] discuss various accounting simplicity. S. Schenker et. al. [24] discuss various accounting
implications and introduced the edge pricing model. The edge pricing implications and introduced the edge pricing model. The edge pricing
model shows similarity to the model described in this section with model shows similarity to the model described in this section with
the exception that mobility and the security implications itself are the exception that mobility and the security implications itself are
not addressed. not addressed.
9.3 QoS Authorization 10.3 Computing the authorization decision
Authorization is a necessary function in order to prevent
theft-of-service and to enable charging. With regard to authorization
a few issues still need to be resolved to specify the protocol
interaction for a QoS NSLP with regard to authorization of resource
requests.
This section provides a description of the different approaches for
providing authorization for QoS resource requests. Three different
approaches are shown, whereby one is a two-party and two others
describe a three party approach.
9.3.1 Authorization for the two party approach
This section starts with the conceptually simpler two party approach.
+-------------+ QoS request +--------------+
| Entity |----------------->| Entity |
| requesting | | authorizing |
| resource |granted / rejected| resource |
| |<-----------------| request |
+-------------+ +--------------+
^ ^
+...........................+
financial establishment
Figure 17: Two party approach
Figure 17 describes the simple and basic approach where
the authorization decision is purely executed between the two
entities only or
where previous (out-of-band) mechanisms separated the signaling
protocol from executing other entities during NSIS protocol
execution.
The entity authorizing the resource request and the entity actually
performing the QoS reservation are in the same administrative domain.
Hence they are treated as a single logical entity.
Examples for this type of model can be found between two neighboring
networks (inter-domain signaling) where a long-term contract (or
other out-of-band mechanisms) exists and allows both networks to know
how to charge the other entity (i.e. how the authorizing entity
finally gets paid for the consumed resources) and
how to authorize the resource requesting entity (i.e. associating
the identifier of the protected signaling message to the identity
used in the authentication and key exchange protocol run and
finally this identity to the user identity of the contract for the
purpose of charging).
No additional message signaling for authorization is required. In
this scenario the identity used during the authentication and key
exchange process is used for authorizing the same entity. The QoS
NSLP needs to have access to this authenticated identity via an API.
9.3.2 Token based three party approach
This section describes an approach which uses authorization tokens
such as those introduced with [12] and [13] or with the Open
Settlement protocol [26]. The former only associates two different
signaling protocols and their authorization with each other whereas
the latter is a form of digital money. In this text we refer to the
former as the 'authorization tokens' and in the latter case as 'OSP
tokens'. In case of authorization tokens the entity which requests
authorization wants to run, for example, SIP with an entity in the
local network and wants to experience quality of service for the
media traffic. Some form of authorization will be provided at the SIP
proxy, which acts as the resource authorizing entity in Figure 18. In
case of a successful verification of the request SIP signaling
returns an authorization token which is subsequently included in the
QoS signaling protocol to refer to the previous authorization
decision. The authorization decision can be passed by value or by
reference. The advantage of the latter is that the token is smaller
(i.e., effectively only a pointer to installed state in the network)
with the disadvantage that the entity performing the QoS reservation
has to query the state, possibly from a central entity.
The token based approach assumes that the entity which authorizes the
QoS request (and which also creates the token) is trusted by the
entity which performs the QoS reservation. These two entities do not
necessarily need to be in the same administrative domain. Security
mechanisms must ensure that
the token cannot be modified
the token questing entity is authenticated and authorized at the
token granting entity
the token cannot be stolen and reused by an adversary
Hence, to prevent an adversary from eavesdropping and stealing the
authorization token it is necessary to establish at least a
unilateral authenticated secure channel between entity A and B. As a
side-effect it is possible to provide anonymous authorization since
the authorization decision based on the received token by entity B
does not need to be based on the identity of A. This assumes that
entity C does not provide entity B with the identity.
Authorization
Token Request +--------------+
+-------------->| Entity C | financial settlement
| | authorizing | <..................+
| | resource | .
| +------+ request | .
| | +--------------+ .
| | .
| |Authorization .
| |Token .
| | .
| | .
| | .
| | QoS request .
+-------------+ + Authz. Token +--------------+ .
| Entity |----------------->| Entity B | .
| requesting | | performing | .
| resource |granted / rejected| QoS | <..+
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 18: Token based three party approach
The token is only an attribute in the QoS NSLP message. The token
acts as a form of voucher and is therefore a one-shot message. For
the OSP token (or digital money) alike approach, as soon as the
credits are consumed a new token needs to be requested in order.
Refresh messages can therefore be used to trigger the transmission of
new tokens. A trigger message from the network is necessary to
request a new token. Tokens provide a good mechanism for the client
to restrict the amount of spend resources and to quickly learn about
the cost of a QoS reservation if tokens represent only a small value
(such as those used in hash-chain based approaches). The refresh
interval is therefore, in some sense, bound to the "charging"
interval.
Please note that OSP tokens only serve as an example here. The
content of the OSP token is tailored towards its usage in the
telephony environment. Therefore, we see OSP tokens as a prominent
representative of authorization token usage.
Since authorization tokens or OSP tokens can be fairly large
fragmentation is possible or even likely.
9.3.3 Generic three party approach
This section covers a generic three party approach. Figure 19 shows
the intra-domain variant of the exchange.
+--------------+
| Entity C |
| authorizing |
| resource |
| request |
+-----------+--+
^ |
| |
QoS | | QoS
authz| |authz
req.| | res.
| |
QoS | v
+-------------+ request +--+-----------+
| Entity |----------------->| Entity B |
| requesting | | performing |
| resource |granted / rejected| QoS |
| A |<-----------------| reservation |
+-------------+ +--------------+
Figure 19: Three party approach (intra-domain)
The main difference between the scenario in Figure 19 and Figure 20
is the trust relationship between the participating entities. In
Figure 20 the home AAA server is responsible for authoring the QoS
request. This might be on a per-request basis, periodically, or on a
per-session basis. In both cases the EAP authentication runs between
the EAP Peer (entity A in Figure 19) and between the EAP Server
(entity C in Figure 19). For the EAP method protocol run the
Authenticator (entity B in Figure 19) is not actively involved. To
fulfill the requirements of the EAP keying framework it is necessary
to execute a protocol exchange between entity A and entity B
subsequently to successful EAP authentication. This exchange should
lead to a secure channel between these two entities.
The main advantage of this exchange is that
a number of authentication and key exchange protocols can be used
in a very flexible fashion; these protocols can be tailed exactly
to the needs of the architecture and the environment
a secure channel can be established
the protocol exchange is effectively a three party protocol
authorization can be incorporated in a very flexible way which
allows the home network (or some other entity) to give tight
control over the sessions
The disadvantage of this approach is that there is no out-of-the-box
solution available. Further investigation is required here.
+-----------------------------+ +-----------------+
| Local Network | | |
| |QoS | |
| +------------+ authz. req. +---------+ |
| | Local |-----+----+--->| Home | |
| | AAA | |QoS | | AAA | |
| | Server |<----+----+----| Server | |
| +---------+--+ authz. res. +---------+ |
| ^ | | | |
| | | <...financial...> |
| QoS | QoS | settlement |
| authz| authz| | | |
| req.| res.| | | |
| | | | | |
| | v | | |
+----------+ QoS +----+---------+ | | Users |
|Entity | request | Entity | | | Home Network |
|requesting|--+------->| performing | | +-----------------+
|resource |<-+--------| QoS | |
+----------+ granted/ | reservation | |
rejected +--------------+ |
| |
+-----------------------------+
Figure 20: Three party approach (inter-domain)
9.3.4 Computing the authorization decision
Whenever an authorization decision has to be made then there is the Whenever an authorization decision has to be made then there is the
question which information serves as an input to the authorizing question which information serves as an input to the authorizing
entity. The following information items have been mentioned in the entity. The following information items have been mentioned in the
past for computing the authorization decision (in addition to the past for computing the authorization decision (in addition to the
authenticated identity): authenticated identity):
Price Price
QoS objects QoS objects
Policy rules Policy rules
Policy rules include attributes like time of day, subscription to Policy rules include attributes like time of day, subscription to
certain services, membership, etc. into consideration when computing certain services, membership, etc. into consideration when computing
an authorization decision. an authorization decision.
A detailed description of the authorization handling will be left for A detailed description of the authorization handling will be left for
a future version of this document. The authors assume that the QoS a future version of this document. The authors assume that the QoS
NSLP needs to provide a number of attributes to support the large NSLP needs to provide a number of attributes to support the large
range of scenarios. range of scenarios.
10. Change History 11. Change History
Changes from -00 Changes from -00
* Additional explanation of RSN versus Session ID differences. * Additional explanation of RSN versus Session ID differences.
(Session IDs still need to be present and aren't replaced by (Session IDs still need to be present and aren't replaced by
RSNs. Explain how QoS-NSLP could react once it notes that it RSNs. Explain how QoS-NSLP could react once it notes that it
maintains stale state.) maintains stale state.)
* Additional explanation of message types - why we don't just * Additional explanation of message types - why we don't just
have RESERVE and RESPONSE. have RESERVE and RESPONSE.
* Clarified that figure 1 is not an implementation restriction. * Clarified that figure 1 is not an implementation restriction.
Changes from -01 Changes from -01
* Significant restructuring. * Significant restructuring.
* Added more concrete details of message formats and processing. * Added more concrete details of message formats and processing.
* Added description of layering/aggregation concepts. * Added description of layering/aggregation concepts.
* Added details of authentication/authorisation aspects. * Added details of authentication/authorisation aspects.
Changes from -02
* Addressed comments from early review.
* Added text on receiver-initiated and bi-directional
reservations.
* Extended description of session binding. Added support for
fate sharing.
* Restructured message formats and processing section.
* Clarified refresh reduction mechanism.
* Added assumptions on QoS model.
* Added assumptions on operating environment.
11. Acknowledgements 12. Acknowledgements
The authors would like to thank Eleanor Hepworth for her useful The authors would like to thank Eleanor Hepworth for her useful
comments. comments.
12. Contributors 13. Contributors
This draft combines work from three individual drafts. The following This draft combines work from three individual drafts. The following
authors from these drafts also contributed to this document: Robert authors from these drafts also contributed to this document: Robert
Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia
Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and
Maarten Buechli (Dante) and Eric Waegeman (Alcatel). Maarten Buechli (Dante) and Eric Waegeman (Alcatel).
Yacine El Mghazli (Alcatel) contributed text on AAA. Yacine El Mghazli (Alcatel) contributed text on AAA.
Normative References 14. References
14.1 Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997. Levels", BCP 14, RFC 2119, March 1997.
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax [2] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
[3] Hancock, R., "Next Steps in Signaling: Framework", [3] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for
draft-ietf-nsis-fw-05 (work in progress), October 2003. Signaling", draft-ietf-nsis-ntlp-01 (work in progress), February
2004.
[4] Schulzrinne, H., "GIMPS: General Internet Messaging Protocol for
Signaling", draft-ietf-nsis-ntlp-00 (work in progress), October
2003.
Informative References 14.2 Informative References
[5] Braden, B., Clark, D. and S. Shenker, "Integrated Services in [4] Braden, B., Clark, D. and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994. the Internet Architecture: an Overview", RFC 1633, June 1994.
[6] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin, [5] Braden, B., Zhang, L., Berson, S., Herzog, S. and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997. Specification", RFC 2205, September 1997.
[7] Wroclawski, J., "The Use of RSVP with IETF Integrated [6] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997. Services", RFC 2210, September 1997.
[8] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA [7] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
Considerations Section in RFCs", BCP 26, RFC 2434, October Considerations Section in RFCs", BCP 26, RFC 2434, October
1998. 1998.
[9] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W. [8] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z. and W.
Weiss, "An Architecture for Differentiated Services", RFC 2475, Weiss, "An Architecture for Differentiated Services", RFC 2475,
December 1998. December 1998.
[10] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S. [9] Berger, L., Gan, D., Swallow, G., Pan, P., Tommasi, F. and S.
Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC Molendini, "RSVP Refresh Overhead Reduction Extensions", RFC
2961, April 2001. 2961, April 2001.
[11] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie, [10] Baker, F., Iturralde, C., Le Faucheur, F. and B. Davie,
"Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175, "Aggregation of RSVP for IPv4 and IPv6 Reservations", RFC 3175,
September 2001. September 2001.
[12] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session [11] Hamer, L-N., Gage, B., Kosinski, B. and H. Shieh, "Session
Authorization Policy Element", RFC 3520, April 2003. Authorization Policy Element", RFC 3520, April 2003.
[13] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session [12] Hamer, L-N., Gage, B. and H. Shieh, "Framework for Session
Set-up with Media Authorization", RFC 3521, April 2003. Set-up with Media Authorization", RFC 3521, April 2003.
[14] Chaskar, H., "Requirements of a Quality of Service (QoS) [13] Chaskar, H., "Requirements of a Quality of Service (QoS)
Solution for Mobile IP", RFC 3583, September 2003. Solution for Mobile IP", RFC 3583, September 2003.
[15] Brunner, M., "Requirements for Signaling Protocols", [14] Brunner, M., "Requirements for Signaling Protocols", RFC 3726,
draft-ietf-nsis-req-09 (work in progress), August 2003. April 2004.
[15] Hancock, R., "Next Steps in Signaling: Framework",
draft-ietf-nsis-fw-05 (work in progress), October 2003.
[16] Tschofenig, H., "NSIS Authentication, Authorization and [16] Tschofenig, H., "NSIS Authentication, Authorization and
Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work Accounting Issues", draft-tschofenig-nsis-aaa-issues-01 (work
in progress), March 2003. in progress), March 2003.
[17] Tschofenig, H., "QoS NSLP Authorization Issues", [17] Tschofenig, H., "QoS NSLP Authorization Issues",
draft-tschofenig-nsis-qos-authz-issues-00 (work in progress), draft-tschofenig-nsis-qos-authz-issues-00 (work in progress),
June 2003. June 2003.
[18] Ash, J., "NSIS Network Service Layer Protocol QoS Signaling [18] Ash, J., "NSIS Network Service Layer Protocol QoS Signaling
skipping to change at page 57, line 17 skipping to change at page 67, line 26
[19] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load [19] Kappler, C., "A QoS Model for Signaling IntServ Controlled-Load
Service with NSIS", Service with NSIS",
draft-kappler-nsis-qosmodel-controlledload-00 (work in draft-kappler-nsis-qosmodel-controlledload-00 (work in
progress), February 2004. progress), February 2004.
[20] Bader, A., "RMD (Resource Management in Diffserv) QoS-NSLP [20] Bader, A., "RMD (Resource Management in Diffserv) QoS-NSLP
model", draft-bader-rmd-qos-model-00 (work in progress), model", draft-bader-rmd-qos-model-00 (work in progress),
February 2004. February 2004.
[21] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS", [21] Tschofenig, H. and D. Kroeselberg, "Security Threats for NSIS",
draft-ietf-nsis-threats-03 (work in progress), October 2003. draft-ietf-nsis-threats-04 (work in progress), February 2004.
[22] Westberg, L., "Resource Management in Diffserv (RMD) [22] Westberg, L., "Resource Management in Diffserv (RMD)
Framework", draft-westberg-rmd-framework-04.txt, work in Framework", draft-westberg-rmd-framework-04.txt, work in
progress, September 2003. progress, September 2003.
[23] Shenker, S., Clark, D., Estrin, D. and S. Herzog, "Pricing in [23] Breslau, L., "Two Issues in Reservation Establishment", Proc.
ACM SIGCOMM '95 , Cambridge , MA , August 1995.
[24] Shenker, S., Clark, D., Estrin, D. and S. Herzog, "Pricing in
computer networks: Reshaping the research agenda", Proc. of computer networks: Reshaping the research agenda", Proc. of
TPRC 1995, 1995. TPRC 1995, 1995.
[24] Metro Ethernet Forum, "Ethernet Services Model", letter ballot [25] Metro Ethernet Forum, "Ethernet Services Model", letter ballot
document , August 2003. document , August 2003.
[25] Jacobson, V., "Synchronization of Periodic Routing Messages", [26] Jacobson, V., "Synchronization of Periodic Routing Messages",
IEEE/ACM Transactions on Networking , Vol. 2 , No. 2 , April IEEE/ACM Transactions on Networking , Vol. 2 , No. 2 , April
1994. 1994.
[26] ETSI, "Telecommunications and internet protocol harmonization [27] ETSI, "Telecommunications and internet protocol harmonization
over networks (tiphon); open settlement protocol (osp) for over networks (tiphon); open settlement protocol (osp) for
inter- domain pricing, authorization, and usage exchange", inter- domain pricing, authorization, and usage exchange",
Technical Specification 101 321, version 2.1.0. Technical Specification 101 321, version 2.1.0.
Authors' Addresses Authors' Addresses
Sven Van den Bosch Sven Van den Bosch
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
Antwerpen B-2018 Antwerpen B-2018
skipping to change at page 58, line 4 skipping to change at page 68, line 14
Authors' Addresses Authors' Addresses
Sven Van den Bosch Sven Van den Bosch
Alcatel Alcatel
Francis Wellesplein 1 Francis Wellesplein 1
Antwerpen B-2018 Antwerpen B-2018
Belgium Belgium
EMail: sven.van_den_bosch@alcatel.be EMail: sven.van_den_bosch@alcatel.be
Georgios Karagiannis Georgios Karagiannis
University of Twente/Ericsson University of Twente/Ericsson
P.O. Box 217 P.O. Box 217
Enschede 7500 AE Enschede 7500 AE
The Netherlands The Netherlands
EMail: karagian@cs.utwente.nl EMail: karagian@cs.utwente.nl
Andrew McDonald Andrew McDonald
Siemens/Roke Manor Research Siemens/Roke Manor Research
Roke Manor Research Ltd. Roke Manor Research Ltd.
Romsey, Hants SO51 0ZN Romsey, Hants SO51 0ZN
UK UK
EMail: andrew.mcdonald@roke.co.uk EMail: andrew.mcdonald@roke.co.uk
Appendix A. Object Definitions Appendix A. Object Definitions
The currentlly specified C-Types definitions are contained in this The currentlly specified C-Types definitions are contained in this
Appendix. To accommodate other address families, additional C-Types Appendix. To accommodate other address families, additional C-Types
could easily be defined. could easily be defined.
All unused fields should be sent as zero and ignored on receipt. All unused fields should be sent as zero and ignored on receipt.
A.1 RESPONSE_REQUEST Class A.1 RESPONSE_REQUEST Class
RESPONSE_REQUEST Class = 1. RESPONSE_REQUEST Class = 1.
RESPONSE_REQUEST object: Class = 1, C-Type = 1 RESPONSE_REQUEST object: Class = 1, C-Type = 1
The object content is empty The object content is empty
RESPONSE_REQUEST object: Class = 1, C-Type = 2 RESPONSE_REQUEST object: Class = 1, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
skipping to change at page 59, line 4 skipping to change at page 69, line 10
RESPONSE_REQUEST object: Class = 1, C-Type = 1 RESPONSE_REQUEST object: Class = 1, C-Type = 1
The object content is empty The object content is empty
RESPONSE_REQUEST object: Class = 1, C-Type = 2 RESPONSE_REQUEST object: Class = 1, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Request Identification Information (RII)(4 bytes) | | Request Identification Information (RII)(4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Request Identification Information (RII) (4 bytes) Request Identification Information (RII) (4 bytes)
An identifier which must be (probabilistically) unique An identifier which must be (probabilistically) unique
within the context of a SESSION_ID, and SHOULD be different within the context of a SESSION_ID, and SHOULD be different
for each response request. Used by a node to match back a for each response request. Used by a node to match back a
RESPONSE to a request in a RESERVE or QUERY message. RESPONSE to a request in a RESERVE or QUERY message.
A.2 RSN Class A.2 RSN Class
RSN class = 2. RSN class = 2.
RSN object: Class = 2, C-Type = 1 RSN object: Class = 2, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Reservation Sequence Number (RSN) (4 bytes) | | Reservation Sequence Number (RSN) (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Reservation Sequence Number (RSN) (4 bytes) Reservation Sequence Number (RSN) (4 bytes)
An incrementing sequence number that indicates the order in An incrementing sequence number that indicates the order in
which state modifying actions are performed by a QNE. It has which state modifying actions are performed by a QNE. It
local significance only, i.e. between a pair of neighbouring has local significance only, i.e. between a pair of
stateful QNEs. neighbouring stateful QNEs.
A.3 REFRESH_PERIOD Class A.3 REFRESH_PERIOD Class
REFRESH_PERIOD class = 3. REFRESH_PERIOD class = 3.
REFRESH_PERIOD Object: Class = 3, C-Type = 1 REFRESH_PERIOD Object: Class = 3, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Refresh Period R (4 bytes) | | Refresh Period R (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Refresh Period R (4 bytes) Refresh Period R (4 bytes)
The refresh timeout period R used to generate this message; The refresh timeout period R used to generate this message;
in milliseconds. in milliseconds.
A.4 SESSION_ID Class A.4 SESSION_ID Class
SESSION_ID class = 4. SESSION_ID class = 4.
SESSION_ID Object: Class = 4, C-Type = 1 SESSION_ID Object: Class = 4, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| | | |
+ + + +
| | | |
+ SESSION_ID (16 bytes) + + SESSION_ID (16 bytes) +
| | | |
+ + + +
| | | |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
SESSION_ID (16 bytes) SESSION_ID (16 bytes)
It represents the SESSION_ID as specified in [3] of the It represents the SESSION_ID as specified in [15] of the
session that must be bound to the session associated to the session that must be bound to the session associated to the
message carrying this object. message carrying this object.
A.5 SCOPING Class A.5 SCOPING Class
SCOPING class = 5. SCOPING class = 5.
SCOPING Object: Class = 5, C-Type = 1 SCOPING Object: Class = 5, C-Type = 1
No content value. Selection of a single hop message scoping. No content value. Selection of a single hop message scoping.
SCOPING Object: Class = 5, C-Type = 2 SCOPING Object: Class = 5, C-Type = 2
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Region scoping (4 bytes) | | Region scoping (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Region scoping (4 bytes) Region scoping (4 bytes)
Ordered number, forwarded by routers belonging to region Ordered number, forwarded by routers belonging to region
skipping to change at page 61, line 26 skipping to change at page 71, line 34
SCOPING Object: Class = 5, C-Type = 3 SCOPING Object: Class = 5, C-Type = 3
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| RII scoping (4 bytes) | | RII scoping (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
RII (back to me) scoping (4 bytes) RII (back to me) scoping (4 bytes)
An identifier which must be (probabilistically) unique An identifier which must be (probabilistically) unique
within the context of a SESSION_ID, and SHOULD be different within the context of a SESSION_ID, and SHOULD be different
for each response request. Used by a node to match back a for each response request. Used by a node to match back a
RESPONSE to a request in a RESERVE or QUERY message. RESPONSE to a request in a RESERVE or QUERY message.
A.6 ERROR_SPEC Class A.6 ERROR_SPEC Class
ERROR_SPEC class = 6. ERROR_SPEC class = 6.
ERROR_SPEC object: Class = 6, C-Type = 1 ERROR_SPEC object: Class = 6, C-Type = 1
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Error (4 bytes) | | Error (4 bytes) |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Flags | Error Code | Error Value | | Flags | Error Code | Error Value |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
Error (4 bytes) Error (4 bytes)
To be done To be done
Flags (1 byte) Flags (1 byte)
To be done To be done
Error Code (1 byte) Error Code (1 byte)
A one-octet error description. A one-octet error description.
Error Value (2 bytes) Error Value (2 bytes)
A two-octet field containing additional information about A two-octet field containing additional information about
the error. Its contents depend upon the Error Type. the error. Its contents depend upon the Error Type.
The values for Error Code and Error Value are defined in The values for Error Code and Error Value are defined in
Appendix B (to be done). Appendix B (to be done).
A.7 POLICY_DATA Class A.7 POLICY_DATA Class
This section presents a set of specifications for supporting generic This section presents a set of specifications for supporting generic
authorization in QoS NSLP. These specs include the standard format of authorization in QoS NSLP. These specs include the standard format
POLICY_DATA objects, and a description of QoS NSLP handling of of POLICY_DATA objects, and a description of QoS NSLP handling of
authorization events. This section does not advocate a particular authorization events. This section does not advocate a particular
authorization approach (2-party, 3-party, token-based 3-party). authorization approach (2-party, 3-party, token-based 3-party).
The traffic control block is responsible for controlling and The traffic control block is responsible for controlling and
enforcing access and usage policies. enforcing access and usage policies.
A.7.1 Base Format A.7.1 Base Format
POLICY_DATA object: Class=7, C-Type=1 POLICY_DATA object: Class=7, C-Type=1
+-------------------------------------------------------+ +-------------------------------------------------------+
| | | |
// Option List // // Option List //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
| | | |
// Policy Element List // // Policy Element List //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
Option List: Variable length. See more details in Appendix A.7.2. Option List: Variable length. See more details in Appendix A.7.2.
Policy Element List: Variable length. See more details in Appendix Policy Element List: Variable length. See more details in Appendix
A.7.3. A.7.3.
A.7.2 Options A.7.2 Options
This section describes a set of options that may appear in This section describes a set of options that may appear in
POLICY_DATA objects. Some policy options appear as QoS NSLP objects POLICY_DATA objects. Some policy options appear as QoS NSLP objects
but their semantic is modified when used as policy data options. but their semantic is modified when used as policy data options.
Policy Refresh TIME_VALUES (PRT) object: Policy Refresh TIME_VALUES (PRT) object:
The Policy Refresh TIME_VALUES (PRT) option is used to slow policy The Policy Refresh TIME_VALUES (PRT) option is used to slow policy
refresh frequency for policies that have looser timing constraints refresh frequency for policies that have looser timing constraints
relative to QoS NSLP. If the PRT option is present, policy relative to QoS NSLP. If the PRT option is present, policy
refreshes can be withheld as long as at least one refresh is sent refreshes can be withheld as long as at least one refresh is sent
before the policy refresh timer expires. A minimal value for PRT before the policy refresh timer expires. A minimal value for PRT
is the NSLP session refresh period R; lower values are assumed to is the NSLP session refresh period R; lower values are assumed to
be R (neither error nor warning should be triggered). This option be R (neither error nor warning should be triggered). This option
is especially useful to combine strong (high overhead) and weak is especially useful to combine strong (high overhead) and weak
(low overhead) authentication certificates as policy data. In such (low overhead) authentication certificates as policy data. In
schemes the weak certificate can support admitting a reservation such schemes the weak certificate can support admitting a
only for a limited time, after which the strong certificate is reservation only for a limited time, after which the strong
required. This approach may reduce the overhead of POLICY_DATA certificate is required. This approach may reduce the overhead of
processing. Strong certificates could be transmitted less POLICY_DATA processing. Strong certificates could be transmitted
frequently, while weak certificates are included in every QoS NSLP less frequently, while weak certificates are included in every QoS
refresh. NSLP refresh.
Policy Source Identification Information (PSII) object: Policy Source Identification Information (PSII) object:
The Policy SII object identifies the neighbor/peer policy-capable The Policy SII object identifies the neighbor/peer policy-capable
QN that constructed the policy object. When policy is enforced at QN that constructed the policy object. When policy is enforced at
border QNEs, peer policy nodes may be several NSLP hops away from border QNEs, peer policy nodes may be several NSLP hops away from
each other and the SII is the basis for the mechanism that allows each other and the SII is the basis for the mechanism that allows
them to recognize each other and communicate safely and directly. them to recognize each other and communicate safely and directly.
As stated above, we assume such an (P)SII to be available from a As stated above, we assume such an (P)SII to be available from a
service from the NTLP. If no PSII object is present, the policy service from GIMPS. If no PSII object is present, the policy data
data is implicitly assumed to have been constructed by the QoS is implicitly assumed to have been constructed by the QoS NSLP HOP
NSLP HOP indicated in the SII (i.e., the neighboring QoS NSLP node indicated in the SII (i.e., the neighboring QoS NSLP node is
is policy-capable). policy-capable).
Integrity object: Integrity object:
The INTEGRITY object option inside POLICY_DATA object creates The INTEGRITY object option inside POLICY_DATA object creates
direct secure communications between non-neighboring policy aware direct secure communications between non-neighboring policy aware
nodes without involving PIN nodes. nodes without involving PIN nodes.
A.7.3 Policy Elements A.7.3 Policy Elements
There are no requirements for all nodes to process this container. There are no requirements for all nodes to process this container.
Policy data is opaque to NSLP, which simply passes it to policy Policy data is opaque to NSLP, which simply passes it to policy
control when required. control when required.
The content of policy elements is opaque to the QoS NSLP layer. Only The content of policy elements is opaque to the QoS NSLP layer. Only
policy peers understand their internal format and NSLP layer simply policy peers understand their internal format and NSLP layer simply
passes it to policy control when required. passes it to policy control when required.
Policy Elements have the following format: Policy Elements have the following format:
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type | | Length | P-Type |
+---------------------------+---------------------------+ +---------------------------+---------------------------+
| | | |
// Policy information (Opaque to QoS NSLP) // // Policy information (Opaque to QoS NSLP) //
| | | |
+-------------------------------------------------------+ +-------------------------------------------------------+
A.7.3.1 Authorization token Policy Element A.7.3.1 Authorization token Policy Element
The AUTHZ_TOKEN policy element contains a list of fields, which The AUTHZ_TOKEN policy element contains a list of fields, which
describe the session, along with other attributes. describe the session, along with other attributes.
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
| Length | P-Type = AUTHZ_TOKEN | | Length | P-Type = AUTHZ_TOKEN |
+-------------+-------------+-------------+-------------+ +-------------+-------------+-------------+-------------+
// Session Authorization Attribute List // // Session Authorization Attribute List //
+-------------------------------------------------------+ +-------------------------------------------------------+
Session Authorization Attribute List: variable length. The session Session Authorization Attribute List: variable length. The
authorization attribute list is a collection of objects which session authorization attribute list is a collection of objects
describes the session and provides other information necessary to which describes the session and provides other information
verify the resource reservation request. See [12] for a details. necessary to verify the resource reservation request. See [11]
Session Authorization Attributes. A session authorization for a details.
Session Authorization Attributes. A session authorization
attribute may contain a variety of information and has both an attribute may contain a variety of information and has both an
attribute type and subtype. The attribute itself MUST be a attribute type and subtype. The attribute itself MUST be a
multiple of 4 octets in length, and any attributes that are not a multiple of 4 octets in length, and any attributes that are not a
multiple of 4 octets long MUST be padded to a 4-octet boundary. multiple of 4 octets long MUST be padded to a 4-octet boundary.
All padding bytes MUST have a value of zero. All padding bytes MUST have a value of zero.
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Length | X-Type |SubType | | Length | X-Type |SubType |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
| Value ... | | Value ... |
+--------+--------+--------+--------+ +--------+--------+--------+--------+
skipping to change at page 65, line 28 skipping to change at page 76, line 4
X-Type: 8 bits X-Type: 8 bits
Session authorization attribute type (X-Type) field is one octet. Session authorization attribute type (X-Type) field is one octet.
IANA acts as a registry for X-Types as described in Section 6. IANA acts as a registry for X-Types as described in Section 6.
Initially, the registry contains the following X-Types: Initially, the registry contains the following X-Types:
1 AUTH_ENT_ID: The unique identifier of the entity which 1 AUTH_ENT_ID: The unique identifier of the entity which
authorized the session. authorized the session.
2 SESSION_ID: Unique identifier for this session. 2 SESSION_ID: Unique identifier for this session.
3 SOURCE_ADDR: Address specification for the session originator. 3 SOURCE_ADDR: Address specification for the session originator.
4 DEST_ADDR: Address specification for the session end-point. 4 DEST_ADDR: Address specification for the session end-point.
5 START_TIME: The starting time for the session. 5 START_TIME: The starting time for the session.
6 END_TIME: The end time for the session. 6 END_TIME: The end time for the session.
7 RESOURCES: The resources which the user is authorized to 7 RESOURCES: The resources which the user is authorized to
request. request.
8 AUTHENTICATION_DATA: Authentication data of the session 8 AUTHENTICATION_DATA: Authentication data of the session
authorization policy element. authorization policy element.
SubType: 8 bits SubType: 8 bits
Session authorization attribute sub-type is one octet in length. Session authorization attribute sub-type is one octet in length.
The value of the SubType depends on the X-Type. The value of the SubType depends on the X-Type.
Value: variable length Value: variable length
The attribute specific information is defined in [12]. The attribute specific information is defined in [11].
A.7.3.2 OSP Token Policy Element A.7.3.2 OSP Token Policy Element
To be completed. To be completed.
A.7.3.3 User Identity Policy element A.7.3.3 User Identity Policy element
To be completed. To be completed.
A.8 QSPEC Class A.8 QSPEC Class
QSPEC class = 8. QSPEC class = 8.
QSPEC object: Class = 8, C-Type = (QoS model ID) QSPEC object: Class = 8, C-Type = (QoS model ID)
This object contains the QSPEC (QoS specification) information. This object contains the QSPEC (QoS specification) information.
Its content has a variable length and it is QoS model specific. Its content has a variable length and it is QoS model specific.
Such a QoS model can be a standardized one, a private one, or a Such a QoS model can be a standardized one, a private one, or a
well-known one. The C-Type contains the QoS model ID that well-known one. The C-Type contains the QoS model ID that
identifies the used QSPEC. identifies the used QSPEC.
The contents and encoding rules for this object are specified The contents and encoding rules for this object are specified
in other documents, prepared by QoS model designers. in other documents, prepared by QoS model designers.
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP-11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. 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 The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
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 Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 470 change blocks. 
1416 lines changed or deleted 1837 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/