< draft-ietf-nsis-qos-nslp-07.txt   draft-ietf-nsis-qos-nslp-08.txt >
Next Steps in Signalling J. Manner (ed.) Next Steps in Signalling J. Manner (ed.)
Internet-Draft University of Helsinki Internet-Draft University of Helsinki
Expires: January, 2006 G. Karagiannis Expires: April, 2006 G. Karagiannis
University of Twente/Ericsson University of Twente/Ericsson
A. McDonald A. McDonald
Siemens/Roke Manor Research Siemens/Roke Manor Research
S. Van den Bosch S. Van den Bosch
Alcatel Alcatel
July 2005 October 2005
NSLP for Quality-of-Service signalling NSLP for Quality-of-Service signalling
<draft-ietf-nsis-qos-nslp-07.txt> <draft-ietf-nsis-qos-nslp-08.txt>
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 The list of current Internet-Drafts can be accessed at
http://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 in January, 2006. This Internet-Draft will expire in April, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
This draft describes an NSIS Signalling Layer Protocol (NSLP) for This draft describes an NSIS Signalling Layer Protocol (NSLP) for
signalling QoS reservations in the Internet. It is in accordance with signalling QoS reservations in the Internet. It is in accordance with
the framework and requirements developed in NSIS. Together with the framework and requirements developed in NSIS. Together with
GIMPS, it provides functionality similar to RSVP and extends it. The GIST, it provides functionality similar to RSVP and extends it. The
QoS NSLP is independent of the underlying QoS specification or QoS NSLP is independent of the underlying QoS specification or
architecture and provides support for different reservation models. architecture and provides support for different reservation models.
It is simplified by the elimination of support for multicast flows. It is simplified by the elimination of support for multicast flows.
This draft explains the overall protocol approach, design decisions This draft explains the overall protocol approach, design decisions
made and provides examples. It specifies object and message formats made and provides examples. It specifies object and message formats
and processing rules. and processing rules.
Table of Contents Table of Contents
1 Introduction ................................................. 4 1 Introduction ................................................. 4
1.1 Scope and background ....................................... 4 1.1 Scope and background ....................................... 4
1.2 Model of operation ......................................... 5 1.2 Model of operation ......................................... 5
2 Terminology .................................................. 7 2 Terminology .................................................. 7
3 Protocol Overview ............................................ 8 3 Protocol Overview ............................................ 9
3.1 Overall approach ........................................... 8 3.1 Overall approach ........................................... 9
3.1.1 GIMPS Interactions ....................................... 8 3.1.1 GIST Interactions ........................................ 9
3.1.2 Protocol messages ........................................ 9 3.1.2 Protocol messages ........................................ 9
3.1.3 QoS Models and QoS Specifications ........................ 10 3.1.3 QoS Models and QoS Specifications ........................ 10
3.1.4 Policy control ........................................... 11 3.1.4 Policy control ........................................... 11
3.2 Design decisions ........................................... 12 3.2 Design decisions ........................................... 13
3.2.1 Soft-state ............................................... 12 3.2.1 Soft-state ............................................... 13
3.2.2 Sender-receiver initiation ............................... 13 3.2.2 Sender-receiver initiation ............................... 13
3.2.3 Message sequencing ....................................... 13 3.2.3 Message sequencing ....................................... 13
3.2.4 Explicit state installation confirmation and responses ... 13 3.2.4 Explicit state installation confirmation and responses ... 14
3.2.5 Reduced refresh .......................................... 14 3.2.5 Reduced refresh .......................................... 14
3.2.6 Message scoping .......................................... 14 3.2.6 Message scoping .......................................... 14
3.2.7 Session binding .......................................... 14 3.2.7 Session binding .......................................... 15
3.2.8 Layering ................................................. 15 3.2.8 Layering ................................................. 15
3.2.8.1 Local QoS models ....................................... 15 3.2.8.1 Local QoS models ....................................... 15
3.2.8.2 Local control plane properties ......................... 15 3.2.8.2 Local control plane properties ......................... 16
3.2.8.3 Aggregate reservations ................................. 16 3.2.8.3 Aggregate reservations ................................. 16
3.2.9 Priority ................................................. 16 3.2.9 Priority ................................................. 17
3.2.10 Rerouting ............................................... 17 3.2.10 Rerouting ............................................... 17
4 Examples of QoS NSLP Operation ............................... 18 4 Examples of QoS NSLP Operation ............................... 20
4.1 Basic sender-initiated reservation ......................... 18 4.1 Basic sender-initiated reservation ......................... 20
4.2 Sending a Query ............................................ 20 4.2 Sending a Query ............................................ 22
4.3 Basic receiver-initiated reservation ....................... 20 4.3 Basic receiver-initiated reservation ....................... 22
4.4 Bidirectional Reservations ................................. 22 4.4 Bidirectional Reservations ................................. 24
4.5 Use of Local QoS Models .................................... 23 4.5 Use of Local QoS Models .................................... 25
4.6 Aggregate Reservations ..................................... 24 4.6 Aggregate Reservations ..................................... 26
4.7 Reduced State or Stateless Interior Nodes .................. 25 4.7 Reduced State or Stateless Interior Nodes .................. 27
4.8 Re-routing scenario ........................................ 27 4.8 Re-routing scenario ........................................ 29
4.9 Authorization Model Examples ............................... 28 4.9 Authorization Model Examples ............................... 30
4.9.1 Authorization for the two party approach ................. 28 4.9.1 Authorization for the two party approach ................. 31
4.9.2 Token based three party approach ......................... 29 4.9.2 Token based three party approach ......................... 31
4.9.3 Generic three party approach ............................. 30 4.9.3 Generic three party approach ............................. 32
5 QoS NSLP Functional specification ............................ 30 5 QoS NSLP Functional specification ............................ 33
5.1 QoS NSLP Message and Object Formats ........................ 30 5.1 QoS NSLP Message and Object Formats ........................ 33
5.1.1 Common header ............................................ 31 5.1.1 Common header ............................................ 33
5.1.2 Message formats .......................................... 31 5.1.2 Message formats .......................................... 34
5.1.2.1 RESERVE ................................................ 31 5.1.2.1 RESERVE ................................................ 34
5.1.2.2 QUERY .................................................. 33 5.1.2.2 QUERY .................................................. 35
5.1.2.3 RESPONSE ............................................... 34 5.1.2.3 RESPONSE ............................................... 36
5.1.2.4 NOTIFY ................................................. 34 5.1.2.4 NOTIFY ................................................. 37
5.1.3 Object Formats ........................................... 35 5.1.3 Object Formats ........................................... 37
5.1.3.1 Request Identification Information (RII) ............... 35 5.1.3.1 Request Identification Information (RII) ............... 38
5.1.3.2 Reservation Sequence Number (RSN) ...................... 36 5.1.3.2 Reservation Sequence Number (RSN) ...................... 38
5.1.3.3 REFRESH_PERIOD ......................................... 36 5.1.3.3 REFRESH_PERIOD ......................................... 39
5.1.3.4 BOUND_SESSION_ID ....................................... 36 5.1.3.4 BOUND_SESSION_ID ....................................... 39
5.1.3.5 PACKET_CLASSIFIER ...................................... 37 5.1.3.5 PACKET_CLASSIFIER ...................................... 39
5.1.3.6 ERROR_SPEC ............................................. 38 5.1.3.6 INFO_SPEC .............................................. 41
5.1.3.7 QSPEC .................................................. 40 5.1.3.7 QSPEC .................................................. 43
5.1.3.8 POLICY_DATA ............................................ 40 5.1.3.8 POLICY_DATA ............................................ 43
5.2 General Processing Rules ................................... 41 5.2 General Processing Rules ................................... 44
5.2.1 State Manipulation ....................................... 41 5.2.1 State Manipulation ....................................... 44
5.2.2 Message Forwarding ....................................... 42 5.2.2 Message Forwarding ....................................... 45
5.2.3 Standard Message Processing Rules ........................ 42 5.2.3 Standard Message Processing Rules ........................ 45
5.3 Object Processing .......................................... 42 5.2.4 Retransmissions .......................................... 45
5.3.1 Reservation Sequence Number (RSN) ........................ 42 5.3 Object Processing .......................................... 46
5.3.2 Request Identification Information (RII) ................. 43 5.3.1 Reservation Sequence Number (RSN) ........................ 46
5.3.3 BOUND_SESSION_ID ......................................... 44 5.3.2 Request Identification Information (RII) ................. 46
5.3.4 REFRESH_PERIOD ........................................... 44 5.3.3 BOUND_SESSION_ID ......................................... 47
5.3.5 ERROR_SPEC ............................................... 46 5.3.4 REFRESH_PERIOD ........................................... 48
5.3.6 QSPEC .................................................... 46 5.3.5 INFO_SPEC ................................................ 50
5.4 Message Processing Rules ................................... 46 5.3.6 QSPEC .................................................... 50
5.4.1 RESERVE Messages ......................................... 47 5.4 Message Processing Rules ................................... 50
5.4.2 QUERY Messages ........................................... 50 5.4.1 RESERVE Messages ......................................... 51
5.4.3 RESPONSE Messages ........................................ 51 5.4.2 QUERY Messages ........................................... 54
5.4.4 NOTIFY Messages .......................................... 51 5.4.3 RESPONSE Messages ........................................ 55
6 IANA considerations .......................................... 52 5.4.4 NOTIFY Messages .......................................... 56
7 QoS use of GIMPS service interface ........................... 52 6 IANA considerations .......................................... 56
7.1 Example sender-initiated reservation ....................... 53 7 QoS use of GIST service interface ............................ 57
7.2 Session identification ..................................... 54 7.1 Example sender-initiated reservation ....................... 57
7.3 Support for bypassing intermediate nodes ................... 54 7.2 Session identification ..................................... 58
7.4 Support for peer change identification ..................... 54 7.3 Support for bypassing intermediate nodes ................... 58
7.5 Support for stateless operation ............................ 55 7.4 Support for peer change identification ..................... 59
7.6 Last node detection ........................................ 55 7.5 Support for stateless operation ............................ 59
7.7 Re-routing detection ....................................... 56 7.6 Last node detection ........................................ 59
7.8 Priority of signalling messages ............................ 56 7.7 Re-routing detection ....................................... 60
7.9 Knowledge of intermediate QoS NSLP unaware nodes ........... 56 7.8 Priority of signalling messages ............................ 60
7.10 NSLP Data Size ............................................ 56 7.9 Knowledge of intermediate QoS NSLP unaware nodes ........... 60
7.11 Notification of GIMPS 'D' flag value ...................... 56 7.10 NSLP Data Size ............................................ 61
7.12 NAT Traversal ............................................. 57 7.11 Notification of GIST 'D' flag value ....................... 61
8 Assumptions on the QoS Model ................................. 57 7.12 NAT Traversal ............................................. 61
8.1 Resource sharing ........................................... 57 8 Assumptions on the QoS Model ................................. 61
8.2 Reserve/commit support ..................................... 57 8.1 Resource sharing ........................................... 61
9 Security Considerations ...................................... 57 8.2 Reserve/commit support ..................................... 62
9.1 Introduction and Threat Overview ........................... 57 9 Security Considerations ...................................... 62
9.2 Trust Model ................................................ 58 9.1 Introduction and Threat Overview ........................... 62
9.3 Computing the authorization decision ....................... 60 9.2 Trust Model ................................................ 63
10 Open Issues ................................................. 61 9.3 Computing the authorization decision ....................... 65
11 Acknowledgements ............................................ 61 10 Open Issues ................................................. 65
12 Contributors ................................................ 61 11 Acknowledgements ............................................ 65
13 References .................................................. 61 12 Contributors ................................................ 66
13.1 Normative References ...................................... 61 13 References .................................................. 66
13.2 Informative References .................................... 62 13.1 Normative References ...................................... 66
13.2 Informative References .................................... 66
1. Introduction 1. Introduction
1.1. Scope and background 1.1. Scope and background
This document defines a Quality of Service (QoS) NSIS Signalling This document defines a Quality of Service (QoS) NSIS Signalling
Layer Protocol (NSLP), henceforth referred to as the "QoS NSLP". This Layer 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
RFC 3726 [RFC3726]. This QoS NSLP is part of a larger suite of RFC 3726 [RFC3726]. This QoS NSLP is part of a larger suite of
signalling protocols, whose structure is outlined in the NSIS signalling protocols, whose structure is outlined in the NSIS
framework [RFC4080]; this defines a common NSIS Transport Layer framework [RFC4080]; this defines a common NSIS Transport Layer
Protocol (NTLP) which QoS NSLP uses to carry out many aspects of Protocol (NTLP) which QoS NSLP uses to carry out many aspects of
signalling message delivery. A specification of the NTLP, GIMPS [I- signalling message delivery. A specification of the NTLP, GIST [I-
D.ietf-nsis-ntlp] is done in another document. D.ietf-nsis-ntlp] is done in another document.
The design of QoS NSLP is conceptually similar to RSVP, RFC 2205 The design of QoS NSLP is conceptually similar to RSVP, RFC 2205
[RFC2205], and uses soft-state peer-to-peer refresh messages as the [RFC2205], and uses soft-state peer-to-peer refresh messages as the
primary state management mechanism (i.e. state installation/refresh primary state management mechanism (i.e. state installation/refresh
is performed between pairs of adjacent NSLP nodes, rather than in an is performed between pairs of adjacent NSLP nodes, rather than in an
end-to-end fashion along the complete signalling path). Although end-to-end fashion along the complete signalling path). Although
there is no backwards compatibility at the level of protocol there is no backwards compatibility at the level of protocol
messages, interworking with RSVP at a signalling application gateway messages, interworking with RSVP at a signalling application gateway
would be possible in some circumstances. QoS NSLP extends the set of would be possible in some circumstances. QoS NSLP extends the set of
skipping to change at page 5, line 6 skipping to change at page 5, line 7
information on resources available, resources required, traffic information on resources available, resources required, traffic
descriptions and other information required by the RMF. descriptions and other information required by the RMF.
This document is structured as follows. The overall approach to This document is structured as follows. The overall approach to
protocol design is outlined in Section 3.1. The operation and use of protocol design is outlined in Section 3.1. The operation and use of
QoS NSLP is then clarified by means of a number of examples in QoS NSLP is then clarified by means of a number of examples in
Section 4. These sections should be read by readers interested in the Section 4. These sections should be read by readers interested in the
protocol capabilities. The functional specification Section 5 protocol capabilities. The functional specification Section 5
contains more detailed object and message formats and processing contains more detailed object and message formats and processing
rules and should be the basis for implementers. The subsequent rules and should be the basis for implementers. The subsequent
sections describe extensibility (IANA), requirements on GIMPS API and sections describe extensibility (IANA), requirements on GIST API and
security considerations. security considerations.
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. NSLP and associated provisioning mechanisms within a single node.
The model is shown in Figure 1. The model is shown in Figure 1.
+---------------+ +---------------+
| Local | | Local |
skipping to change at page 6, line 25 skipping to change at page 6, line 27
o The request from a local application includes not only user o The request from a local application includes not only user
applications (e.g. multimedia applications) but also network applications (e.g. multimedia applications) but also network
management (e.g. initiating a tunnel to handle an aggregate, or management (e.g. initiating a tunnel to handle an aggregate, or
interworking with some other reservation protocol - such as RSVP) interworking with some other reservation protocol - such as RSVP)
and the policy control module (e.g. for explicit teardown and the policy control module (e.g. for explicit teardown
triggered by AAA). In this sense, the model does not distinguish triggered by AAA). In this sense, the model does not distinguish
between hosts and routers. between hosts and routers.
o Incoming messages are captured during input packet processing o Incoming messages are captured during input packet processing
and handled by GIMPS. Only messages related to QoS are passed to and handled by GIST. Only messages related to QoS are passed to
the QoS NSLP. GIMPS may also generate triggers to the QoS NSLP the QoS NSLP. GIST may also generate triggers to the QoS NSLP
(e.g. indications that a route change has occurred). (e.g. indications that a route change has occurred).
The QoS request is handled by a local 'resource management' The QoS 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. It also handles policy-specific aspects configure the resource. It also handles policy-specific aspects
of QoS signaling. of QoS signaling.
o The grant processing involves two local decision modules, o The grant processing involves two local decision modules,
'policy control' and 'admission control'. Policy control 'policy control' and 'admission control'. Policy control
determines whether the user has administrative permission to make determines whether the user has administrative permission to make
skipping to change at page 7, line 25 skipping to change at page 7, line 26
QoS NSLP is independent of the QoS parameters (e.g. IntServ service QoS NSLP is independent of the QoS parameters (e.g. IntServ service
elements). These are captured in a QoS Model and interpreted only by elements). These are captured in a QoS Model and interpreted only by
the resource management and associated functions, and are opaque to the resource management and associated functions, and are opaque to
the QoS NSLP itself. QoS Models are discussed further in Section the QoS NSLP itself. QoS Models are discussed further in Section
3.1.3. 3.1.3.
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 been configured. The QoS NSLP may generate an acknowledgement
message in one direction, and may forward the resource request in the message in one direction, and may forward the resource request in the
other. Message routing is (by default) carried out by the GIMPS other. Message routing is (by default) carried out by the GIST
module. Note that while Figure 1 shows a unidirectional data flow, module. Note that while Figure 1 shows a unidirectional data flow,
the signalling messages can pass in both directions through the node, the signalling messages can pass in both directions through the node,
depending on the particular message and orientation of the depending on the particular message and orientation of the
reservation. reservation.
2. Terminology 2. Terminology
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.
The terminology defined by GIMPS [I-D.ietf-nsis-ntlp] applies to this The terminology defined by GIST [I-D.ietf-nsis-ntlp] applies to this
draft. draft.
In addition, the following terms are used: In addition, 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 QNI: the first node in the sequence of QNEs that issues a
reservation request for a session. reservation 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 for a session. reservation request for a session.
Session: A "session" is essentially a signaling application
concept, since it is only used in non-trivial state management
actions that are application specific. A session defines an
association between a QNI and QNR related to a data flow. All QNEs
on the path, including the QNI and QNR, use the same identifier to
refer to the state stored for the association. The same QNI and
QNR may have more than one session active at any one time. The
session identifier should be (probabilistically) globally unique,
and it should not be modified end-to-end.
Session Identification (SESSION_ID, SID): This is a
cryptographically random and (probabilistically) globally unique
identifier of the application layer session that associated with a
certain flow. For a given flow, different signaling applications
may or may not use the same session identifier. Often there will
only be one flow for a given session, but in mobility/multihoming
scenarios there may be more than one and they may be differently
routed [RFC4080].
Source or message source: The one of two adjacent NSLP peers that Source or message source: The one of two adjacent NSLP peers that
is sending a signalling message (maybe the upstream or the is sending a signalling message (maybe the upstream or the
downstream peer). NB: this is not necessarily the QNI. downstream peer). NB: this is not necessarily the QNI.
QoS NSLP operation state: state used/kept by QoS NSLP processing QoS NSLP operation state: state used/kept by QoS NSLP processing
to handle messaging aspects. to handle messaging aspects.
QoS reservation state: state used/kept by Resource Management QoS reservation state: state used/kept by Resource Management
Function to describe reserved resources for a session. Function to describe reserved resources for a session.
skipping to change at page 8, line 38 skipping to change at page 9, line 9
Flow Flow
Figure 2: Components of the QoS NSLP architecture. Figure 2: Components of the QoS NSLP architecture.
A glossary of terms and abbreviations used in this document can be A glossary of terms and abbreviations used in this document can be
found in Appendix A. found in Appendix A.
3. Protocol Overview 3. Protocol Overview
3.1. Overall approach 3.1. Overall approach
3.1.1. GIMPS Interactions 3.1.1. GIST Interactions
The QoS NSLP uses GIMPS for delivery of all its messages. Messages The QoS NSLP uses GIST for delivery of all its messages. Messages
are normally passed from the NSLP to GIMPS via an API (defined in are normally passed from the NSLP to GIST via an API (defined in
Appendix D of [I-D.ietf-nsis-ntlp]), which also specifies additional Appendix D of [I-D.ietf-nsis-ntlp]), which also specifies additional
information, including an identifier for the signalling application information, including an identifier for the signalling application
(e.g. 'QoS NSLP'), the flow/session identifier, and an indication of (e.g. 'QoS NSLP'), the flow/session identifier, and an indication of
the intended direction - towards data sender or receiver. On the intended direction - towards data sender or receiver. On
reception, GIMPS provides the same information to the QoS NSLP. In reception, GIST provides the same information to the QoS NSLP. In
addition to the NSLP message data itself, other meta-data (e.g. addition to the NSLP message data itself, other meta-data (e.g.
session identifier, flow routing information) can be transferred session identifier, flow routing information) can be transferred
across this interface. across this interface.
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 GIMPS. basic NAT traversal service is provided by GIST.
3.1.2. Protocol messages 3.1.2. Protocol messages
The QoS NSLP uses four message types: The QoS NSLP uses four message types:
RESERVE: The RESERVE message is the only message that manipulates RESERVE: The RESERVE message is the only message that manipulates
QoS NSLP reservation state. It is used to create, refresh, modify QoS NSLP reservation state. It is used to create, refresh, modify
and remove such state. The RESERVE message is idempotent; the and remove such state. The RESERVE message is idempotent; the
resultant effect is the same whether a message is received once or resultant effect is the same whether a message is received once or
many times. many times.
skipping to change at page 10, line 21 skipping to change at page 10, line 42
the reservation of resources. the reservation of resources.
Object formats are defined in Section 5.1.3. Object processing rules Object formats are defined in Section 5.1.3. Object processing rules
are defined in Section 5.3. are defined in Section 5.3.
3.1.3. QoS Models and QoS Specifications 3.1.3. QoS Models and QoS Specifications
QoS NSLP provides flexibility over the exact patterns of signalling QoS NSLP provides flexibility over the exact patterns of signalling
messages that are exchanged. The decoupling of QoS NSLP and QSPEC messages that are exchanged. The decoupling of QoS NSLP and QSPEC
allows the QoS NSLP to be ignorant about the ways in which traffic, allows the QoS NSLP to be ignorant about the ways in which traffic,
resources, etc are described, and it can treat the QSPEC as an opaque resources, etc. are described, and it can treat the QSPEC as an
object. opaque object.
The QSPEC fulfills a similar purpose to the TSpec, RSpec and AdSpec The QSPEC fulfills a similar purpose to the TSpec, RSpec and AdSpec
objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC objects used with RSVP and specified in RFC 2205 [RFC2205] and RFC
2210 [RFC2210]. At each QNE, its content is interpreted by the 2210 [RFC2210]. At each QNE, its content is interpreted by the
Resource Management Function and the Policy Control Function for the Resource Management Function and the Policy Control Function for the
purposes of policy control and traffic control (including admission purposes of policy control and traffic control (including admission
control and configuration of the packet classifier and scheduler). control and configuration of the packet classifier and scheduler).
QoS NSLP does not mandate any particular behaviour for the RMF, QoS NSLP does not mandate any particular behaviour for the RMF,
instead demanding interoperability at the signalling protocol whilst instead demanding interoperability at the signalling protocol whilst
skipping to change at page 11, line 7 skipping to change at page 11, line 29
QoS Models may be local (private to one network), implementation/ QoS Models may be local (private to one network), implementation/
vendor specific, or global (implementable by different networks and vendor specific, or global (implementable by different networks and
vendors). The authors are currently aware of three efforts related vendors). The authors are currently aware of three efforts related
to QoS Model specification: IntServ Controlled Load [I-D.kappler- to QoS Model specification: IntServ Controlled Load [I-D.kappler-
nsis-qosmodel-controlledload], ITU Y.1541 [I-D.ash-nsis-y1541-qosm], nsis-qosmodel-controlledload], ITU Y.1541 [I-D.ash-nsis-y1541-qosm],
and Resource Management for DiffServ (RMD) [I-D.ietf-nsis-rmd]. and Resource Management for DiffServ (RMD) [I-D.ietf-nsis-rmd].
The definition of a QoS model may also have implications on how local The definition of a QoS model may also have implications on how local
behaviour should be implemented in the areas where the QoS NSLP gives behaviour should be implemented in the areas where the QoS NSLP gives
freedom to implementers. For example, it may be useful to identify freedom to implementers. For example, it may be useful to identify
recommended behaviour for how a RESERVE message that is forwarded recommended behaviour for how a RESERVE message that is forwarded
relates to that received, or when additional signalling sessions relates to that received, or when additional signalling sessions
should be started based on existing sessions, such as required for should be started based on existing sessions, such as required for
aggregate reservations. In some cases, suggestions may be made on aggregate reservations. In some cases, suggestions may be made on
whether state that may optionally be retained should be held in whether state that may optionally be retained should be held in
particular scenarios. particular scenarios. Moreover, a QoS model may specify reservation
pre-emption, e.g., an incoming resource request may cause removal of
an earlier reservation.
An ongoing effort attempts to specify a QSPEC template [I-D.ietf- An ongoing effort attempts to specify a QSPEC template [I-D.ietf-
nsis-qspec]. The QSPEC template contains object formats for nsis-qspec]. The QSPEC template contains object formats for
generally useful elements of the QoS description, which is designed generally useful elements of the QoS description, which is designed
to ensure interoperability when using the basic set of objects. to ensure interoperability when using the basic set of objects.
3.1.4. Policy control 3.1.4. Policy control
Getting access to network resources typically involves some kind of Getting access to network resources typically involves some kind of
policy control. One example of this is authorisation of the resource policy control. One example of this is authorisation of the resource
skipping to change at page 12, line 8 skipping to change at page 12, line 32
a two-party model between neighbouring QNEs. The actual policy a two-party model between neighbouring QNEs. The actual policy
decision may depend on the involvement of a third entity (the policy decision may depend on the involvement of a third entity (the policy
decision point, PDP), but this happens outside of the QoS NSLP decision point, PDP), but this happens outside of the QoS NSLP
protocol by means of existing policy infrastructure (COPS, Diameter, protocol by means of existing policy infrastructure (COPS, Diameter,
etc). The policy control model for the entire end-to-end chain of etc). The policy control model for the entire end-to-end chain of
QNEs is therefore one of transitivity, where each of the QNEs QNEs is therefore one of transitivity, where each of the QNEs
exchanges policy information with its QoS NSLP policy peer. exchanges policy information with its QoS NSLP policy peer.
The input to policy control is referred to as "Policy data", some of The input to policy control is referred to as "Policy data", some of
which QoS NSLP carries in the POLICY_DATA object while other which QoS NSLP carries in the POLICY_DATA object while other
information is provided across the GIMPS API. Policy data itself is information is provided across the GIST API. Policy data itself is
opaque to the QoS NSLP, which simply passes it to policy control when opaque to the QoS NSLP, which simply passes it to policy control when
required. The policy data is independent from the QoS model in use. required. The policy data is independent from the QoS model in use.
[FIXME: what is the final verdict on these options?] Two options are currently considered for support by QoS NSLP policy
control:
Three options have currently been suggested for support by QoS NSLP
policy control:
a. Reuse of GIMPS channel security mechanisms a. Reuse of GIST channel security mechanisms
b. Carrying (authorisation) tokens b. Carrying (authorisation) tokens
c. Encapsulating EAP exchanges in the QoS NSLP protocol The fist option is preferred as it relies on existing security
measures. This can be controlled through the GIST API. The second
Option a is the preferred option. Option b is also supported in this option is supported through [FIXME: FILL IN HANNES' WORK]
version of the specification. Option c is not considered at this
moment in time, but could potentially be added at a later date
through the use of extension mechanisms already available in the
protocol.
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 administrative domains. In some concentrate on border nodes between administrative domains. In some
cases policy objects transmitted across the domain traverse an cases policy objects transmitted across the domain traverse an
intermediate Policy Ignorant Node (PIN) that is allowed to process intermediate Policy Ignorant Node (PIN) that is allowed to process
QoS NSLP message but does not handle policy information. The policy QoS NSLP message but does not handle policy information. The policy
peering between ingress and egress edge of a domain therefore relies peering between ingress and egress edge of a domain therefore relies
on the internal chain of trust between the nodes in the domain. If on the internal chain of trust between the nodes in the domain. If
this is not acceptable, a separate signalling session can be set up this is not acceptable, a separate signalling session can be set up
between the edge node in order to exchange policy information. This between the edge node in order to exchange policy information. This
skipping to change at page 13, line 10 skipping to change at page 13, line 24
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 milliseconds indicating how long the state that contains a value in milliseconds indicating how long the state that
is signalled for remains valid. Maintaining the reservation beyond is signalled for remains valid. Maintaining the reservation beyond
this lifetime can be done by sending periodically a RESERVE message. this lifetime can be done by sending periodically a RESERVE message.
3.2.2. Sender-receiver initiation 3.2.2. Sender-receiver initiation
QoS NSLP supports both sender-initiated and receiver-initiated QoS NSLP supports both sender-initiated and receiver-initiated
reservations. For a sender-initiated reservation, RESERVE messages reservations. For a sender-initiated reservation, RESERVE messages
travel in the same direction as the dataflow that is being signalled travel in the same direction as the dataflow that is being signalled
for (the QNI is at the side of the source of the dataflow). For a for (the QNI is at the side of the source of the dataflow).
receiver-initiated reservation, RESERVE messages travel in the
For a receiver-initiated reservation, RESERVE messages travel in the
opposite direction (the QNI is at the side of the receiver of the opposite direction (the QNI is at the side of the receiver of the
data flow). Before sending the RESERVE, the sender of the data first data flow). Before sending the RESERVE, the sender of the data first
sends a QUERY message that creates the required GIMPS path state. The sends a QUERY message with the R-bit set that creates the required
QUERY message is needed due to the asymmetric nature of IP routing. GIST path state. The QUERY message is needed due to the asymmetric
nature of IP routing.
Note: these definitions follow the definitions in Section 3.3.1. of
RFC 4080 [RFC4080]. The question is, which node is in charge of
requesting and maintaining the resouce reservation. In a receiver-
initiated reservation, even though the sender sends the initial
QUERY, the receiver is still in charge of making the actual resource
request, and maintaining the reservation.
3.2.3. Message sequencing 3.2.3. 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, QoS NSLP supports detection of will be stored at a QNE. Therefore, QoS NSLP supports detection of
RESERVE message re-ordering or duplication with Reservation Sequence RESERVE message re-ordering or duplication with Reservation Sequence
Number (RSN). Number (RSN).
skipping to change at page 14, line 41 skipping to change at page 15, line 12
This specification does not support an explicit notion of a region This specification does not support an explicit notion of a region
scope or "to a mobility-related path branch/merge point". If needed, scope or "to a mobility-related path branch/merge point". If needed,
this can be easily proposed as an extension later on,e.g. based on this can be easily proposed as an extension later on,e.g. based on
LRSVP [I-D.manner-lrsvp]. LRSVP [I-D.manner-lrsvp].
3.2.7. Session binding 3.2.7. Session binding
Session binding is defined as the enforcement of a relation between Session binding is defined as the enforcement of a relation between
different QoS NSLP sessions (i.e. signalling flows with different different QoS NSLP sessions (i.e. signalling flows with different
SESSION_ID (SID) as defined in GIMPS [I-D.ietf-nsis-ntlp]). SESSION_ID (SID) as defined in GIST [I-D.ietf-nsis-ntlp]).
Session binding indicates a (possibly asymmetric) dependency relation Session binding indicates a (possibly asymmetric) dependency relation
between two or more sessions by including a BOUND_SESSION_ID object. between two or more sessions by including a BOUND_SESSION_ID object.
A session with SID_A (the binding session) can express its relation A session with SID_A (the binding session) can express its relation
to another session with SID_B (the bound session) by including a to another session with SID_B (the bound session) by including a
BOUND_SESSION_ID object containing SID_B in its messages. The BOUND_SESSION_ID object containing SID_B in its messages. The
dependency is asymmetric if the session with SID_B does not carry a dependency is asymmetric if the session with SID_B does not carry a
BOUND_SESSION_ID object containing SID_A. BOUND_SESSION_ID object containing SID_A.
The concept of session binding is used to indicate the dependency The concept of session binding is used to indicate the dependency
skipping to change at page 15, line 13 skipping to change at page 15, line 37
session binding is purely informative in nature and does not session binding is purely informative in nature and does not
automatically trigger any action in a QNE. However, a QNE may use automatically trigger any action in a QNE. However, a QNE may use
the information for local resource optimisation or to tear down the information for local resource optimisation or to tear down
reservations that are no longer useful. reservations that are no longer useful.
3.2.8. Layering 3.2.8. Layering
QoS NSLP supports layered reservations. Layered reservations may 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. GIMPS unreliable transfer mode instead plane characteristics (e.g. GIST unreliable transfer mode instead of
of reliable transfer mode). They may also occur when several per- reliable transfer mode). They may also occur when several per-flow
flow reservations are locally combined into an aggregate reservation. reservations are locally combined into an aggregate reservation.
3.2.8.1. Local QoS models 3.2.8.1. Local QoS models
A domain may have local policies regarding QoS model implementation, A domain may have local policies regarding QoS model implementation,
i.e. it may map incoming traffic to its own locally defined QoS i.e. it may map incoming traffic to its own locally defined QoS
models. QoS NSLP supports this by allowing QSPEC objects to be models. QoS NSLP supports this by allowing QSPEC objects to be
stacked. stacked.
When a domain wants to apply a certain QoS model to an incoming per- When a domain wants to apply a certain QoS model to an incoming per-
flow reservation request, each edge of the domain is configured to flow reservation request, each edge of the domain is configured to
map the incoming QSPEC object to a local QSPEC object and push that map the incoming QSPEC object to a local QSPEC object and push that
object onto the stack of QSPEC objects (typically immediately 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., before the first
is found in the message). QNEs inside the domain look at the top of QSPEC that is found in the message). QNEs inside the domain look at
the QSPEC object stack to determine which QoS model to apply for the the top of the QSPEC object stack to determine which QoS model to
reservation. apply for the 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 any). By mandating the locally valid object to be on top of the
stack we value ease of processing over ease of message construction. stack we value ease of processing over ease of message construction.
Note that the use of multiple QSPEC objects may require complex Note that the use of multiple QSPEC objects may require complex
processing. A QNE while processing the QSPEC on the top of the stack processing. A QNE while processing the QSPEC on the top of the stack
may also need to process inner QSPEC objects. For example, a domain may also need to process inner QSPEC objects. For example, a domain
may want to hide its existence from the end hosts, and for doing that may want to hide its existence from the end hosts, and for doing that
may need to process objects and fields in the inner QSPEC used may need to process objects and fields in the inner QSPEC used
originally by the end hosts. originally by the end hosts.
3.2.8.2. Local control plane properties 3.2.8.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 GIMPS-NSLP API and by the Common parameters that are sent over GIST-NSLP API and by the Common Control
Control Information. A domain may have a policy to implement local Information. A domain may have a policy to implement local control
control plane behaviour. It may, for instance, elect to use an plane behaviour. It may, for instance, elect to use an unreliable
unreliable transport locally in the domain while still keeping end- transport locally in the domain while still keeping end-to-end
to-end reliability intact. 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.
Intermediate node bypass is achieved with GIMPS. The local session Intermediate node bypass is achieved with GIST. The local session
and the end-to-end session are bound at the egress QNE by means of and the end-to-end session are bound at the egress QNE by means of
the BOUND_SESSION_ID object. the BOUND_SESSION_ID object.
3.2.8.3. Aggregate reservations 3.2.8.3. Aggregate reservations
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. The QoS NSLP, therefore, provides aggregation signalling messages. The QoS NSLP, therefore, provides aggregation
facilities similar to RFC 3175 [RFC3175]. However, the aggregation facilities similar to RFC 3175 [RFC3175]. However, the aggregation
scenarios supported are wider than that proposed there. Note that scenarios supported are wider than that proposed there. Note that
QoS NSLP does not specify how reservations need to be combined in an QoS NSLP does not specify how reservations need to be combined in an
aggregate or how end-to-end properties need to be computed but only aggregate or how end-to-end properties need to be computed but only
provides signalling support for it. provides signalling support for it.
The essential difference with the layering approaches described in The essential difference with the layering approaches described in
Section 3.2.8.1 and Section 3.2.8.2 is that the aggregate reservation Section 3.2.8.1 and Section 3.2.8.2 is that the aggregate reservation
needs a FlowID that describes all traffic carried in the aggregate needs a FlowID, ie., MRI, that describes all traffic carried in the
(e.g. a DSCP in case of IntServ over DiffServ). The need for a aggregate (e.g. a DSCP in case of IntServ over DiffServ). The need
different FlowID mandates the use of two different sessions, similar for a different FlowID mandates the use of two different sessions,
to Section 3.2.8.2 and to the RSVP aggregation solution in RFC 3175 similar to Section 3.2.8.2 and to the RSVP aggregation solution in
[RFC3175]. RFC 3175 [RFC3175].
Edge QNEs of the aggregation domain that want to maintain some end- Edge QNEs of the aggregation domain that want to maintain some end-
to-end properties may establish a peering relation by sending the to-end properties may establish a peering relation by sending the
end-to-end message transparently over the domain (using the end-to-end message transparently over the domain (using the
intermediate node bypass capability described above). Updating the intermediate node bypass capability described above). Updating the
end-to-end properties in this message may require some knowledge of end-to-end properties in this message may require some knowledge of
the aggregated session (e.g. for updating delay values). For this the aggregated session (e.g. for updating delay values). For this
purpose, the end-to-end session contains a BOUND_SESSION_ID carrying purpose, the end-to-end session contains a BOUND_SESSION_ID carrying
the SESSION_ID of the aggregate session. the SESSION_ID of the aggregate session.
3.2.9. Priority 3.2.9. 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 GIMPS harmful than during handover. This situation only occurs when GIST
or QoS NSLP processing is the congested part or scarce resource. or QoS NSLP processing is the congested part or scarce resource.
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 resources are oversubscribed. In that case, existing reservations
may be preempted in order to make room for new higher-priority may be preempted in order to make room for new higher-priority
reservations. A typical approach to deal with priority and reservations. A typical approach to deal with priority and
preemption is through the specification of a setup priority and preemption is through the specification of a setup priority and
holding priority for each reservation. The resource management holding priority for each reservation. The resource management
function at each QNE then keeps track of the resource consumption at function at each QNE then keeps track of the resource consumption at
each priority level. Reservations are established when resources, at each priority level. Reservations are established when resources, at
their setup priority level, are still available. They may cause their setup priority level, are still available. They may cause
preemption of reservations with a lower holding priority than their preemption of reservations with a lower holding priority than their
setup priority. setup priority.
Support of reservation priority is a QSPEC parameter and therefore Support of reservation priority is a QSPEC parameter and therefore
outside the scope of this specification. The GIMPS implementation outside the scope of this specification. The GIST specification
should provide a mechanism to support a number of levels of message provides a mechanism to support a number of levels of message
priority that can be requested over the NSLP-GIMPS API. priority that can be requested over the NSLP-GIST API.
3.2.10. Rerouting 3.2.10. Rerouting
QoS NSLP needs to adapt to route changes in the data path. This 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 GIMPS implementations may routing protocols. Certain QNEs or GIST implementations may interact
interact with local routing module to receive quick notification of with local routing module to receive quick notification of route
route changes. This is largely implementation-specific and outside changes. This is largely implementation-specific and outside of the
of the scope of NSIS. Second, route changes may be detected at GIMPS scope of NSIS. Second, route changes may be detected at GIST layer.
layer. This specification requests GIMPS design to foresee This specification requests GIST design to foresee notification of
notification of this information over the API. This is outside the this information over the API. This is outside the scope of the QoS
scope of the QoS NSLP specification. Third, rerouting may be NSLP specification. Third, rerouting may be detected at the NSLP
detected at the NSLP layer. A QoS NSLP node is able to detect layer. A QoS NSLP node is able to detect changes in its QoS NSLP
changes in its QoS NSLP peers by keeping track of a Source peers by keeping track of a Source Identification Information (SII)
Identification Information (SII) object that is similar in nature to object that is similar in nature to the RSVP_HOP object described in
the RSVP_HOP object described in RFC 2205 [RFC2205]. When a RESERVE RFC 2205 [RFC2205]. When a RESERVE message with an existing
message with an existing SESSION_ID and a different SII is received, SESSION_ID and a different SII is received, the QNE knows its
the QNE knows its upstream or downstream peer has changed, for upstream or downstream peer has changed, for sender- and receiver-
sender- and receiver-oriented reservations, respectively. oriented reservations, respectively.
Reservation on the new path happens when a refreshing RESERVE message Reservation on the new path happens when a refreshing RESERVE message
arrives at the QNE where the old and the new path diverge. The arrives at the QNE where the old and the new path diverge. The
refreshing RESERVE will be interpreted as a new RESERVE on the new refreshing RESERVE will be interpreted as a new RESERVE on the new
path. Depending on the transfer mode, this may require installation path. Depending on the transfer mode, this may require installation
of a new messaging association. Rapid recovery at the NSLP layer of a new messaging association. Rapid recovery at the NSLP layer
therefore requires short refresh periods. Detection before the next therefore requires short refresh periods. Detection before the next
RESERVE message arrives is only possible at the IP layer or through RESERVE message arrives is only possible at the IP layer or through
monitoring of GIMPS peering relations (e.g. by TTL counting the monitoring of GIST peering relations (e.g. by TTL counting the number
number of GIMPS hops between NSLP peers or the observing changes in of GIST hops between NSLP peers or the observing changes in the
the outgoing interface towards GIMPS peer). These mechanisms can outgoing interface towards GIST peer). These mechanisms can provide
provide implementation specific optimisations, and are outside the implementation specific optimisations, and are outside the scope of
scope of this specification. this 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 incrementing the the reservation on the new path. This is done by incrementing the
RSN and then sending a new RESERVE message. On links that are common RSN and then sending a new RESERVE message. On links that are common
to the old and the new path, this RESERVE message is interpreted as a to the old and the new path, this RESERVE message is interpreted as a
refreshing RESERVE. On new links, it creates the reservation. refreshing RESERVE. 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 functionality is supported by keeping track of the old SII.
This specification requests GIMPS design to provide support for an This specification requests GIST design to provide support for an SII
SII that is interpreted as a random identifier at the QoS NSLP but that is interpreted as a random identifier at the QoS NSLP but that
that allows, when passed over the API, to forward QoS NSLP messages allows, when passed over the API, to forward QoS NSLP messages to the
to the QNE identified by that SII. QNE identified by that SII.
A QNI or a branch node may wish to keep the reservation on the old A QNI or a branch node may wish to keep the reservation on the old
branch. This could for instance be the case when a mobile node has branch. This could for instance be the case when a mobile node has
experienced a mobility event and wishes to keep reservation to its experienced a mobility event and wishes to keep reservation to its
old attachment point in case it moves back there. For this purpose, old attachment point in case it moves back there. For this purpose,
a REPLACE flag is foreseen in the common header, which, when set to a REPLACE flag is foreseen in the common header, which, when set to
FALSE, indicates that the reservation on the old branch should be FALSE, indicates that the reservation on the old branch should be
kept. kept.
[FIXME: This section also needs to discuss last node issues, since The design of the QoS-NSLP allows reservations to be installed at a
the last NSIS node on the path may change as a result of rerouting or subset of the nodes along a path, including cases where those nodes
mobility events.] might not included the endpoints of the application data flow.
In the case where the data flow receiver does not support the QoS-
NSLP, some particular considerations must be given to node discovery
and rerouting at the end of the signalling path.
There are three cases for the last node on the signalling path: 1)
Last node is the data receiver 2) Last node is a configured proxy for
the data receiver 3) Last node is not the data receiver and is not
explicitly configured to act as a signalling proxy on behalf of the
data receiver.
Cases (1) and (2) can be handled by the QoS-NSLP itself during the
initial path setup, since the QNE knows that it should terminate the
signalling. Case (3) requires some assistance from GIST which
provides messages across the API to indicate that no further QoS-NSLP
supporting GIST nodes are present downstream.
We can consider two particular cases for rerouting. In the first,
referred to as "Path Extension", rerouting occurs such that an
additional QNE is inserted into the signalling path between the old
last node and the data receiver, as shown in Figure 4.
/-------\ Initial route
/ v
/-\
/--|B|--\ +-+
/ \-/ \ |x| = QoS-NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ +-+ / |x| = QoS-NSLP unaware
\--|C|--/ \-/
+-+
\ ^
\-------/ Updated route
Figure 4: Path Extension
When rerouting occurs, the data path changes from A-B-D to A-C-D.
Initially the signalling path ends at A. Despite initially being the
last node, node A MUST continue to attempt to send messages
downstream to probe for path changes, unless it has been explicitly
configured as a signalling proxy for the data flow receiver. This is
required so that the signalling path change is detected, and C will
become the new last QNE.
In a second case, referred to as "Path Truncation", rerouting occurs
such that the QNE that was the last node on the signalling path is no
longer on the data path. This is shown in Figure 5.
/-------\ Initial route
/ v
+-+
/--|B|--\ +-+
/ +-+ \ |x| = QoS-NSLP aware
+-+ /-\ +-+
----|A| |D|
+-+ \-/ /-\
\ /-\ / |x| = QoS-NSLP unaware
\--|C|--/ \-/
\-/
\ ^
\-------/ Updated route
Figure 5: Path Truncation
When rerouting occurs, the data path again changes from A-B-D to A-C-
D. The signalling path initially ends at C, but this node is not on
the new path. In this case, the normal GIST path change detection
procedures at A will detect the path change and notify the QoS-NSLP.
GIST will also notify the signalling application that no downstream
GIST nodes supporting the QoS-NSLP are present. Node A MUST take over
as the last node on the signalling path
4. Examples of QoS NSLP Operation 4. Examples of QoS NSLP Operation
The QoS NSLP can be used in a number of ways. The examples given The QoS NSLP can be used in a number of ways. The examples given
here give an indication of some of the basic processing. However, here give an indication of some of the basic processing. However,
they are not exhaustive and do not attempt to cover the details of they are not exhaustive and do not attempt to cover the details of
the protocol processing. the protocol processing.
4.1. Basic sender-initiated reservation 4.1. Basic sender-initiated reservation
skipping to change at page 19, line 15 skipping to change at page 21, line 12
| RESPONSE | | | | RESPONSE | | |
|<---------+ | | |<---------+ | |
| | | | | | | |
| | | | | | | |
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 GIMPS which transports it to the The RESERVE message is passed to GIST which transports it to the next
next QNE. There it is delivered to the QoS NSLP processing which QNE. There it is delivered to the QoS NSLP processing which examines
examines the message. Policy control and admission control decisions the message. Policy control and admission control decisions are
are made. The exact processing also takes into account the QoS model made. The exact processing also takes into account the QoS model
being used. The node performs appropriate actions (e.g. installing being used. The node performs appropriate actions (e.g. installing
reservation) based on the QSPEC object in the message. 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 GIMPS, which forwards it to the the one received). This is passed to GIST, which forwards it to the
next QNE. 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 GIMPS functionality to determine that there are no more using some GIST 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.
A node can ask a confirmation of the installed state from its A node can ask a confirmation of the installed state from its
immediate peer. It does so by setting the A flag, which causes a immediate peer. It does so by setting the A flag, which causes a
RESPONSE message to be sent by the immediate peer. One use of this RESPONSE message to be sent by the immediate peer. One use of this
is to confirm the installation of state, which allows the use of is to confirm the installation of state, which allows the use of
reduced refreshes that later refer to that state. A RESPONSE message reduced refreshes that later refer to that state. A RESPONSE message
can also indicate an error when, e.g., a reservation has failed to be can also indicate an error when, e.g., a reservation has failed to be
installed. installed.
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. It does so by including a Request Identification messages. It does so by including a Request Identification
Information (RII) object in the RESERVE message. The RESPONSE is Information (RII) object in the RESERVE message. If the message
forwarded peer-to-peer along the reverse of the path that the RESERVE already includes an RII, an interested QNE must not add a new RII
message took (using GIMPS path state), and so is seen by all the QNEs object nor replace the old RII object, but may simply remember that
on the reverse-path. It is only forwarded as far as the node which RII to match the related RESPONSE it is interested in later. When it
requested the RESPONSE. receives the RESPONSE, it forwards the RESPONSE upstream towards the
RII originating node.
The RESPONSE is forwarded peer-to-peer along the reverse of the path
that the RESERVE message took (using GIST path state), and so is seen
by all the QNEs on the reverse-path. It is only forwarded as far as
the node which requested the RESPONSE originally.
The reservation can subsequently be refreshed by sending further The reservation can subsequently 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 QSPEC data to indicate a different set the same way, by changing the QSPEC data to indicate a different set
of resources to reserve. 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 RFC 2961 [RFC2961]. Once a similar way to that proposed for RSVP in RFC 2961 [RFC2961]. Once a
RESPONSE message has been received indicating the successful RESPONSE message has been received indicating the successful
skipping to change at page 20, line 18 skipping to change at page 22, line 21
QUERY messages can be used to gather information from QNEs along the QUERY messages can be used to gather information from QNEs along the
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 a QSPEC containing the actual query to message. This message includes a QSPEC containing the actual query to
be performed at QNEs along the path. It also contains an object used be performed at QNEs along the path. It also contains an object used
to match the response back to the query, and an indicator of the to match the response back to the query, and an indicator of the
query scope (next node, whole path). The QUERY message is passed to query scope (next node, whole path). The QUERY message is passed to
GIMPS to forward it along the path. GIST to forward it along the path.
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 GIMPS for further forwarding (unless it message is then passed to GIST 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 must be generated if the QUERY message At the QNR, a RESPONSE message must be generated if the QUERY message
includes a Request Identification Information (RII) object. Into includes a Request Identification Information (RII) object. Into
this is copied various objects from the received QUERY message. It this is copied various objects from the received QUERY message. It
is then passed to GIMPS to be forwarded peer-to-peer back along the is then passed to GIST to be forwarded peer-to-peer back along the
path. path.
Each QNE receiving the RESPONSE message should inspect the RII object Each QNE receiving the RESPONSE message should inspect the RII object
to see if it 'belongs' to it (i.e. it was the one that originally to see if it 'belongs' to it (i.e. it was the one that originally
created it). If it does not then it simply passes the message back created it). If it does not then it simply passes the message back
to GIMPS to be forwarded back down the path. to GIST to be forwarded back down the path.
4.3. Basic receiver-initiated reservation 4.3. Basic receiver-initiated reservation
As described in the NSIS framework [RFC4080] in some signalling As described in the NSIS framework [RFC4080] in some signalling
applications, a node at one end of the data flow takes responsibility applications, a node at one end of the data flow takes responsibility
for requesting special treatment - such as a resource reservation - for requesting special treatment - such as a resource reservation -
from the network. Both ends then agree whether sender or receiver- from the network. Both ends then agree whether sender or receiver-
initiated reservation is to be done. In case of a receiver initiated initiated reservation is to be done. In case of a receiver initiated
reservation, both ends agree whether a "One Pass With Advertising" reservation, both ends agree whether a "One Pass With Advertising"
(OPWA) [_XREF_OPWA95] model is being used. This negotiation can be (OPWA) [_XREF_OPWA95] model is being used. This negotiation can be
accomplished using mechanisms that are outside the scope of NSIS. accomplished using mechanisms that are outside the scope of NSIS.
To make a receiver-initiated reservation, the QNR constructs a QUERY To make a receiver-initiated reservation, the QNR constructs a QUERY
message, which may contain a QSPEC object from its chosen QoS model message, which may contain a QSPEC object from its chosen QoS model
(see Figure 5). This QUERY message does not need to trigger a (see Figure 5). The QUERY must have the R-bit set. This QUERY message
RESPONSE message and therefore, the QNI must not include the RII does not need to trigger a RESPONSE message and therefore, the QNI
object (Section 5.4.2), into the QUERY message. The QUERY message must not include the RII object (Section 5.4.2), into the QUERY
may be used to gather information along the path, which is carried by message. The QUERY message may be used to gather information along
the QSPEC object. An example of such information is the "One Pass the path, which is carried by the QSPEC object. An example of such
With Advertising" (OPWA) [_XREF_OPWA95]. This QUERY message causes information is the "One Pass With Advertising" (OPWA) [_XREF_OPWA95].
GIMPS reverse-path state to be installed. This QUERY message causes GIST reverse-path state to be installed.
QNR QNE QNE QNI QNR QNE QNE QNI
sender receiver sender receiver
| | | | | | | |
| QUERY | | | | QUERY | | |
+--------->| | | +--------->| | |
| | QUERY | | | | QUERY | |
| +--------->| | | +--------->| |
| | | QUERY | | | | QUERY |
| | +--------->| | | +--------->|
skipping to change at page 21, line 35 skipping to change at page 23, line 38
| RESPONSE | | | | RESPONSE | | |
+--------->| | | +--------->| | |
| | RESPONSE | | | | RESPONSE | |
| +--------->| | | +--------->| |
| | | RESPONSE | | | | RESPONSE |
| | +--------->| | | +--------->|
| | | | | | | |
Figure 5: Basic Receiver Initiated Reservation Figure 5: Basic Receiver Initiated Reservation
The QUERY message is transported by GIMPS to the next downstream QoS The QUERY message is transported by GIST to the next downstream QoS
NSLP node. There it is delivered to the QoS NSLP processing which NSLP node. There it is delivered to the QoS NSLP processing which
examines the message. The exact processing also takes into account examines the message. The exact processing also takes into account
the QoS model being used and may include gathering information on the QoS model being used and may include gathering information on
path characteristics that may be used to predict the end-to-end QoS. path characteristics that may be used to predict the end-to-end QoS.
The QNE generates a new QUERY message (usually based on the one The QNE generates a new QUERY message (usually based on the one
received). This is passed to GIMPS, which forwards it to the next received). This is passed to GIST, which forwards it to the next QNE.
QNE. The same processing is performed at further QNEs along the The same processing is performed at further QNEs along the path, up
path, up to the receiver, which in this situation is the QNR. The to the flow receiver. The receiver detects that this QUERY message
QNR detects that this QUERY message does not carry an RII object and carries the R-bit and by using the information contained in the
by using the information contained in the received QUERY message, received QUERY message, such as the QSPEC, constructs a RESERVE
such as the QSPEC, constructs a RESERVE message. message.
The RESERVE is forwarded peer-to-peer along the reverse of the path The RESERVE is forwarded peer-to-peer along the reverse of the path
that the QUERY message took (using GIMPS reverse path state). that the QUERY message took (using GIST reverse path state). Similar
Similar to the sender-initiated approach, any node may include an RII to the sender-initiated approach, any node may include an RII in its
in its RESERVE messages. The RESPONSE is sent back to confirm the RESERVE messages. The RESPONSE is sent back to confirm the resources
resources are set up. are set up.
The reservation can subsequently be refreshed in the same way as for The reservation can subsequently be refreshed in the same way as for
the sender-initiated approach. This RESERVE message may be also used the sender-initiated approach. This RESERVE message may be also used
to refresh GIMPS reverse path state. Alternatively, refreshing GIMPS to refresh GIST reverse path state. Alternatively, refreshing GIST
reverse path state could be performed by sending periodic QUERY reverse path state could be performed by sending periodic QUERY
messages, which are needed in case of route changes anyway. messages, which are needed in case of route changes anyway.
[FIXME - Receiver initiated reservations have been discussed on the
mailing list. There are aspects that still need solving.]
4.4. Bidirectional Reservations 4.4. Bidirectional Reservations
Bidirectional reservations are supported by binding two uni- Bidirectional reservations are supported by binding two uni-
directional sessions together. We distinguish two cases: directional sessions together. We distinguish two cases:
o Binding two sender-initiated reservations, e.g. one sender- o Binding two sender-initiated reservations, e.g. one sender-
initiated reservation from QNE A to QNE B and another one from QNE B initiated reservation from QNE A to QNE B and another one from QNE B
to QNE A. to QNE A.
o Binding a sender-initiated and a receiver-initiated reservation, o Binding a sender-initiated and a receiver-initiated reservation,
skipping to change at page 25, line 8 skipping to change at page 27, line 8
messages shown in Figure 9 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 9 as "RESERVE'"). This may use the same QoS model (shown in Figure 9 as "RESERVE'"). This may use the same QoS model
as 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.
This document does not specify how the QSPEC of the aggregate session This document does not specify how the QSPEC of the aggregate session
can be derived from the QSPECs of the end-to-end sessions. can be derived from the QSPECs of the end-to-end sessions.
Markings are used so that intermediate routers do not need to inspect The messages used for the signaling of the individual reservation
the individual flow reservations. The deaggregator then becomes the need to be marked such that the intermediate routers will not inspect
next hop QNE for the end-to-end per-flow reservation. them. The marking MUST be accomplished by the Aggregator by
modifying the QoS-NSLP default NSLP-ID value to a NSLP-ID predefined
value. The De-aggregator MUST stop this marking process by
reassigning the QoS-NSLP default NSLP-ID value to these signaling
messages. The deaggregator then becomes the next hop QNE for the end-
to-end per-flow 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
skipping to change at page 25, line 36 skipping to change at page 27, line 41
another. another.
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 that for the end-to-end reservation. The aggregate reservation can
be updated independently of the per-flow end-to-end reservations. be updated independently of the per-flow end-to-end reservations.
4.7. Reduced State or Stateless Interior Nodes 4.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 GIMPS and NSLP functionality which allows the conjunction with GIST and NSLP functionality which allows the
interior nodes to avoid storing GIMPS and QoS NSLP state. As a interior nodes to avoid storing GIST and QoS NSLP state. As a result
result the interior nodes only store the QSPEC-related reservation the interior nodes only store the QSPEC-related reservation state, or
state, or even no state at all. This allows the QoS model to use a even no state at all. This allows the QoS model to use a form of
form of "reduced-state" operation, where reservation states with a "reduced-state" operation, where reservation states with a coarser
coarser granularity (e.g. per-class) are used, or a "stateless" granularity (e.g. per-class) are used, or a "stateless" operation
operation where no QoS NSLP state is needed (or created). where no QoS NSLP 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 4.5 is that the transport characteristics for the models in Section 4.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. GIMPS can be used in a different way for the edge- reservation, i.e. GIST can be used in a different way for the edge-
to-edge and hop-by-hop sessions. The reduced state reservation can to-edge and hop-by-hop sessions. The reduced state reservation can
be updated independently of the per-flow end-to-end reservations. be updated independently of the per-flow end-to-end reservations.
QNE QNE QNE QNE QNE QNE QNE QNE
ingress interior interior egress ingress interior interior egress
GIMPS stateful GIMPS stateless GIMPS stateless GIMPS stateful
GIST stateful GIST stateless GIST stateless GIST stateful
| | | | | | | |
RESERVE | | | | RESERVE | | | |
-------->| RESERVE | | | -------->| RESERVE | | |
+--------------------------------------------->| +--------------------------------------------->|
| RESERVE' | | | | RESERVE' | | |
+-------------->| | | +-------------->| | |
| | RESERVE' | | | | RESERVE' | |
| +-------------->| | | +-------------->| |
| | | RESERVE' | | | | RESERVE' |
| | +------------->| | | +------------->|
skipping to change at page 26, line 23 skipping to change at page 28, line 29
| | | |<-------- | | | |<--------
| | | RESPONSE | | | | RESPONSE |
|<---------------------------------------------+ |<---------------------------------------------+
RESPONSE| | | | RESPONSE| | | |
<--------| | | | <--------| | | |
Figure 11: Sender-initiated reservation with Reduced State Interior Figure 11: Sender-initiated reservation with Reduced State Interior
Nodes 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 GIMPS as usual. At initial RESERVE message, and it is forwarded by GIST 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 ignored At the ingress the original RESERVE message is forwarded but ignored
by the stateless or reduced-state nodes. The egress node is the next by the stateless or reduced-state nodes. This is accomplished by
QoS NSLP hop for that session. After the initial discovery phase marking this message, i.e., modifying the QoS-NSLP default NSLP-ID
using unreliable GIMPS transfer mode, reliable GIMPS transfer mode value to another NSLP-ID predefined value. The marking MUST be
between the ingress and egress can be used. At the egress node the accomplished by the ingress by modifying the QoS_NSLP default NSLP-ID
RESERVE message is then forwarded normally. value to a NSLP-ID predefined value. The egress MUST stop this
marking process by reassigning the QoS-NSLP default NSLP-ID value to
the original RESERVE message. An example of such operation is given
in [I-D.ietf-nsis-rmd].
The egress node is the next QoS NSLP hop for that session. After the
initial discovery phase using unreliable GIST transfer mode, reliable
GIST transfer mode between the ingress and egress 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). Since the original operation (such as the RMD per hop reservation). Since the original
RESERVE and the RESERVE' messages are addressed identically, RESERVE' RESERVE and the RESERVE' messages are addressed identically, RESERVE'
visits the same nodes that were visited, including the egress QNE. visits the same nodes that were visited, including the egress QNE.
When processed by interior (stateless) nodes the QoS NSLP processing When processed by interior (stateless) nodes the QoS NSLP processing
exercises its options to not keep state wherever possible, so that no exercises its options to not keep state wherever possible, so that no
per flow QoS NSLP state is stored. Some state, e.g. per class, for per flow QoS NSLP state is stored. Some state, e.g. per class, for
the QSPEC related data may be held at these interior nodes. The QoS the QSPEC related data may be held at these interior nodes. The QoS
NSLP also requests that GIMPS use different transport characteristics NSLP also requests that GIST use different transport characteristics
(i.e. sending of messages in unreliable GIMPS transfer mode). It (i.e. sending of messages in unreliable GIST transfer mode). It also
also requests the local GIMPS processing not to retain messaging requests the local GIST processing not to retain messaging
association state or reverse message routing state. association state or reverse message routing state.
Nodes, such as those in the interior of the stateless or reduced- Nodes, such as those in the interior of the stateless or reduced-
state domain, that do not retain reservation state cannot send back state domain, that do not retain reservation state cannot send back
RESPONSE messages (and so cannot use reduced refreshes). RESPONSE messages (and so cannot use reduced 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 GIMPS neighbour relations are not maintained in the reduced- Since GIST neighbour relations are not maintained in the reduced-
state region, only sender initiated signalling can be supported. If state region, only sender initiated signalling can be supported. If
a receiver-initiated reservation over a stateless or reduced state a receiver-initiated reservation over a stateless or reduced state
domain is required this can be implemented as shown below. domain is required this can be implemented as shown below.
QNE QNE QNE QNE QNE QNE
ingress interior egress ingress interior egress
GIMPS stateful GIMPS stateless GIMPS stateful GIST stateful GIST stateless GIST stateful
| | | | | |
QUERY | | | QUERY | | |
-------->| QUERY | | -------->| QUERY | |
+------------------------------>| +------------------------------>|
| | | QUERY | | | QUERY
| | +--------> | | +-------->
| | | RESERVE | | | RESERVE
| | |<-------- | | |<--------
| | RESERVE | | | RESERVE |
|<------------------------------+ |<------------------------------+
skipping to change at page 28, line 4 skipping to change at page 30, line 17
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 incrementing the the reservation on the new path. This is done by incrementing the
RSN and sending a RESERVE message. On links that are common to the RSN and sending a RESERVE message. On links that are common to the
old and the new path, this RESERVE message is interpreted as a old and the new path, this RESERVE message is interpreted as a
refreshing RESERVE. On new links, it creates the reservation. refreshing RESERVE. 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 functionality is supported by keeping track of the old SII.
This specification requests GIST design to provide support for an
This specification requests GIMPS design to provide support for an
SII. The SII is opaque to the QoS NSLP, i.e. QoS NSLP does not make SII. The SII is opaque to the QoS NSLP, i.e. QoS NSLP does not make
any assumptions on how this identifier is constructed. When passed any assumptions on how this identifier is constructed. When passed
over the API, it allows QoS NSLP to indicate that its messages should over the API, it allows QoS NSLP to indicate that its messages should
be sent to the QNE identified by that SII. be sent to the QNE identified by that SII.
In case of a receiver-initiated reservation, a QNE can detect a route In case of a receiver-initiated reservation, a QNE can detect a route
change by receiving a RESERVE message with a different SII. In case change by receiving a RESERVE message with a different SII. In case
of a sender-initiated reservation, the same information is learned of a sender-initiated reservation, the same information is learned
from a RESPONSE message, or from a NOTIFY message sent by the from a RESPONSE message, or from a NOTIFY message sent by the
downstream peer. A QNE that has detected the route change via the downstream peer. A QNE that has detected the route change via the
skipping to change at page 30, line 53 skipping to change at page 33, line 16
AAA server in the user's home network when making the authorization AAA server in the user's home network when making the authorization
decision. decision.
5. QoS NSLP Functional specification 5. QoS NSLP Functional specification
5.1. QoS NSLP Message and Object Formats 5.1. QoS NSLP Message and Object Formats
A 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 common header and other objects are encapsulated together in a The common header and other objects are encapsulated together in a
GIMPS NSLP-Data object. The following subsections define the formats GIST NSLP-Data object. The following subsections define the formats
of the common header and each of the QoS NSLP message types. In the of the common header and each of the QoS NSLP message types. In the
message formats, the common header is denoted as COMMON_HEADER. message formats, the common header is denoted as COMMON_HEADER.
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
the Augmented Backus-Naur Form (ABNF) specified in RFC 2234 the Augmented Backus-Naur Form (ABNF) specified in RFC 2234
[RFC2234]. The ABNF implies an order for the objects in a message. [RFC2234]. The ABNF implies an order for the objects in a message.
However, in many (but not all) cases, object order makes no logical However, in many (but not all) cases, object order makes no logical
difference. An implementation should create messages with the difference. An implementation should create messages with the
objects in the order shown here, but accept the objects in any order, objects in the order shown here, but accept the objects in any order,
except for QSPEC object(s) which always appear last in the message, except for QSPEC object(s) which always appear last in the message,
and whose mutual order matters. and whose mutual order matters.
5.1.1. Common header 5.1.1. Common header
All GIMPS NSLP-Data objects for the QoS NSLP MUST contain this common All GIST NSLP-Data objects for the QoS NSLP MUST contain this common
header as the first 32 bits of the object (this is not the same as header as the first 32 bits of the object (this is not the same as
the GIMPS Common Header). the GIST Common Header).
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message Type | Flags | | Message Type | Message Flags | Generic Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields in the common header are as follows: The fields in the common header are as follows:
Msg Type: 16 bits Msg Type: 8 bits
1 = RESERVE 1 = RESERVE
2 = QUERY 2 = QUERY
3 = RESPONSE 3 = RESPONSE
4 = NOTIFY 4 = NOTIFY
Flags: 16 bits Message-specific flags: 8 bits
Generic flags: 16 bits
The set of appropriate flags depends on the particular message The set of appropriate flags depends on the particular message
being processed. Any bit not defined as a flag for a particular being processed. Any bit not defined as a flag for a particular
message MUST be set to zero on sending and MUST be ignored on message MUST be set to zero on sending and MUST be ignored on
receiving. receiving.
5.1.2. Message formats 5.1.2. Message formats
5.1.2.1. RESERVE 5.1.2.1. RESERVE
skipping to change at page 32, line 13 skipping to change at page 34, line 27
RESERVE = COMMON_HEADER RESERVE = COMMON_HEADER
RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] RSN [ RII ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] *2QSPEC [ POLICY_DATA ] *2QSPEC
The RSN is the only mandatory object and MUST always be present. The RSN is the only mandatory object and MUST always be present.
If any QSPEC objects are present, they MUST occur at the end of the If any QSPEC objects are present, they MUST occur at the end of the
message. There are no other requirements on transmission order, message. There are no other requirements on transmission order,
although the above order is recommended. although the above order is recommended.
Four flags are defined for use in the common header with the RESERVE Three message-specific flags are defined for use in the common header
message. These are: with the RESERVE message. These are:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
| Reserved |T|S|A|R| |Reserved |T|A|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
TEAR (T) - when set, indicates that reservation state and QoS NSLP TEAR (T) - when set, indicates that reservation state and QoS NSLP
operation state should be torn down. This is indicated to the operation state should be torn down. This is indicated to the
RMF. RMF. Depending on the QoS model, the tear message may include a
QSPEC to further specify state removal.
SCOPING (S) - when set, indicates that the message is scoped and
should not travel down the entire path but only as far as the next
QNE (scope="next hop"). By default, this flag is not set (default
scope="whole path").
ACKNOWLEDGE (A) - when set, indicates that an explicit ACKNOWLEDGE (A) - when set, indicates that an explicit
confirmation of the state installation action is REQUIRED. This confirmation of the state installation action is REQUIRED. This
flag SHOULD be set on transmission by default. flag SHOULD be set on transmission by default.
REPLACE (R) - when set, indicates that a RESERVE with different REPLACE (R) - when set, indicates that a RESERVE with different
Message Routing Information (MRI) replaces an existing one, so the Message Routing Information (MRI) replaces an existing one, so the
old one MAY be torn down immediately. This is the default old one MAY be torn down immediately. This is the default
situation. This flag may be unset to indicate a desire from an situation. This flag may be unset to indicate a desire from an
upstream node to keep an existing reservation on an old branch in upstream node to keep an existing reservation on an old branch in
place. place.
One generic flag is used with the RESERVE message:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCOPING (S) - when set, indicates that the message is scoped and
should not travel down the entire path but only as far as the next
QNE (scope="next hop"). By default, this flag is not set (default
scope="whole path").
If the REFRESH_PERIOD is not present, a default value of 30 seconds If the REFRESH_PERIOD is not present, a default value of 30 seconds
is assumed. is assumed.
If the session of this message is bound to another session, then the 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 RESERVE message MUST include the SESSION_ID of that other session in
a BOUND_SESSION_ID object. a BOUND_SESSION_ID object.
A "reservation collision" may occur if the sender believes that a A "reservation collision" may occur if the sender believes that a
sender-initiated reservation should be performed for a flow, whilst sender-initiated reservation should be performed for a flow, whilst
the other end believes that it should be starting a receiver- the other end believes that it should be starting a receiver-
skipping to change at page 33, line 22 skipping to change at page 35, line 46
messages to be sent further along the path, as each hop has its own messages to be sent further along the path, as each hop has its own
refresh timer. If the routing path changed due to mobility, the refresh timer. If the routing path changed due to mobility, the
mobile node's IP address changed, and it sent a Mobile IP binding mobile node's IP address changed, and it sent a Mobile IP binding
update, the resulting refresh is a new RESERVE. This RESERVE includes update, the resulting refresh is a new RESERVE. This RESERVE includes
new MRI and will be propagated end-to-end without requesting a new MRI and will be propagated end-to-end without requesting a
RESPONSE. RESPONSE.
Note: It is possible for a host to use this mechanism to constantly Note: It is possible for a host to use this mechanism to constantly
force the QNEs on the path to send refresh RESERVE messages. It may, force the QNEs on the path to send refresh RESERVE messages. It may,
therefore, be appropriate for QNEs to perform rate limiting on the therefore, be appropriate for QNEs to perform rate limiting on the
refresh messages that they send. [FIXME: Should this "DoS attack" be refresh messages that they send.
mentioned in the Security Considerations section?]
[FIXME: what happens if a refresh arrives for a receiver-initiated
reservation, but due to a routing change there is no reverse path
state set up, yet? Added a new open issue on this.]
5.1.2.2. QUERY 5.1.2.2. 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
[ RII ][ BOUND_SESSION_ID ] [ RII ][ BOUND_SESSION_ID ]
[ POLICY_DATA ] *2QSPEC [ POLICY_DATA ] *2QSPEC
A QUERY message MUST contain an RII object to match an incoming A QUERY message MUST contain an RII object to match an incoming
RESPONSE to the QUERY, unless the QUERY is being used to initiate RESPONSE to the QUERY, unless the QUERY is being used to initiate
reverse-path state for a receiver-initiated reservation. reverse-path state for a receiver-initiated reservation.
A QUERY message MAY contain one or two QSPEC objects and a A QUERY message MAY contain one or two QSPEC objects and a
POLICY_DATA object. The QSPEC object describes what is being queried POLICY_DATA object. The QSPEC object describes what is being queried
for and may contain objects that gather information along the data for and may contain objects that gather information along the data
path. The POLICY_DATA object authorizes the requester of the QUERY path. The POLICY_DATA object authorizes the requester of the QUERY
message. If any QSPEC objects are present, they MUST occur at the message. If any QSPEC objects are present, they MUST occur at the
end of the message. There are no other requirements on transmission end of the message. There are no other requirements on transmission
order, although the above order is recommended. order, although the above order is recommended.
One flag is defined for use in the common header with the QUERY One message-specific flag is defined for use in the common header
message. This is: with the QUERY message. This is:
+-+-+-+-+-+-+-+-+
|Reserved |R|
+-+-+-+-+-+-+-+-+
RESERVE-INIT (R) - when this is set, the QUERY is meant as a trigger
for the recipient to make a resource reservation by sending a
RESERVE.
One generic flag is defined for use in the common header with the
QUERY message. This is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S| | Reserved |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCOPING - when set, indicates that the message is scoped an should SCOPING (S) - when set, indicates that the message is scoped an
not travel down the entire path but only as far as the next QNE should not travel down the entire path but only as far as the next
(scope="next hop"). By default, this flag is not set (default QNE (scope="next hop"). By default, this flag is not set (default
scope="whole path"). scope="whole path").
If the session of this message is bound to another session, then the 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 RESERVE message MUST include the SESSION_ID of that other session in
a BOUND_SESSION_ID object. a BOUND_SESSION_ID object.
5.1.2.3. RESPONSE 5.1.2.3. RESPONSE
The format of a RESPONSE message is as follows: The format of a RESPONSE message is as follows:
RESPONSE = COMMON_HEADER RESPONSE = COMMON_HEADER
[ RII / RSN ] ERROR_SPEC [ RII / RSN ] INFO_SPEC
*2QSPEC *2QSPEC
A RESPONSE message MUST contain an ERROR_SPEC object which indicates A RESPONSE message MUST contain an INFO_SPEC object which indicates
the success of a reservation installation or an error condition. the success of a reservation installation or an error condition.
Depending on the value of the ERROR_SPEC, the RESPONSE MAY also Depending on the value of the INFO_SPEC, the RESPONSE MAY also
contain a QSPEC object. contain a QSPEC object.
If any QSPEC objects are present, they MUST occur at the end of the If any QSPEC objects are present, they MUST occur at the end of the
message. There are no other requirements on transmission order, message. There are no other requirements on transmission order,
although the above order is recommended. although the above order is recommended.
One flag is defined for use in the common header with the RESPONSE No message-specific flags are defined.
message. This is:
One generic flag is defined for use in the common header with the
RESPONSE message. This is:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |S| | Reserved |S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCOPING - when set, indicates that the message is scoped and SCOPING (S) - when set, indicates that the message is scoped and
should not travel down the entire path but only as far as the next should not travel down the entire path but only as far as the next
QNE (scope="next hop"). By default, this flag is not set (default QNE (scope="next hop"). By default, this flag is not set (default
scope="whole path"). scope="whole path").
5.1.2.4. NOTIFY 5.1.2.4. NOTIFY
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 *2QSPEC INFO_SPEC *2QSPEC
A NOTIFY message MUST contain an ERROR_SPEC object indicating the A NOTIFY message MUST contain an INFO_SPEC object indicating the
reason for the notification. Depending on the ERROR_SPEC value, it reason for the notification. Depending on the INFO_SPEC value, it
MAY contain one or two QSPEC objects providing additional MAY contain one or two QSPEC objects providing additional
information. information.
No flags are defined for use with the NOTIFY message. No flags are defined for use with the NOTIFY message.
5.1.3. Object Formats 5.1.3. Object Formats
The QoS NSLP uses the Type-Length-Value (TLV) object format defined The QoS NSLP uses the Type-Length-Value (TLV) object format defined
by GIMPS [I-D.ietf-nsis-ntlp]. Every object consists of one or more by GIST [I-D.ietf-nsis-ntlp]. Every object consists of one or more
32-bit words with a one-word header. For convenience the standard 32-bit words with a one-word header. For convenience the standard
object header is shown here: object header is shown here:
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|r|r|r|r| Type |r|r|r|r| Length | |r|r|r|r| Type |r|r|r|r| Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The value for the Type field comes from GIST object type space. The
The value for the Type field comes from GIMPS object type space. The
Length field is given in units of 32 bit words and measures the Length field is given in units of 32 bit words and measures the
length of the Value component of the TLV object (i.e. it does not length of the Value component of the TLV object (i.e. it does not
include the standard header). include the standard header).
The object diagrams here use '//' to indicate a variable sized field The object diagrams here use '//' to indicate a variable sized field
and ':' to indicate a field that is optionally present. and ':' to indicate a field that is optionally present.
A QoS NSLP implementation must recognize objects of the following A QoS NSLP implementation must recognize objects of the following
types: RII, RSN, REFRESH_PERIOD, BOUND_SESSION_ID, ERROR_SPEC, QSPEC types: RII, RSN, REFRESH_PERIOD, BOUND_SESSION_ID, INFO_SPEC, QSPEC
and POLICY_DATA. and POLICY_DATA.
NB: This draft does not currently include the codepoints for the QoS NB: This draft does not currently include the codepoints for the QoS
NSLP related object types. The object header is followed by the NSLP related object types. The object header is followed by the
Value field, which varies for different objects. The format of the Value field, which varies for different objects. The format of the
Value field for currently defined objects is specified below. Value field for currently defined objects is specified below.
5.1.3.1. Request Identification Information (RII) 5.1.3.1. Request Identification Information (RII)
Type: RII Type: RII
skipping to change at page 36, line 9 skipping to change at page 38, line 40
request in a RESERVE or QUERY message. request in a RESERVE or QUERY message.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Response Identification Information (RII) | | Response Identification Information (RII) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3.2. Reservation Sequence Number (RSN) 5.1.3.2. Reservation Sequence Number (RSN)
Type: RSN Type: RSN
Length: Fixed - 1 32-bit word Length: Fixed - 2 32-bit word
Value: An incrementing sequence number that indicates the order in Value: An incrementing sequence number that indicates the order in
which state modifying actions are performed by a QNE. The RSN has which state modifying actions are performed by a QNE, and an epoc
identifier to allow the identification of peer restarts. The RSN has
local significance only, i.e. between a pair of neighbouring stateful local significance only, i.e. between a pair of neighbouring stateful
QNEs. QNEs.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Reservation Sequence Number (RSN) | Reservation Sequence Number (RSN) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
Epoch Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
[FIXME: Further details of RSN handling need to be specified. An
Epoch Identifier might need to be added to this object.]
5.1.3.3. REFRESH_PERIOD 5.1.3.3. REFRESH_PERIOD
Type: REFRESH_PERIOD Type: REFRESH_PERIOD
Length: Fixed - 1 32-bit word Length: Fixed - 1 32-bit word
Value: The refresh timeout period R used to generate this message; in Value: The refresh timeout period R used to generate this message; in
milliseconds. milliseconds.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Refresh Period (R) | | Refresh Period (R) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3.4. BOUND_SESSION_ID 5.1.3.4. BOUND_SESSION_ID
Type: BOUND_SESSION_ID Type: BOUND_SESSION_ID
Length: Fixed - 4 32-bit words Length: Fixed - 4 32-bit words
Value: Specifies the SESSION_ID (as specified in GIMPS [I-D.ietf- Value: Specifies the SESSION_ID (as specified in GIST [I-D.ietf-nsis-
nsis-ntlp]) of the session that must be bound to the session ntlp]) of the session that must be bound to the session associated
associated with the message carrying this object. with the message carrying this object.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ Session ID + + Session ID +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3.5. PACKET_CLASSIFIER 5.1.3.5. PACKET_CLASSIFIER
[FIXME: This is a first attempt at this for discussion (see also [FIXME: This is a first attempt at this for discussion (see also
previous discussion on mailing list).] previous discussion on mailing list). Should the PACKET_CLASSIFIER be
in here, or in the QSPEC?]
Type: Packet Classifier Type: Packet Classifier
Length: Variable Length: Variable
Value: Contains a 2 byte value indicating the MRM being used, and Value: Contains a 2 byte value indicating the MRM being used, and
then additional variable length MRM-specific data then additional variable length MRM-specific data
[FIXME: do we need to duplicate the MRM value here? could we just get [FIXME: do we need to duplicate the MRM value here? could we just get
it from the MRI in the GIMPS part of the message? however, it from the MRI in the GIST part of the message? however, duplicating
duplicating it seems not unreasonable from a sanity checking it seems not unreasonable from a sanity checking perspective.]
perspective.]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message-Routing-Method | | | Message-Routing-Method | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
// Method-specific classifier data (variable) // // Method-specific classifier data (variable) //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
For the basic path-coupled routing MRM, the method specific data is For the basic path-coupled routing MRM, the method specific data is
two bytes long and consists of a set of flags: two bytes long and consists of a set of flags:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 37, line 55 skipping to change at page 40, line 36
F - Flow Label F - Flow Label
S - SPI S - SPI
A - Source Port A - Source Port
B - Destination Port B - Destination Port
[FIXME: Some of the flag identifiers seem strange. They were selected [FIXME: Some of the flag identifiers seem strange. They were selected
so that they didn't conflict with any flag names in the GIMPS MRI, so that they didn't conflict with any flag names in the GIST MRI,
i.e. make D in GIMPS be something different here] i.e. make D in GIST be something different here]
The flags indicate which fields from the MRI should be used by the The flags indicate which fields from the MRI should be used by the
packet classifier. Flags MUST only be set if the data is present in packet classifier. Flags MUST only be set if the data is present in
the MRI (i.e. if there is a flag for it in GIMPS, then that must also the MRI (i.e. if there is a flag for it in GIST, then that must also
be set). be set).
The appropriate set of flags set may depend, to some extent, on the The appropriate set of flags set may depend, to some extent, on the
QoS model being used. QoS model being used.
[FIXME: I assume we don't need flags for prefixes. Do we need [FIXME: I assume we don't need flags for prefixes. Do we need
separate flags for the two ports?] separate flags for the two ports?]
[FIXME: Should this object be mandatory or optional? Optional might [FIXME: Should this object be mandatory or optional? Optional might
mean 'use all information from the MRI'. Currently specified as mean 'use all information from the MRI'. Currently specified as
mandatory.] mandatory.]
5.1.3.6. ERROR_SPEC 5.1.3.6. INFO_SPEC
[FIXME: Change name from ERROR_SPEC to something that reflects that
fact that not all status codes are errors.]
Type: ERROR Type: INFO
Length: Variable Length: Variable
Value: Contains a 1 byte error class and 3 byte error code, an error Value: Contains a 4-bit error class, a 12-bit error code, an 8-bit
source identifier and optionally variable length error-specific NSLP-specific error subcode, an 8-bit error source identifier length,
information. an error source identifier and optionally variable length error-
specific information.
[FIXME: Suggested modification is to change this to Error Class +
Error Code + Error Subcode, where Error Codes are shared between
NSLPs, and Subcodes are NSLP-specific.]
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Error Class | Error Code | | Class | Error Code | Error subcode | ESI-Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ESI-Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Error Source Identifier // // Error Source Identifier //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Optional error-specific information // // Optional error-specific information //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The first byte of the error code indicates the severity level. The The first four bits of the error code indicates the severity class.
currently defined severity levels are: The currently defined severity classes are:
o 0x01 - Informational o 0x01 - Informational
o 0x02 - Success o 0x02 - Success
o 0x03 - Protocol Error o 0x03 - Protocol Error
o 0x04 - Transient Failure o 0x04 - Transient Failure
o 0x05 - Permanent Failure o 0x05 - Permanent Failure
o 0x06 - NSLP-specific Error
Within each severity class a number of error values are defined. Within each severity class a number of error values are defined.
o Informational: o Informational:
* 0x01000001 - Unknown BOUND_SESSION_ID: the message refers to * 0x01 - Unknown BOUND_SESSION_ID: the message refers to an
an unknown SESSION_ID in its BOUND_SESSION_ID object. unknown SESSION_ID in its BOUND_SESSION_ID object.
o Success: o Success:
* 0x02000001 - State installation succeeded * 0x01 - State installation succeeded
* 0x02000002 - Reservation created: reservation installed on * 0x02 - Reservation created: reservation installed on
complete path (sent by last node). complete path (sent by last node).
* 0x02000003 - Reservation accepted: reservation installed at * 0x03 - Reservation accepted: reservation installed at this
this QNE, but not yet installed on the rest of the path. QNE, but not yet installed on the rest of the path.
* 0x02000004 - Reservation created but modified: reservation * 0x04 - Reservation created but modified: reservation
installed, but bandwidth reserved was not the maximum installed, but bandwidth reserved was not the maximum
requested. requested.
o Protocol Error: o Protocol Error:
* 0x03000001 - Illegal message type: the type given in the * 0x01 - Illegal message type: the type given in the Message
Message Type field of the common header is unknown. Type field of the common header is unknown.
* 0x03000002 - Wrong message length: the length given for the * 0x02 - Wrong message length: the length given for the
message does not match the length of the message data. message does not match the length of the message data.
* 0x03000003 - Bad flags value: an undefined flag or * 0x03 - Bad flags value: an undefined flag or combination of
combination of flags was set. flags was set.
* 0x03000004 - Mandatory object missing: an object required in * 0x04 - Mandatory object missing: an object required in a
a message of this type was missing. message of this type was missing.
* 0x03000005 - Illegal object present: an object was present * 0x05 - Illegal object present: an object was present which
which must not be used in a message of this type. must not be used in a message of this type.
* 0x03000006 - Unknown object present: an object of an unknown * 0x06 - Unknown object present: an object of an unknown type
type was present in the message. was present in the message.
* 0x03000007 - Wrong object length: the length given for the * 0x07 - Wrong object length: the length given for the object
object did not match the length of the object data present. did not match the length of the object data present.
* 0x03000008 - Unknown QSPEC type: the QoS Model ID refers to * 0x08 - Unknown QSPEC type: the QoS Model ID refers to a QoS
a QoS Model which is not known by this QNE. Model which is not known by this QNE.
* 0x3000009 - RESERVE received from wrong direction. * 0x09 - RESERVE received from wrong direction.
o Transient Failure: o Transient Failure:
* 0x04000001 - Requested resources not available * 0x01 - Requested resources not available
* 0x04000002 - Insufficient bandwidth available
* 0x04000003 - Delay requirement cannot be met * 0x02 - Insufficient bandwidth available
* 0x04000004 - Transient RMF-related error * 0x03 - Delay requirement cannot be met
* 0x04000005 - Resources pre-empted * 0x04 - Transient RMF-related error
* 0x04000006 - No GIMPS reverse-path forwarding state * 0x05 - Resources pre-empted
* 0x04000007 - NSLP soft-state expired * 0x06 - No GIST reverse-path forwarding state
* 0x07 - NSLP soft-state expired
* 0x08 - No path state for RESERVE, when doing a receiver-
oriented
reservation
* 0x09 - Reservation pre-empted
* 0x10 - RII conflict
o Permanent Failure: o Permanent Failure:
* 0x05000001 - Authentication failure * 0x01 - Authentication failure
* 0x05000002 - Unable to agree transport security with peer * 0x02 - Unable to agree transport security with peer
* 0x05000003 - Internal or system error * 0x03 - Internal or system error
* 0x05000004 - Resource request denied (authorization failed) * 0x04 - Resource request denied (authorization failed)
* 0x05000005 - Permanent RMF-related error * 0x05000005 - Permanent RMF-related error
o NSLP-specific Error:
This error class may be used, if an NSLP needs to indicate
errors, which do not fit any of the pre-defined error levels.
The interpretation of these errors is defined in each NSLP
separately.
Values in the error subcode field are defined in each NSLP
separately. For the QoS NSLP, these are defined in the different QoS
model specifications.
5.1.3.7. QSPEC 5.1.3.7. QSPEC
Type: QSPEC Type: QSPEC
Length: Variable Length: Variable
Value: Variable length QSPEC (QoS specification) information, which Value: Variable length QSPEC (QoS specification) information, which
is QoS Model dependent. is QoS Model dependent.
The contents and encoding rules for this object are specified in The contents and encoding rules for this object are specified in
skipping to change at page 41, line 5 skipping to change at page 43, line 50
// QSPEC Data // // QSPEC Data //
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.1.3.8. POLICY_DATA 5.1.3.8. POLICY_DATA
POLICY_DATA objects may contain various items to authenticate the POLICY_DATA objects may contain various items to authenticate the
user and allow the reservation to be authorised. Some related issues user and allow the reservation to be authorised. Some related issues
are also discussed in Section 3.1.4. are also discussed in Section 3.1.4.
[FIXME: Need to fix this when Hannes is done]
5.2. General Processing Rules 5.2. General Processing Rules
5.2.1. State Manipulation 5.2.1. State Manipulation
The processing of a message and its component objects involves The processing of a message and its component objects involves
manipulating the QoS NSLP and reservation state of a QNE. manipulating the QoS NSLP and reservation state of a QNE.
For each flow, a QNE stores (RMF-related) reservation state which For each flow, a QNE stores (RMF-related) reservation state which
depends on the QoS model / QSPEC used and QoS NSLP operation state depends on the QoS model / QSPEC used and QoS NSLP operation state
which includes non-persistent state (e.g. the API parameters while a which includes non-persistent state (e.g. the API parameters while a
QNE is processing a message) and persistent state which is kept as QNE is processing a message) and persistent state which is kept as
long as the session is active. 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 GIMPS or set locally. A large identifier provided by GIST 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 GIMPS. Several entries are possible in case of Copied from GIST. Several entries are possible in case of
mobility events. mobility events.
QoS Model ID QoS Model ID
32 bit identification of the QoS Model. 32 bit identification of the QoS Model.
SII for each upstream and downstream peer SII-Handle for each upstream and downstream peer
The SII is a large identifier (minimum 128 bits) generated by the The SII-Handle is a local identifier generated by GIST and passed
QoS NSLP and passed over the API. over the API. It is a handle that allows to refer to a particular
GIST next hop. See SII-Handle in [I-D.ietf-nsis-ntlp] for more
information.
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 the List of RII for outstanding responses with processing information the
skipping to change at page 42, line 35 skipping to change at page 45, line 37
5.2.3. Standard Message Processing Rules 5.2.3. Standard Message Processing Rules
If a mandatory object is missing from a message then the receiving If a mandatory object is missing from a message then the receiving
QNE MUST NOT propagate the message any further. It MUST construct an QNE MUST NOT propagate the message any further. It MUST construct an
RESPONSE message indicating the error condition and send it back to RESPONSE message indicating the error condition and send it back to
the peer QNE that sent the message. the peer QNE that sent the message.
If a message contains an object of an unrecognised type, then the If a message contains an object of an unrecognised type, then the
behaviour depends on the object type value. The usual operation is to behaviour depends on the object type value. The usual operation is to
skip unknown objects. See the GIMPS specification for more skip unknown objects. See the GIST specification for more
information. information.
5.2.4. Retransmissions
QoS-NSLP messages for which a response is requested but fail to
elicit a response are retransmitted. The initial retransmission
occurs after a QOSNSLP_REQUEST_RETRY wait period. Retransmissions
MUST be made with exponentially increasing wait intervals (doubling
the wait each time). QoS-NSLP messages should be retransmitted until
either a response (which might be an error) has been obtained, or
until QOSNSLP_RETRY_MAX seconds after the initial transmission.
QOSNSLP_REQUEST_RETRY: 2 seconds Wait interval before initial
retransmit of the message
QOSNSLP_RETRY_MAX: 30 seconds Give up retrying to send the
message
5.3. Object Processing 5.3. Object Processing
5.3.1. Reservation Sequence Number (RSN) 5.3.1. Reservation Sequence Number (RSN)
A QNE's own RSN is a sequence number which applies to a particular A QNE's own RSN is a sequence number which applies to a particular
NSIS signalling session (i.e. with a particular GIMPS SESSION_ID). NSIS signalling session (i.e. with a particular GIMPS SESSION_ID).
It MUST be incremented for each new RESERVE message where the It MUST be incremented for each new RESERVE message where the
reservation for the session changes. Once the RSN has reached its reservation for the session changes. The RSN is manipulated using the
maximum value, the next value it takes is zero. serial number arithmetic rules from [RFC1982], which also defines
wrapping rules and the meaning of 'equals', 'less than' and 'greater
than' for comparing sequence numbers in a circular sequence space.
The RSN object also contains an Epoch Identifier, which provides a
method for determining when a peer has restarted (e.g. due to node
reboot or software restart). The exact method for providing this
value is implementation defined. Options include storing a serial
number which is incremented on each restart, picking a random value
on each restart or using the restart time.
On receiving a RESERVE message a QNE examines the Epoch Identifier to
determine if the peer sending the message has restarted. If the Epoch
Identifier is different to that stored for the reservation then the
RESERVE message MUST be treated as an updated reservation (even if
the RSN is less than the current stored value), and the stored RSN
and Epoch Identifier MUST be updated to the new values.
When receiving a RESERVE message a QNE uses the RSN given in the When receiving a RESERVE message a QNE uses the RSN given in the
message to determine whether the state being requested is different message to determine whether the state being requested is different
to that already stored. If the RSN is the same as for the current to that already stored. If the RSN is equal to that stored for the
reservation the current state MUST be refreshed. If the RSN is current reservation the current state MUST be refreshed. If the RSN
greater than the current stored value, the current reservation MUST is greater than the current stored value, the current reservation
be modified appropriately (provided that admission control and policy MUST be modified appropriately (provided that admission control and
control succeed), and the stored RSN value updated to that for the policy control succeed), and the stored RSN value updated to that for
new reservation. If the RSN is less than the current value, then it the new reservation. If the RSN is less than the current value, then
indicates an out-of-order message and the RESERVE message MUST be it indicates an out-of-order message and the RESERVE message MUST be
discarded. discarded.
If the QNE does not store per-session state (and so does not keep any If the QNE does not store per-session state (and so does not keep any
previous RSN values) then it MAY ignore the value of the RSN. It 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 MUST also copy the same RSN into the RESERVE message (if any) it
sends as a consequence of receiving this one. sends as a consequence of receiving this one.
5.3.2. Request Identification Information (RII) 5.3.2. Request Identification Information (RII)
A QNE sending some types of messages may require a response to be A QNE sending some types of messages may require a response to be
sent. It does so by including a Request Identification Information sent. It does so by including a Request Identification Information
(RII) object. When creating an RII object the QNE MUST select the (RII) object. When creating an RII object the QNE MUST select the
value for the RII such that it is probabilistically unique within the value for the RII such that it is probabilistically unique within the
given session. A RII object is typically set by the QNI. given session. A RII object is typically set by the QNI.
A number of choices are available when implementing this. A number of choices are available when implementing this.
Possibilities might include using a totally random value, or a node Possibilities might include using a totally random value, or a node
identifier together with a counter. If the value is selected by identifier together with a counter. If the value collides with one
another QNE then RESPONSE messages may be incorrectly terminated, and selected by another QNE for a different QUERY then RESPONSE messages
not passed back to the node that requested them. may be incorrectly terminated, and not passed back to the node that
requested them.
When sending a message containing an RII object the sending node MUST The node that created the RII object MUST remember the value used in
remember the value used in the RII to match back any RESPONSE the RII to match back any RESPONSE it will receive. The node SHOULD
received. It SHOULD use a timer to identify situations where it has use a timer to identify situations where it has taken too long to
taken too long to receive the expected RESPONSE. If the timer receive the expected RESPONSE. If the timer expires without receiving
expires without receiving a RESPONSE it MAY perform a retransmission. a RESPONSE it MAY perform a retransmission as discussed in Section
5.2.4.
[FIXME: how is the retransmission actually handled? Exponential If an intermediate QNE wants to request a response for an outgoing
timeout, number of retransmissions, what to do when no replies ever message, but the message already included an RII when it arrive, the
come back? A new error type? Need to look at e.g. Seamoby documents, QNE must not add a new RII object nor replace the old RII object, but
how they specify these...:)] may simply remember that RII to match the related RESPONSE it is
interested in later. When it receives the RESPONSE, it forwards the
RESPONSE upstream towards the RII originating node. Note that only
the node that originally created the RII can set up a retransmission
timer. Thus, if an intermediate QNE decides to use the RII already
contained in the message, it MUST NOT set up a retransmission timer,
but rely on the retransmission timer set up by the QNE that inserted
the RII.
When receiving a message containing an RII object the node MUST send When receiving a message containing an RII object the node MUST send
a RESPONSE if either a RESPONSE if either
o The SCOPING flag is set to one ('next hop' scope), or o The SCOPING flag is set to one ('next hop' scope), or
o This QNE is the last one on the path for the given session. 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. and the QNE keeps per-session state for the given session.
A message contains at most one RII object that is unique within a A message contains at most one RII object that is unique within a
session and different for each message, in order to allow responses session and different for each message, in order to allow responses
to be matched back to requests (without incorrectly matching at other to be matched back to requests (without incorrectly matching at other
nodes). Downstream nodes that desire responses may keep track of nodes). Downstream nodes that desire responses may keep track of
this RII to identify the RESPONSE when it passes back through them. this RII to identify the RESPONSE when it passes back through them.
In the rare event that the QNE wants to request a response for a
message that already included an RII, and this RII value conflicts
with an existing RII value on the QNE, the node should interrupt the
processing the message, and send an error message upstream to
indicate an RII collision, and request a retry with a new RII value.
5.3.3. BOUND_SESSION_ID 5.3.3. BOUND_SESSION_ID
As shown in the examples in Section 4, the QoS NSLP can relate As shown in the examples in Section 4, the QoS NSLP can relate
multiple sessions together. It does this by including the SESSION_ID multiple sessions together. It does this by including the SESSION_ID
from one session in a BOUND_SESSION_ID object in messages in another from one session in a BOUND_SESSION_ID object in messages in another
session. session.
When receiving a message with a BOUND_SESSION_ID object, a QNE MUST When receiving a message with a BOUND_SESSION_ID object, a QNE MUST
copy the BOUND_SESSION_ID object into all messages it sends for the copy the BOUND_SESSION_ID object into all messages it sends for the
same session. A QNE that stores per-session state MUST store the same session. A QNE that stores per-session state MUST store the
skipping to change at page 46, line 8 skipping to change at page 50, line 5
6. To improve robustness, a node may temporarily send refreshes 6. To improve robustness, a node may temporarily send refreshes
more often than R after a state change (including initial state more often than R after a state change (including initial state
establishment). establishment).
7. The values of Rdef, K, and Slew.Max used in an implementation 7. The values of Rdef, K, and Slew.Max used in an implementation
should be easily modifiable per interface, as experience may lead should be easily modifiable per interface, as experience may lead
to different values. The possibility of dynamically adapting K to different values. The possibility of dynamically adapting K
and/or Slew.Max in response to measured loss rates is for future and/or Slew.Max in response to measured loss rates is for future
study. study.
5.3.5. ERROR_SPEC 5.3.5. INFO_SPEC
[FIXME SOMETIME] [FIXME: INFO_SPEC processing rules are still to be defined in more
detail.]
ERROR_SPEC processing rules are still to be defined in more detail. We must make a distinction between INFO_SPEC messages used to provide
non-fatal information, and fatal error messages. Error messages must
be generated even if no RII is included in the incoming message.
5.3.6. QSPEC 5.3.6. QSPEC
The contents of the QSPEC depends on the QoS model being used. It The contents of the QSPEC depends on the QoS model being used. There
may be that parts of the QSPEC are standardised across multiple QoS is ongoing work to standardised parts of the QSPEC across multiple
models. This topic is currently under further study. QoS models [QoS-Template].
[FIXME ONCE THIS IS DONE]
Upon reception, the complete QSPEC is passed to the Resource Upon reception, the complete QSPEC is passed to the Resource
Management Function (RMF), along with other information from the Management Function (RMF), along with other information from the
message necessary for the RMF processing. message necessary for the RMF processing.
A QNE that receives a QSPEC stack MUST only look at the top QSPEC in A QNE that receives a QSPEC stack MUST only look at the top QSPEC in
the stack. If this QSPEC is not understood by the RMF, the QNE MUST the stack. If this QSPEC is not understood by the RMF, the QNE MUST
send an RESPONSE containing an ERROR_SPEC and MUST NOT attempt to send an RESPONSE containing an INFO_SPEC and MUST NOT attempt to
recover by inspecting the rest of the stack. recover by inspecting the rest of the stack.
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 per- When a domain wants to apply a certain QoS Model to an incoming per-
flow reservation request, each edge of the domain is configured to flow reservation request, each edge of the domain is configured to
skipping to change at page 47, line 4 skipping to change at page 50, line 48
object onto the stack of QSPEC objects (typically immediately 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). is found in the message).
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) MUST object (e.g. by configuration of the egress QNEs of a domain) MUST
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.
5.4. Message Processing Rules 5.4. Message Processing Rules
This section provides rules for message processing. Not all possible
error situation are considered. A general rule for dealing with
erroneous messages is that a node should evaluate the situation
before deciding how to react. There are two ways to react to
erroneous messages:
a) Silently drop the message, or
b) Drop the message, and reply with an error code the sender.
The default behavior, in order to protect the QNE from a possible DoS
attack, is to silently drop the message. However, if the QNE is able
to authenticate the sender, e.g., through GIST, the QNE may send a
proper error message back to sender in order to let it know that
there is an inconsistency in the states of adjacent QNEs.
Yet, there is a third possible mode of operation when receiving an
unexpected or erroneous message. The QNE may consider the incoming
message as fully accpetable, and operate as if there was no error in
the processing. This may happen, for example, if the QNE knowns it
has just rebooted and has lost its signaling states. Now, the QNE may
try to act as if "nothing happened". Note that an implementation must
carefully consider this behavior.
5.4.1. RESERVE Messages 5.4.1. RESERVE Messages
The RESERVE message is used to manipulate QoS reservation state in The RESERVE message is used to manipulate QoS reservation state in
QNEs. A RESERVE message may create, refresh, modify or remove such QNEs. A RESERVE message may create, refresh, modify or remove such
state. The format of a RESERVE message is repeated here for state. The format of a RESERVE message is repeated here for
convenience: convenience:
RESERVE = COMMON_HEADER RESERVE = COMMON_HEADER
RSN PACKET_CLASSIFIER [ RII ] RSN PACKET_CLASSIFIER [ RII ]
[ REFRESH_PERIOD ] [ BOUND_SESSION_ID ] [ REFRESH_PERIOD ] [ BOUND_SESSION_ID ]
[ POLICY_DATA ] *2QSPEC [ POLICY_DATA ] *2QSPEC
RESERVE messages MUST only be sent towards the QNR. RESERVE messages MUST only be sent towards the QNR.
A QNE that receives a RESERVE message checks the message format. In A QNE that receives a RESERVE message checks the message format. In
case of malformed messages, the QNE sends a RESPONSE message with the case of malformed messages, the QNE MAY send a RESPONSE message with
appropriate ERROR_SPEC. the appropriate INFO_SPEC.
Before performing any state changing actions a QNE MUST determine Before performing any state changing actions a QNE MUST determine
whether the request is authorized. It SHOULD exercise its local whether the request is authorized. It SHOULD exercise its local
policy in conjunction with the POLICY_DATA object to do this. policy in conjunction with the POLICY_DATA object to do this.
When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags. When the RESERVE is authorized, a QNE checks the COMMON_HEADER flags.
If the TEAR flag is set, the message is a tearing RESERVE which If the TEAR flag is set, the message is a tearing RESERVE which
indicates complete QoS NSLP state removal (as opposed to a indicates complete QoS NSLP state removal (as opposed to a
reservation of zero resources). On receiving such a RESERVE message reservation of zero resources). On receiving such a RESERVE message
the QNE MUST inform the RMF that the reservation is no longer the QNE MUST inform the RMF that the reservation is no longer
required. The QNE SHOULD remove the QoS NSLP state. It MAY signal required. The QNE SHOULD remove the QoS NSLP state. It MAY signal to
to GIMPS (over the API) that reverse path state for this reservation GIST (over the API) that reverse path state for this reservation is
is no longer required. If the message does not match any existing no longer required. Depending on the QoS model, the tear message may
session it MUST be dropped. If the QNE has reservations which are include a QSPEC to further specify state removal. If the QoS model
bound to this session (they contained the SESSION_ID of this session requires a QSPEC, and none is provided, the QNE should reply with an
in their BOUND_SESSION_ID object), it MUST send a NOTIFY message for error message, and not remove the reservation. If the tearing
each of these reservations with an appropriate ERROR_SPEC. The QNE RESERVE includes a QSPEC, but none is required by the QoS model, the
MAY elect to send RESERVE messages with the TEAR flag set for these QNE may silently discard the QSPEC and proceed as if it did not exit
reservations. in the message.
If the QNE has reservations which are bound to this session (they
contained the SESSION_ID of this session in their BOUND_SESSION_ID
object), it MUST send a NOTIFY message for each of these reservations
with an appropriate INFO_SPEC. The QNE MAY elect to send RESERVE
messages with the TEAR flag set for these reservations.
The default behaviour of a QNE that receives a RESERVE with a The default behaviour of a QNE that receives a RESERVE with a
SESSION_ID for which it already has state installed but 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 different flow ID is to replace the existing reservation (and tear
down the reservation on the old branch if the RESERVE is received down the reservation on the old branch if the RESERVE is received
with a different SII). with a different SII).
In some cases, this may not be the desired behaviour. In that case, In some cases, this may not be the desired behaviour. In that case,
the QNI or a QNE may set the REPLACE flag in the common header to the QNI or a QNE may set the REPLACE flag in the common header to
zero to indicate that the new session does not replace the existing zero to indicate that the new session does not replace the existing
one. A QNE that receives a RESERVE with the REPLACE flag set to zero one.
but with the same SII will update the flow ID and indicate REPLACE=0
to the RMF (where it will be used for the resource handling). If the A QNE that receives a RESERVE with the REPLACE flag set to zero but
SII is different, this means that the QNE is a merge point. In that with the same SII, will indicate REPLACE=0 to the RMF (where it will
case, the REPLACE=0 also indicates that a tearing RESERVE SHOULD NOT be used for the resource handling). Furthermore, if the QNE mainains
be sent on the old branch. a QoS-NSLP state then it will also add the new flow ID in the QoS-
NSLP state. If the SII is different, this means that the QNE is a
merge point. In that case, in addition to the operations specified
above, the value REPLACE=0 is also indicating that a tearing RESERVE
SHOULD NOT be sent on the old branch.
When a QNE receives a RESERVE message with an unknown SESSION_ID, it When a QNE receives a RESERVE message with an unknown SESSION_ID, it
MAY send a NOTIFY message to its upstream peer, indicating the MAY send a NOTIFY message to its upstream peer, indicating the
unknown SESSION_ID. If the message was meant as a refresh, the reply unknown SESSION_ID. If the message was meant as a refresh, the reply
indicates a downstream route change to the upstream peer. The indicates a downstream route change to the upstream peer. The
upstream peer SHOULD send a complete RESERVE on the new path (new upstream peer SHOULD send a complete RESERVE on the new path (new
SII). It identifies the old signalling association (old SII) and MAY SII). It identifies the old signalling association (old SII) and MAY
start sending complete RESERVE messages for other SESSION_IDs linked start sending complete RESERVE messages for other SESSION_IDs linked
to this association. to this association.
skipping to change at page 48, line 37 skipping to change at page 53, line 10
all. This is the case of a reduced refresh. In this case, rather all. This is the case of a reduced refresh. In this case, rather
than sending a refreshing RESERVE with the full QSPEC, only the than sending a refreshing RESERVE with the full QSPEC, only the
SESSION_ID and the SII are sent to refresh the reservation. Note SESSION_ID and the SII are sent to refresh the reservation. Note
that this mechanism just reduces the message size (and probably eases that this mechanism just reduces the message size (and probably eases
processing). One RESERVE per session is still needed. processing). One RESERVE per session is still needed.
If the REPLACE flag is set, the QNE SHOULD update the reservation If the REPLACE flag is set, the QNE SHOULD update the reservation
state according to the QSPEC contained in the message. It MUST state according to the QSPEC contained in the message. It MUST
update the lifetime of the reservation. If the REPLACE flag is not update the lifetime of the reservation. If the REPLACE flag is not
set, a QNE SHOULD NOT remove the old reservation state if the SII set, a QNE SHOULD NOT remove the old reservation state if the SII
which is passed by GIMPS over the API is different than the SII that which is passed by GIST over the API is different than the SII that
was stored for this reservation. The QNE MAY elect to keep sending was stored for this reservation. The QNE MAY elect to keep sending
refreshing RESERVE messages. refreshing RESERVE messages.
If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state If the ACKNOWLEDGE flag is set, the QNE MUST acknowledge its state
installation action. It does so by sending a RESPONSE with an installation action. It does so by sending a RESPONSE with an
ERROR_SPEC indicating that the reservation is installed at the QNE. INFO_SPEC indicating that the reservation is installed at the QNE.
If the SCOPING flag is set, or if the QNE is the last QNE on the path If the SCOPING flag is set, or if the QNE is the last QNE on the path
to the destination, the QNE MUST send a RESPONSE message. to the destination, the QNE MUST send a RESPONSE message.
When a QNE receives a RESERVE message, its processing may involve When a QNE receives a RESERVE message, its processing may involve
sending out another RESERVE message. When sending a RESERVE message, sending out another RESERVE message. When sending a RESERVE message,
the QNE may insert or remove 'local' QSPEC objects from the message. the QNE may insert or remove 'local' QSPEC objects from the message.
If any QSPEC is present, the first QSPEC MUST NOT be removed when If any QSPEC is present, the first QSPEC MUST NOT be removed when
sending on the RESERVE message. sending on the RESERVE message.
skipping to change at page 49, line 12 skipping to change at page 53, line 40
refresh message (i.e. a RESERVE with a non-incremented RSN and no refresh message (i.e. a RESERVE with a non-incremented RSN and no
QSPEC) unless it has received a RESPONSE message for that RESERVE QSPEC) unless it has received a RESPONSE message for that RESERVE
message. message.
If the session of this message is bound to another session, then the 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 RESERVE message MUST include the SESSION_ID of that other session in
a BOUND_SESSION_ID object. a BOUND_SESSION_ID object.
In case of receiver-initiated reservations, the RESERVE message must In case of receiver-initiated reservations, the RESERVE message must
follow the same path that has been followed by the QUERY message. follow the same path that has been followed by the QUERY message.
Therefore, GIMPS is informed, over the QoS NSLP/GIMPS API, to pass Therefore, GIST is informed, over the QoS NSLP/GIST API, to pass the
the message upstream, i.e., by setting GIMPS "D" flag, see GIMPS [I- message upstream, i.e., by setting GIST "D" flag, see GIST [I-D.ietf-
D.ietf-nsis-ntlp]. nsis-ntlp].
The QNE must create a new RESERVE and send it to its next peer, when: The QNE must create a new RESERVE and send it to its next peer, when:
- A new resource set up was done, - A new resource set up was done,
- A new resource set up was not done, but the QOSM still defines that - A new resource set up was not done, but the QOSM still defines that
a RESERVE must be propagated, a RESERVE must be propagated,
- The RESERVE is a refresh and includes new MRI, or - The RESERVE is a refresh and includes new MRI, or
- If the F-bit is set. - If the R-bit is included in an arrived QUERY.
[FIXME: what other situations are there?]
5.4.2. QUERY Messages 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
certain QoS models. certain QoS models.
The format of a QUERY message is as follows: The format of a QUERY message is as follows:
QUERY = COMMON_HEADER QUERY = COMMON_HEADER
[ RII ] PACKET_CLASSIFIER [ BOUND_SESSION_ID ] [ RII ] PACKET_CLASSIFIER [ BOUND_SESSION_ID ]
[ POLICY_DATA ] *2QSPEC [ POLICY_DATA ] *2QSPEC
When a QNE receives a QUERY message the QSPEC is passed to the RMF When a QNE receives a QUERY message the QSPEC is passed to the RMF
for processing. The RMF may return a modified QSPEC which is used in for processing. The RMF may return a modified QSPEC which is used in
any QUERY or RESPONSE message sent out as a result of the QUERY any QUERY or RESPONSE message sent out as a result of the QUERY
processing. processing.
When processing a QUERY message, a QNE checks whether an RII object When processing a QUERY message, a QNE checks whether the R-bit is
is present. If not, the QUERY is an empty QUERY which is used to set. If the bit is set, the QUERY is used to install reverse path
install reverse path state. In this case, if the QNE is not the QNR, state. In this case, if the QNE is not the QNR, it creates a new
it creates a new QUERY message to send downstream. If the QUERY QUERY message to send downstream. If the QUERY contained a QSPEC,
contained a QSPEC, this MUST be passed to the RMF where it MAY be this MUST be passed to the RMF where it MAY be modified by QoS Model
modified by QoS Model specific QUERY processing. If the QNE is the specific QUERY processing. If the QNE is the QNR, the QNE creates a
QNR, the QNE creates a RESERVE message, which contains a QSPEC RESERVE message, which contains a QSPEC received from the RMF and
received from the RMF and which MAY be based on the received QSPEC. which MAY be based on the received QSPEC. If this node was not
If this node was not expecting to perform a receiver-initiated expecting to perform a receiver-initiated reservation then an error
reservation then an error MUST be sent back along the path. MUST be sent back along the path.
If an RII object is present, and if the QNE is the QNR or the SCOPING If an RII object is present, and if the QNE is the QNR or the SCOPING
flag is set, the QNE MUST generate a RESPONSE message and pass it flag is set, the QNE MUST generate a RESPONSE message and pass it
back along the reverse of the path used by the QUERY. back along the reverse of the path used by the QUERY.
In other cases, the QNE MUST generate a QUERY message which is then In other cases, the QNE MUST generate a QUERY message which is then
forwarded further along the path using the same MRI, Session ID and forwarded further along the path using the same MRI, Session ID and
Direction as provided when the QUERY was received over the GIMPS API. Direction as provided when the QUERY was received over the GIST API.
The QSPEC to be used is that provided by the RMF as described The QSPEC to be used is that provided by the RMF as described
previously. When generating a QUERY to send out to pass the query previously. When generating a QUERY to send out to pass the query
further along the path, the QNE MUST copy the RII object (if present) further along the path, the QNE MUST copy the RII object (if present)
into the new QUERY message unchanged. A QNE that is also interested into the new QUERY message unchanged. A QNE that is also interested
in the response to the query keeps track of the RII to identify the in the response to the query keeps track of the RII to identify the
RESPONSE when it passes through it. RESPONSE when it passes through it.
Note that QUERY messages with the R-bit set should always be answered
by the QNR. This feature may be used, e.g., following handovers, to
set up new path state in GIST, and request the other party to send a
RESERVE back on this new GIST path.
5.4.3. 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 of a reservation or of a previous QoS NSLP message, e.g. confirmation of a reservation or
information resulting from a query. The RESPONSE message is information resulting from a query. The RESPONSE message is
impotent, 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 repeated here for convenience: The format of a RESPONSE message is repeated here for convenience:
RESPONSE = COMMON_HEADER RESPONSE = COMMON_HEADER
[ RII / RSN ] PACKET_CLASSIFIER [ RII / RSN ] PACKET_CLASSIFIER
ERROR_SPEC *2QSPEC INFO_SPEC *2QSPEC
A RESPONSE message MUST be sent where the QNE is the last node to A RESPONSE message MUST be sent where the QNE is the last node to
process a RESERVE or QUERY message containing an RII object (based on process a RESERVE or QUERY message containing an RII object (based on
scoping of the RESERVE or QUERY, or because this is the last node on scoping of the RESERVE or QUERY, or because this is the last node on
the path). In this case, the RESPONSE MUST copy the RII object from the path). In this case, the RESPONSE MUST copy the RII object from
the RESERVE or QUERY. the RESERVE or QUERY.
In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE In addition, a RESPONSE message MUST be sent when the ACKNOWLEDGE
flag is set or when an error occurs while processing a received flag is set or when an error occurs while processing a received
message. If the received message contains an RII object, this object message. If the received message contains an RII object, this object
MUST be put in the RESPONSE, as described above. If the RESPONSE is 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 an RII sent as a result of the receipt of a RESERVE message without an RII
object, then the RSN of the received RESERVE message MUST be copied object, then the RSN of the received RESERVE message MUST be copied
into the RESPONSE message. into the RESPONSE message.
On receipt of a RESPONSE message containing an RII object, the QNE On receipt of a RESPONSE message containing an RII object, the QNE
MUST attempt to match it to the outstanding response requests for MUST attempt to match it to the outstanding response requests for
that signalling session. If the match succeeds, then the RESPONSE that signalling session. If the match succeeds, then the RESPONSE
MUST NOT be forwarded further along the path. If the match fails, MUST NOT be forwarded further along the path. If the QNE did not
then the QNE MUST attempt to forward the RESPONSE to the next peer insert this RII itself, if must forward the RESPONSE to the next
QNE. peer. Thus, forwarding should only stop if the QNE inserted the RII
by itself.
On receipt of a RESPONSE message containing an RSN object, the QNE On receipt of a RESPONSE message containing an RSN object, the QNE
MUST compare the RSN to that of the appropriate signalling session. MUST compare the RSN to that of the appropriate signalling session.
If the match succeeds then the ERROR_SPEC MUST be processed. The If the match succeeds then the INFO_SPEC MUST be processed. The
RESPONSE message MUST NOT be forwarded further along the path whether RESPONSE message MUST NOT be forwarded further along the path whether
or not the match succeeds. or not the match succeeds. If there is no match for RSN, the message
should be silently dropped.
On receipt of a RESPONSE message containing neither an RII nor an RSN
object, the RESPONSE MUST NOT be forwarded further along the path.
In the typical case RESPONSE messages do not change the states
installed in intermediate QNEs. However, depending on the QoS model,
there may be situations where states are affected, e.g.,
- if the RESPONSE includes an INFO_SPEC describing an error situation
resulting in reservations to be removed, or
- the QoS model allows a QSPEC to define [min,max] limits on the
resources requested, and downstream QNEs gave less resources than
their upstrem nodes, which means that the upstream nodes may
release a
part of the resource reservation.
5.4.4. NOTIFY Messages 5.4.4. NOTIFY Messages
NOTIFY messages are used to convey information to a QNE NOTIFY messages are used to convey information to a QNE
asynchronously. The format of a NOTIFY message is as follows: asynchronously. The format of a NOTIFY message is as follows:
NOTIFY = COMMON_HEADER NOTIFY = COMMON_HEADER
PACKET_CLASSIFIER ERROR_SPEC *2QSPEC PACKET_CLASSIFIER INFO_SPEC *2QSPEC
NOTIFY messages are impotent. They do not cause any state to be NOTIFY messages are impotent. They do not cause any state to be
installed or modified and they do do not directly cause other installed. However, if the notification indicates an error, the
messages to be sent. NOTIFY messages are sent asynchronously, rather indicated state may be removed. The exact operation depends on the
than in response to other messages. They may be sent in either QoS model. NOTIFY message do do not directly cause other messages to
direction (upstream or downstream). be sent. NOTIFY messages are sent asynchronously, rather than in
response to 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 QoS Authority (IANA) regarding registration of values related to the QoS
NSLP, in accordance with BCP 26 RFC 2434 [RFC2434]. NSLP, in accordance with BCP 26 RFC 2434 [RFC2434].
The QoS NSLP requires IANA to create a number of new registries. The QoS NSLP requires IANA to create a number of new registries.
The QoS NSLP Message Type is a 16 bit value. The allocation of The QoS NSLP Message Type is a 16 bit value. The allocation of
skipping to change at page 52, line 32 skipping to change at page 56, line 54
specification defines four QoS NSLP message types, which form the specification defines four QoS NSLP message types, which form the
initial contents of this registry: RESERVE, QUERY, RESPONSE and initial contents of this registry: RESERVE, QUERY, RESPONSE and
NOTIFY. NOTIFY.
QoS NSLP Messages have a messages-specific 16 bit flags/reserved QoS NSLP Messages have a messages-specific 16 bit flags/reserved
field in their header. The allocation policy for new flags is TBD. field in their header. The allocation policy for new flags is TBD.
The QoS Model Identifier (QoS Model ID) is carried in a QSPEC object. The QoS Model Identifier (QoS Model ID) is carried in a QSPEC object.
The allocation policy for new QoS Model IDs is TBD. The allocation policy for new QoS Model IDs is TBD.
This specification defines a NSLP for use with GIMPS. Consequently, This specification defines a NSLP for use with GIST. Consequently, a
a new identifier must be assigned for it from GIMPS NSLP Identifier new identifier must be assigned for it from GIST NSLP Identifier
registry. registry.
This document also defines six new objects for the QoS NSLP: RII, This document also defines six new objects for the QoS NSLP: RII,
RSN, REFRESH_PERIOD, BOUND_SESSION_ID, PACKET_CLASSIFIER, QSPEC and RSN, REFRESH_PERIOD, BOUND_SESSION_ID, PACKET_CLASSIFIER, QSPEC and
ERROR_SPEC. Values are to be assigned for them from NSLP Object Type INFO_SPEC. Values are to be assigned for them from NSLP Object Type
registry. registry.
In addition it defines a number of Error Codes for the QoS NSLP. In addition it defines a number of Error Codes for the QoS NSLP.
These can be found in Section 5.1.3.6 and are to be assigned values These can be found in Section 5.1.3.6 and are to be assigned values
from NSLP Error Code registry. from NSLP Error Code registry.
Further consideration of IANA issues can be found in a separate draft Further consideration of IANA issues can be found in a separate draft
[I-D.loughney-nsis-ext]. [I-D.loughney-nsis-ext].
7. QoS use of GIMPS service interface 7. QoS use of GIST service interface
This section describes the use of GIMPS service interface to This section describes the use of GIST service interface to implement
implement QoS NSLP requirements on GIMPS. QoS NSLP requirements on GIST.
7.1. Example sender-initiated reservation 7.1. Example sender-initiated reservation
We first describe the use of the service interface in a very basic We first describe the use of the service interface in a very basic
scenario: message reception and transmission for a RESERVE message in scenario: message reception and transmission for a RESERVE message in
a sender-initiated reservation. a sender-initiated reservation.
A QNE that wishes to initiate a sender-initiated reservation A QNE that wishes to initiate a sender-initiated reservation
constructs a new RESERVE message to send downstream. The use of constructs a new RESERVE message to send downstream. The use of GIST
GIMPS service interface in this case is explained on Figure 35. Note service interface in this case is explained on Figure 35. Note that
that we assume the SII handling in GIMPS [I-D.ietf-nsis-ntlp] is we assume the SII handling in GIST [I-D.ietf-nsis-ntlp] is extended
extended to distinguish between own and peer SII. to distinguish between own and peer SII.
GIMPS QoS NSLP GIST QoS NSLP
| | | |
|<=====================================| |<=====================================|
| SendMessage{ | | SendMessage{ |
| NSLP-Data=RESERVE, | | NSLP-Data=RESERVE, |
| Retain-State=TRUE, | | Retain-State=TRUE, |
| Size=X bytes, | | Size=X bytes, |
| Message-Handle=NULL, | | Message-Handle=NULL, |
| NSLP-ID=QoS, | | NSLP-ID=QoS, |
| Session-ID=SID_X, | | Session-ID=SID_X, |
| MRI=MRI, | | MRI=MRI, |
| Direction=downstream, | | Direction=downstream, |
| Own-SII-Handle=Own_SII_X, | | Own-SII-Handle=empty, |
| Peer-SII-Handle=empty | | Peer-SII-Handle=empty |
| Transfer-attributes=default, | | Transfer-attributes=default, |
| Timeout=default, | | Timeout=default, |
| IP-TTL=default} | | IP-TTL=default} |
| | | |
Figure 35: GIMPS service interface usage for Figure 35: GIST service interface usage for
sending a sender-initiated reservation sending a sender-initiated reservation
Note that an explicit preference for a particular type of transport, Note that an explicit preference for a particular type of transport,
such as reliable/unreliable, may change the values of some service such as reliable/unreliable, may change the values of some service
interface parameters (e.g. Transfer-attributes=unreliable). interface parameters (e.g. Transfer-attributes=unreliable).
The message is received by the peer QNE. The use of GIMPS service The message is received by the peer QNE. The use of GIST service
interface when receiving a RESERVE message for a sender-initiated interface when receiving a RESERVE message for a sender-initiated
reservation is explained on Figure 36. reservation is explained on Figure 36.
GIMPS QoS NSLP GIST QoS NSLP
| | | |
|=====================================>| |=====================================>|
| RecvMessage{ | | RecvMessage{ |
| NSLP-Data=RESERVE, | | NSLP-Data=RESERVE, |
| Size=X bytes, | | Size=X bytes, |
| Message-Handle=GIMPS_X, | | Message-Handle=GIST_X, |
| NSLP-ID=QoS, | | NSLP-ID=QoS, |
| Session-ID=SID_X, | | Session-ID=SID_X, |
| MRI=MRI, | | MRI=MRI, |
| Direction=downstream, | | Direction=downstream, |
| Peer-SII-Handle=UP_SII_X, | | Peer-SII-Handle=UP_SII_X, |
| Transfer-attributes=default, | | Transfer-attributes=default, |
| IP-TTL=TTL_X, | | IP-TTL=TTL_X, |
| Original-TTL=TTL_Y} | | Original-TTL=TTL_Y} |
| | | |
|<=====================================| |<=====================================|
| MessageReceived{ | | MessageReceived{ |
| Message-Handle=GIMPS_X, | | Message-Handle=GIST_X, |
| Retain-State=TRUE | | Retain-State=TRUE |
| | | |
Figure 36: GIMPS service interface usage for message Figure 36: GIST service interface usage for message
reception of sender-initiated reservation reception of sender-initiated reservation
7.2. Session identification 7.2. 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. On Figure 35, QoS NSLP picks a value SID_X path through the network. On Figure 35, QoS NSLP picks a value SID_X
for Session-ID. This value is subsequently used by GIMPS and QoS for Session-ID. This value is subsequently used by GIST and QoS NSLP
NSLP to refer to this session. to refer to this session.
7.3. Support for bypassing intermediate nodes 7.3. Support for bypassing intermediate nodes
[FIXME: WHAT IS THE FINAL MECHANISM TO BYPASS 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 3.2.8), when only the edge QNEs of a domain (explained in Section 3.2.8), when only the edge QNEs of a domain
process the message. This requires a mechanism at GIMPS level (which process the message. This requires a mechanism at GIMPS level (which
can be invoked by the QoS NSLP) to bypass intermediates nodes between can be invoked by the QoS NSLP) to bypass intermediates nodes between
the edges of the domain. the edges of the domain.
As a suggestion, we identified two ways for bypassing intermediate The intermediate nodes are bypassed using multiple levels of the
nodes. One solution is for the end-to-end session to carry a router alert option. In that case, internal routers are configured to
different protocol ID (QoS NSLP-E2E-IGNORE protocol ID, similar to handle only certain levels of router alerts. This is accomplished by
the RSVP-E2E-IGNORE that is used for RSVP aggregation (RFC 3175 marking the signaling messages, i.e., modifying the QoS-NSLP default
[RFC3175]). Another solution is based on the use of multiple levels NSLP-ID value to another NSLP-ID predefined value. The marking MUST
of the router alert option. In that case, internal routers are be accomplished by the ingress edge by modifying the QoS-NSLP default
configured to handle only certain levels of router alerts. The NSLP-ID value to a NSLP-ID predefined value. The egress MUST stop
choice between both approaches or another approach that fulfills the this marking process by reassigning the QoS-NSLP default NSLP-ID
requirement is left to GIMPS design. value to the original RESERVE message. The exact operation of
modifying the NSLP-ID must be specified in the relevant QoS model
specification.
7.4. Support for peer change identification 7.4. 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 signalling identify the adjacent QNE peer, which is the source of a signalling
application message; e.g., it may be to apply the policy that "state application message; e.g., it may be to apply the policy that "state
can only be modified by messages from the node that created it" or it 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 (fallback) might be that keeping track of peer identity is used as a (fallback)
mechanism for rerouting detection at the NSLP layer. mechanism for rerouting detection at the NSLP layer.
This functionality is implemented in GIMPS service interface with This functionality is implemented in GIST service interface with SII-
SII-handle. As shown in the above example, we assume the SII- handle. As shown in the above example, we assume the SII- handling
handling will support both own SII and peer SII. will support both own SII and peer SII.
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 means for the QoS NSLP to detect route changes. When a QNE receives
a 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 knows that its upstream peer has changed. It can then use the old
SII to initiate a teardown along the old section of the path. This SII to initiate a teardown along the old section of the path. This
functionality is supported in GIMPS service interface when the peer's functionality is supported in GIST service interface when the peer's
SII which is stored on message reception is passed to GIMPS upon SII which is stored on message reception is passed to GIST upon
message transmission. message transmission.
7.5. Support for stateless operation 7.5. 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 GIMPS level when some nodes are able to operate in a stateless way at GIST level
as well. Such nodes should not worry about keeping reverse state, as well. Such nodes should not worry about keeping reverse state,
message fragmentation and reassembly (at GIMPS), congestion control message fragmentation and reassembly (at GIST), congestion control or
or security associations. A stateless or reduced state QNE will be security associations. A stateless or reduced state QNE will be able
able to inform the underlying GIMPS of this situation. GIMPS service to inform the underlying GIST of this situation. GIST service
interface supports this functionality with the Retain-State attribute interface supports this functionality with the Retain-State attribute
in the MessageReceived primitive. in the MessageReceived primitive.
7.6. Last node detection 7.6. 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
skipping to change at page 55, line 49 skipping to change at page 60, line 19
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 o the QNE have some other prior knowledge that it should act as
the QNR the 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 o the QNE may be the last NSIS-capable node on the path
supporting the QoS NSLP supporting the QoS NSLP
Of these four conditions, the last two can only be detected by GIMPS. Of these four conditions, the last two can only be detected by GIST.
We rely on GIMPS to inform the QoS NSLP about these cases by We rely on GIST to inform the QoS NSLP about these cases by providing
providing a trigger to the QoS NSLP when it determines that it is the a trigger to the QoS NSLP when it determines that it is the last NE
last NE on the path, which supports the QoS NSLP. GIMPS supports on the path, which supports the QoS NSLP. GIST supports this by the
this by the MessageDeliverError primitive. The error type 'no next MessageDeliverError primitive. The error type 'no next node found'
node found' which is given as an example can be used. It is expected which is given as an example can be used. It is expected that
that additional error codes need to be defined. additional error codes need to be defined.
7.7. Re-routing detection 7.7. Re-routing detection
Route changes may be detected at GIMPS layer or the information may Route changes may be detected at GIST layer or the information may be
be obtained by GIMPS through local interaction with or notification obtained by GIST through local interaction with or notification from
from routing protocols or modules. GIMPS allows to pass such routing protocols or modules. GIST allows to pass such information
information over the service interface using the NetworkNotification over the service interface using the NetworkNotification primitive
primitive with the appropriate 'downstream route change' or 'upstream with the appropriate 'downstream route change' or 'upstream route
route change' notification. change' notification.
7.8. Priority of signalling messages 7.8. Priority of signalling messages
[FIXME: WHAT IS THE API?]
The QoS NSLP will generate messages with a range of performance The QoS NSLP will generate messages with a range of performance
requirements for GIMPS. These requirements may result from a requirements for GIST. These requirements may result from a
prioritization at the QoS NSLP (Section 3.2.8) or from the prioritization at the QoS NSLP (Section 3.2.9) or from the
responsiveness expected by certain applications supported by the QoS responsiveness expected by certain applications supported by the QoS
NSLP. NSLP.
GIMPS design should be able to ensure that performance for one class GIST design should be able to ensure that performance for one class
of messages was not degraded by aggregation with other classes of of messages was not degraded by aggregation with other classes of
messages. GIMPS service interface supports this with the 'priority' messages. GIST service interface supports this with the 'priority'
transfer attribute. transfer attribute.
7.9. Knowledge of intermediate QoS NSLP unaware nodes 7.9. Knowledge of intermediate QoS NSLP unaware nodes
[FIXME: IS THIS AVAILABLE? WHERE?]
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.
GIMPS should be able to provide information to the NSLP about whether GIST should be able to provide information to the NSLP about whether
the message has passed through nodes that did not provide support for the message has passed through nodes that did not provide support for
this NSLP. this NSLP.
GIMPS service interface supports this by keeping track of IP-TTL and GIST service interface supports this by keeping track of IP-TTL and
Original-TTL in the RecvMessage primitive. A difference between the Original-TTL in the RecvMessage primitive. A difference between the
two indicates the number of QoS NSLP unaware nodes. two indicates the number of QoS NSLP unaware nodes.
The QSPEC template also includes a bit "<NON QOSM Hop>" telling that
one or more QOSM-aware QNE were encountered on the path from the QNI
to the QNR [I-D.ietf-nsis-qspec].
7.10. NSLP Data Size 7.10. NSLP Data Size
When GIMPS passes the QoS NSLP data to the NSLP for processing, it When GIST passes the QoS NSLP data to the NSLP for processing, it
must also indicate the size of that data. This is supported by the must also indicate the size of that data. This is supported by the
NSLP-Data-Size attribute. NSLP-Data-Size attribute.
7.11. Notification of GIMPS 'D' flag value 7.11. Notification of GIST 'D' flag value
When GIMPS passes the QoS NSLP data to the NSLP for processing, it When GIST passes the QoS NSLP data to the NSLP for processing, it
must also indicate the value of the 'D' (Direction) flag for that must also indicate the value of the 'D' (Direction) flag for that
message. This is done in the Direction attribute of the SendMessage message. This is done in the Direction attribute of the SendMessage
and RecvMessage primitives. and RecvMessage primitives.
7.12. NAT Traversal 7.12. NAT Traversal
The QoS NSLP relies on GIMPS for NAT traversal. The QoS NSLP relies on GIST for NAT traversal.
8. Assumptions on the QoS Model 8. Assumptions on the QoS Model
8.1. Resource sharing 8.1. Resource sharing
This specification assumes that resource sharing is possible between This specification assumes that resource sharing is possible between
flows with the same SESSION_ID that originate from the same QNI or flows with the same SESSION_ID that originate from the same QNI or
between flows with a different SESSION_ID that are related through between flows with a different SESSION_ID that are related through
the BOUND_SESSION_ID object. For flows with the same SESSION_ID, the BOUND_SESSION_ID object. For flows with the same SESSION_ID,
resource sharing is only applicable when the existing reservation is resource sharing is only applicable when the existing reservation is
skipping to change at page 57, line 48 skipping to change at page 62, line 22
handled by the QoS Model. handled by the QoS Model.
9. Security Considerations 9. Security Considerations
9.1. Introduction and Threat Overview 9.1. Introduction and Threat Overview
The security requirement for the QoS NSLP is to protect the The security requirement for the QoS NSLP is to protect the
signalling exchange for establishing QoS reservations against signalling exchange for establishing QoS reservations against
identified security threats. For the signalling problem as a whole, identified security threats. For the signalling problem as a whole,
these threats have been outlined in NSIS threats [RFC4081]; the NSIS these threats have been outlined in NSIS threats [RFC4081]; the NSIS
framework [RFC4080] assigns a subset of the responsibility to GIMPS framework [RFC4080] assigns a subset of the responsibility to GIST
and the remaining threats need to be addressed by NSLPs. The main and the remaining threats need to be addressed by NSLPs. The main
issues to be handled can be summarised as: issues to be handled can be summarised as:
Authorization: Authorization:
The QoS NSLP must assure that the network is protected against theft- The QoS NSLP must assure that the network is protected against theft-
of-service by offering mechanisms to authorize the QoS reservation of-service by offering mechanisms to authorize the QoS reservation
requester. A user requesting a QoS reservation might want proper requester. A user requesting a QoS reservation might want proper
resource accounting and protection against spoofing and other resource accounting and protection against spoofing and other
security vulnerabilities which lead to denial of service and security vulnerabilities which lead to denial of service and
skipping to change at page 58, line 28 skipping to change at page 62, line 49
Message Protection: Message Protection:
Signalling message content should be protected against modification, Signalling message content should be protected against modification,
replay, injection and eavesdropping while in transit. Authorization replay, injection and eavesdropping while in transit. Authorization
information, such as authorization tokens, need protection. This information, such as authorization tokens, need protection. This
type of protection at the NSLP layer is necessary to protect messages type of protection at the NSLP layer is necessary to protect messages
between NSLP nodes which includes end-to-middle, middle-to-middle and between NSLP nodes which includes end-to-middle, middle-to-middle and
even end-to-end protection. even end-to-end protection.
Rate Limitation:
QNEs should perform rate limiting on the refresh messages that they
send. An attacker could send erroneous messages on purpose, forcing
the QNE to constantly reply with an error message. Authentication
mechanisms would help in figuring out if error situations should be
reported to the sender, or silently ignored. If the sender is
authenticated, the QNE should reply promptly.
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, GIST and QoS NSLP nodes have finite resources (state storage,
processing power, bandwidth). The protocol mechanisms suggested processing power, bandwidth). The protocol mechanisms suggested
in 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 GIST which by itself relies on existing authentication
and key exchange protocols. Some signalling messages cannot be and key exchange protocols. Some signalling messages cannot be
protected by GIMPS and hence should be used with care by the QoS protected by GIST and hence should be used with care by the QoS NSLP.
NSLP. An API must ensure that the QoS NSLP implementation is aware An API must ensure that the QoS NSLP implementation is aware of the
of the underlying security mechanisms and must be able to indicate underlying security mechanisms and must be able to indicate which
which degree of security is provided between two GIMPS peers. If a degree of security is provided between two GIST peers. If a level of
level of security protection for QoS NSLP messages is required which security protection for QoS NSLP messages is required which goes
goes beyond the security offered by GIMPS or underlying security beyond the security offered by GIST 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 9.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 chain- requires trust between neighboring NSLP nodes to establish a chain-
of-trust along the QoS signalling path. This model is simple to of-trust along the QoS signalling path. This model is simple to
skipping to change at page 61, line 39 skipping to change at page 66, line 19
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.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-nsis-ntlp] Schulzrinne, H., and R. Hancock, "GIMPS: General [I-D.ietf-nsis-ntlp] Schulzrinne, H., and R. Hancock, "GIST: General
Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-08
(work in progress), May 2005. (work in progress), September 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997. Specifications: ABNF", RFC 2234, November 1997.
13.2. Informative References 13.2. Informative References
[RFC4080] Hancock, R., "Next Steps in Signaling: Framework", RFC [RFC4080] Hancock, R., "Next Steps in Signaling: Framework", RFC
4080, December 2004. 4080, December 2004.
[RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for [RFC4081] Tschofenig, H. and D. Kroeselberg, "Security Threats for
NSIS", RFC 4081, October 2004. NSIS", RFC 4081, October 2004.
[I-D.ash-nsis-y1541-qosm] Ash, J., "Y.1541 QoS Model for Networks [I-D.ash-nsis-y1541-qosm] Ash, J., "Y.1541 QoS Model for Networks
Using Y.1541 QoS Classes", draft-ash-nsis-y1541-qosm-00 (work in Using Y.1541 QoS Classes", draft-ietf-nsis-y1541-qosm-00 (work in
progress), May 2005. progress), August 2005.
[I-D.ietf-nsis-qspec] Ash, J., "QoS NSLP QSPEC Template", draft-ietf- [I-D.ietf-nsis-qspec] Ash, J., "QoS NSLP QSPEC Template", draft-ietf-
nsis-qspec-04 (work in progress), May 2005. nsis-qspec-06 (work in progress), October 2005.
[I-D.ietf-nsis-rmd] Bader, A., "RMD-QOSM - The Resource Management in [I-D.ietf-nsis-rmd] Bader, A., "RMD-QOSM - The Resource Management in
Diffserv QoS model", draft-ietf-nsis-rmd-03 (work in progress), June Diffserv QoS model", draft-ietf-nsis-rmd-03 (work in progress), June
2005. 2005.
[I-D.kappler-nsis-qosmodel-controlledload] Kappler, C., "A QoS Model [I-D.kappler-nsis-qosmodel-controlledload] Kappler, C., "A QoS Model
for Signaling IntServ Controlled-Load Service with NSIS", draft- for Signaling IntServ Controlled-Load Service with NSIS", draft-
kappler-nsis-qosmodel-controlledload-01 (work in progress), May 2005. kappler-nsis-qosmodel-controlledload-01 (work in progress), May 2005.
[I-D.loughney-nsis-ext] Loughney, J. "NSIS Extensibility Model", [I-D.loughney-nsis-ext] Loughney, J. "NSIS Extensibility Model",
skipping to change at page 62, line 42 skipping to change at page 67, line 16
lrsvp-04 (work in progress), September 2004. lrsvp-04 (work in progress), September 2004.
[I-D.tschofenig-nsis-aaa-issues] Tschofenig, H., "NSIS [I-D.tschofenig-nsis-aaa-issues] Tschofenig, H., "NSIS
Authentication, Authorization and Accounting Issues", draft- Authentication, Authorization and Accounting Issues", draft-
tschofenig-nsis-aaa-issues-01 (work in progress), March 2003. tschofenig-nsis-aaa-issues-01 (work in progress), March 2003.
[I-D.tschofenig-nsis-qos-authz-issues] Tschofenig, H., "QoS NSLP [I-D.tschofenig-nsis-qos-authz-issues] Tschofenig, H., "QoS NSLP
Authorization Issues", draft-tschofenig-nsis-qos-authz-issues-00 Authorization Issues", draft-tschofenig-nsis-qos-authz-issues-00
(work in progress), June 2003. (work in progress), June 2003.
[I-D.westberg-rmd-framework] Westberg, L., "Resource Management In
Diffserv: An NSIS QoS Signalling Model for Diffserv Networks", draft-
westberg-rmd-framework-04.txt, work in progress, September 2003.
[MEF.EthernetServicesModel] Metro Ethernet Forum, "Ethernet Services [MEF.EthernetServicesModel] Metro Ethernet Forum, "Ethernet Services
Model", letter ballot document , August 2003. Model", letter ballot document , August 2003.
[OSP] ETSI, "Telecommunications and internet protocol harmonization [OSP] ETSI, "Telecommunications and internet protocol harmonization
over networks (tiphon); open settlement protocol (osp) for inter- over networks (tiphon); open settlement protocol (osp) for inter-
domain pricing, authorization, and usage exchange", Technical domain pricing, authorization, and usage exchange", Technical
Specification 101 321, version 2.1.0. Specification 101 321, version 2.1.0.
[RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated [RFC1633] Braden, B., Clark, D., and S. Shenker, "Integrated
Services in the Internet Architecture: an Overview", RFC 1633, June Services in the Internet Architecture: an Overview", RFC 1633, June
skipping to change at page 66, line 34 skipping to change at page 71, line 6
QUERY is used to install reverse state along the path. QUERY is used to install reverse state along the path.
* Made all flag names positive. Removed NO_FATE_SHARING flag: * Made all flag names positive. Removed NO_FATE_SHARING flag:
fate sharing is not supported by the signalling. fate sharing is not supported by the signalling.
* Removed the open issue on one-sided bidirectional reservation. * Removed the open issue on one-sided bidirectional reservation.
Clarified how it can be done, even for stateless or reduced state Clarified how it can be done, even for stateless or reduced state
domains in an example. domains in an example.
* Removed open issue on priority. Message priority will be * Removed open issue on priority. Message priority will be
handled over GIMPS API, reservation priority is an issue for the handled over GIST API, reservation priority is an issue for the
RMF. RMF.
Changes from -04 Changes from -04
* Resolved a number of outstanding comments on clarifications * Resolved a number of outstanding comments on clarifications
(likelihood of transport type, bidirectional reservations, handle (likelihood of transport type, bidirectional reservations, handle
of RESERVE messages inside a domain in case of aggregation or of RESERVE messages inside a domain in case of aggregation or
reduced state operation) from the mailing list. reduced state operation) from the mailing list.
* Introduced a default value for REFRESH_PERIOD. * Introduced a default value for REFRESH_PERIOD.
* Introduced explicit feedback mechanism in case of route * Introduced explicit feedback mechanism in case of route
changes. changes.
* State acknowledgment is now supported by means of an * State acknowledgment is now supported by means of an
ACKNOWLEDGE flag. This is made the default case. ACKNOWLEDGE flag. This is made the default case.
* Changed section 7 to reflect the use of GIMPS service * Changed section 7 to reflect the use of GIST service interface.
interface.
Changes from -05 Changes from -05
* Modified definitions of QoS Model and NSLP/QSPEC relationships. * Modified definitions of QoS Model and NSLP/QSPEC relationships.
Removed concepts of QoS Signalling Model (QSM) and QoS Signalling Removed concepts of QoS Signalling Model (QSM) and QoS Signalling
Policy (QSP). Policy (QSP).
* Made changes to the policy control and authentication concepts. * Made changes to the policy control and authentication concepts.
Removed old appendix on original POLICY_CONTROL object. Removed old appendix on original POLICY_CONTROL object.
skipping to change at page 67, line 31 skipping to change at page 71, line 57
* Renamed "Summary refresh" to "Reduced refresh", as the old * Renamed "Summary refresh" to "Reduced refresh", as the old
seemed to be a somewhat unclear term, and the new follows the seemed to be a somewhat unclear term, and the new follows the
terminology of RFC2961. terminology of RFC2961.
* Added some missing figure captions, and an introductory text to * Added some missing figure captions, and an introductory text to
Fig. 2 Fig. 2
* Added some clarifications to Sections 3.2.2, 3.2.8.1, 4.8, 5.1, * Added some clarifications to Sections 3.2.2, 3.2.8.1, 4.8, 5.1,
5.2.3, and 5.4.1 5.2.3, and 5.4.1
* Removed some texts that makes requests about GIMPS. These should * Removed some texts that makes requests about GIST. These should
be handled e.g. through the open issues list, and not have these be handled e.g. through the open issues list, and not have these
types of clearly open issues within the main text. types of clearly open issues within the main text.
* Added "[FIXME: ...]" entries in various place to be handled at * Added "[FIXME: ...]" entries in various place to be handled at
some point. some point.
* Added discussion on using RII as a "Forced Refresh" mechanism * Added discussion on using RII as a "Forced Refresh" mechanism
that is needed to support changes in routing paths. Now any node that is needed to support changes in routing paths. Now any node
that gets to know that a routing change has happened somewhere can that gets to know that a routing change has happened somewhere can
force a repair of the installed reservation state. force a repair of the installed reservation state.
* Various editorial changes, and typo fixes, e.g., search-replace * Various editorial changes, and typo fixes, e.g., search-replace
"QoS-NSLP" > "QoS NSLP" and "QSpec" > "QSPEC" "QoS-NSLP" > "QoS NSLP" and "QSpec" > "QSPEC"
* Updated sections on "QoS model stacking". * Updated sections on "QoS model stacking".
* Added some additional notes on policy control interactions. * Added some additional notes on policy control interactions.
* Added initial version of a packet classifier information object. * Added initial version of a packet classifier information object.
Changes from -07
* fixed text talking about the GIST API on message processing
priorities
* clarified a number of issues, especially on message processing,
eg., RESPONSE message processing, and the use of RII
* reformatted the COMMON_HEADER
* reformatted and renamed the ERROR_SPEC to INFO_SPEC
* Added a new flag to the QUERY message to indicate a receiver-
initiated reservation is requested
* Updated text and the specification of RSNs
* Added text about retransmissions
* Added text about default message processing when receicing an
erroneous message
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 Rights 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; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
 End of changes. 218 change blocks. 
522 lines changed or deleted 802 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/