< draft-ietf-nsis-qos-nslp-14.txt   draft-ietf-nsis-qos-nslp-15.txt >
Network Working Group J. Manner Network Working Group J. Manner
Internet-Draft University of Helsinki Internet-Draft University of Helsinki
Intended status: Standards Track G. Karagiannis Intended status: Standards Track G. Karagiannis
Expires: December 12, 2007 University of Twente/Ericsson Expires: January 26, 2008 University of Twente/Ericsson
A. McDonald A. McDonald
Siemens/Roke Manor Research Siemens/Roke Manor Research
June 10, 2007 July 25, 2007
NSLP for Quality-of-Service Signaling NSLP for Quality-of-Service Signaling
draft-ietf-nsis-qos-nslp-14.txt draft-ietf-nsis-qos-nslp-15.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 37 skipping to change at page 1, line 37
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 on December 12, 2007. This Internet-Draft will expire on January 26, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2007).
Abstract Abstract
This specification describes the NSIS Signaling Layer Protocol (NSLP) This specification describes the NSIS Signaling Layer Protocol (NSLP)
for signaling QoS reservations in the Internet. It is in accordance for signaling QoS reservations in the Internet. It is in accordance
with the framework and requirements developed in NSIS. Together with with the framework and requirements developed in NSIS. Together with
skipping to change at page 2, line 36 skipping to change at page 2, line 36
3.2.6. Summary Refreshes and Summary Tear . . . . . . . . . . 15 3.2.6. Summary Refreshes and Summary Tear . . . . . . . . . . 15
3.2.7. Message Scoping . . . . . . . . . . . . . . . . . . . 16 3.2.7. Message Scoping . . . . . . . . . . . . . . . . . . . 16
3.2.8. Session Binding . . . . . . . . . . . . . . . . . . . 16 3.2.8. Session Binding . . . . . . . . . . . . . . . . . . . 16
3.2.9. Message Binding . . . . . . . . . . . . . . . . . . . 17 3.2.9. Message Binding . . . . . . . . . . . . . . . . . . . 17
3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17 3.2.10. Layering . . . . . . . . . . . . . . . . . . . . . . . 17
3.2.11. Support for Request Priorities . . . . . . . . . . . . 19 3.2.11. Support for Request Priorities . . . . . . . . . . . . 19
3.2.12. Rerouting . . . . . . . . . . . . . . . . . . . . . . 19 3.2.12. Rerouting . . . . . . . . . . . . . . . . . . . . . . 19
3.2.13. Pre-emption . . . . . . . . . . . . . . . . . . . . . 24 3.2.13. Pre-emption . . . . . . . . . . . . . . . . . . . . . 24
3.3. GIST Interactions . . . . . . . . . . . . . . . . . . . . 24 3.3. GIST Interactions . . . . . . . . . . . . . . . . . . . . 24
3.3.1. Support for Bypassing Intermediate Nodes . . . . . . . 25 3.3.1. Support for Bypassing Intermediate Nodes . . . . . . . 25
3.3.2. Support for Peer Change Identification . . . . . . . . 25 3.3.2. Support for Peer Change Identification . . . . . . . . 26
3.3.3. Support for Stateless Operation . . . . . . . . . . . 26 3.3.3. Support for Stateless Operation . . . . . . . . . . . 26
3.3.4. Priority of Signaling Messages . . . . . . . . . . . . 26 3.3.4. Priority of Signaling Messages . . . . . . . . . . . . 26
3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes . . . 26 3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes . . . 26
4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 27 4. Examples of QoS NSLP Operation . . . . . . . . . . . . . . . . 27
4.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 27 4.1. Sender-initiated Reservation . . . . . . . . . . . . . . . 27
4.2. Sending a Query . . . . . . . . . . . . . . . . . . . . . 28 4.2. Sending a Query . . . . . . . . . . . . . . . . . . . . . 29
4.3. Basic Receiver-initiated Reservation . . . . . . . . . . . 29 4.3. Basic Receiver-initiated Reservation . . . . . . . . . . . 29
4.4. Bidirectional Reservations . . . . . . . . . . . . . . . . 31 4.4. Bidirectional Reservations . . . . . . . . . . . . . . . . 31
4.5. Use of Local QoS Models . . . . . . . . . . . . . . . . . 32 4.5. Aggregate Reservations . . . . . . . . . . . . . . . . . . 32
4.6. Aggregate Reservations . . . . . . . . . . . . . . . . . . 33 4.6. Message Binding . . . . . . . . . . . . . . . . . . . . . 34
4.7. Message Binding . . . . . . . . . . . . . . . . . . . . . 35 4.7. Reduced State or Stateless Interior Nodes . . . . . . . . 37
4.8. Reduced State or Stateless Interior Nodes . . . . . . . . 38 4.7.1. Sender-initiated Reservation . . . . . . . . . . . . . 38
4.8.1. Sender-initiated Reservation . . . . . . . . . . . . . 39 4.7.2. Receiver-initiated Reservation . . . . . . . . . . . . 39
4.8.2. Receiver-initiated Reservation . . . . . . . . . . . . 40 4.8. Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 40
4.9. Proxy Mode . . . . . . . . . . . . . . . . . . . . . . . . 41 5. QoS NSLP Functional Specification . . . . . . . . . . . . . . 41
5. QoS NSLP Functional Specification . . . . . . . . . . . . . . 42 5.1. QoS NSLP Message and Object Formats . . . . . . . . . . . 41
5.1. QoS NSLP Message and Object Formats . . . . . . . . . . . 42 5.1.1. Common Header . . . . . . . . . . . . . . . . . . . . 42
5.1.1. Common Header . . . . . . . . . . . . . . . . . . . . 43 5.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 43
5.1.2. Message Formats . . . . . . . . . . . . . . . . . . . 44 5.1.3. Object Formats . . . . . . . . . . . . . . . . . . . . 47
5.1.3. Object Formats . . . . . . . . . . . . . . . . . . . . 48 5.2. General Processing Rules . . . . . . . . . . . . . . . . . 59
5.2. General Processing Rules . . . . . . . . . . . . . . . . . 60
5.2.1. State Manipulation . . . . . . . . . . . . . . . . . . 60 5.2.1. State Manipulation . . . . . . . . . . . . . . . . . . 60
5.2.2. Message Forwarding . . . . . . . . . . . . . . . . . . 62 5.2.2. Message Forwarding . . . . . . . . . . . . . . . . . . 61
5.2.3. Standard Message Processing Rules . . . . . . . . . . 62 5.2.3. Standard Message Processing Rules . . . . . . . . . . 61
5.2.4. Retransmissions . . . . . . . . . . . . . . . . . . . 62 5.2.4. Retransmissions . . . . . . . . . . . . . . . . . . . 61
5.2.5. Rerouting . . . . . . . . . . . . . . . . . . . . . . 63 5.2.5. Rerouting . . . . . . . . . . . . . . . . . . . . . . 62
5.3. Object Processing . . . . . . . . . . . . . . . . . . . . 65 5.3. Object Processing . . . . . . . . . . . . . . . . . . . . 64
5.3.1. Reservation Sequence Number (RSN) . . . . . . . . . . 65 5.3.1. Reservation Sequence Number (RSN) . . . . . . . . . . 64
5.3.2. Request Identification Information (RII) . . . . . . . 66 5.3.2. Request Identification Information (RII) . . . . . . . 65
5.3.3. BOUND_SESSION_ID . . . . . . . . . . . . . . . . . . . 67 5.3.3. BOUND_SESSION_ID . . . . . . . . . . . . . . . . . . . 66
5.3.4. REFRESH_PERIOD . . . . . . . . . . . . . . . . . . . . 67 5.3.4. REFRESH_PERIOD . . . . . . . . . . . . . . . . . . . . 67
5.3.5. INFO_SPEC . . . . . . . . . . . . . . . . . . . . . . 68 5.3.5. INFO_SPEC . . . . . . . . . . . . . . . . . . . . . . 67
5.3.6. SESSION_ID_LIST . . . . . . . . . . . . . . . . . . . 70 5.3.6. SESSION_ID_LIST . . . . . . . . . . . . . . . . . . . 69
5.3.7. RSN_LIST . . . . . . . . . . . . . . . . . . . . . . . 70 5.3.7. RSN_LIST . . . . . . . . . . . . . . . . . . . . . . . 70
5.3.8. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 71 5.3.8. QSPEC . . . . . . . . . . . . . . . . . . . . . . . . 71
5.4. Message Processing Rules . . . . . . . . . . . . . . . . . 71 5.4. Message Processing Rules . . . . . . . . . . . . . . . . . 71
5.4.1. RESERVE Messages . . . . . . . . . . . . . . . . . . . 72 5.4.1. RESERVE Messages . . . . . . . . . . . . . . . . . . . 71
5.4.2. QUERY Messages . . . . . . . . . . . . . . . . . . . . 76 5.4.2. QUERY Messages . . . . . . . . . . . . . . . . . . . . 76
5.4.3. RESPONSE Messages . . . . . . . . . . . . . . . . . . 77 5.4.3. RESPONSE Messages . . . . . . . . . . . . . . . . . . 77
5.4.4. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 79 5.4.4. NOTIFY Messages . . . . . . . . . . . . . . . . . . . 78
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79
6.1. QoS NSLP Message Type . . . . . . . . . . . . . . . . . . 80 6.1. QoS NSLP Message Type . . . . . . . . . . . . . . . . . . 79
6.2. NSLP Message Objects . . . . . . . . . . . . . . . . . . . 80 6.2. NSLP Message Objects . . . . . . . . . . . . . . . . . . . 79
6.3. QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 80 6.3. QoS NSLP Binding Codes . . . . . . . . . . . . . . . . . . 80
6.4. QoS NSLP Error Classes and Error Codes . . . . . . . . . . 81 6.4. QoS NSLP Error Classes and Error Codes . . . . . . . . . . 80
6.5. QoS NSLP Error Source Identifiers . . . . . . . . . . . . 81 6.5. QoS NSLP Error Source Identifiers . . . . . . . . . . . . 81
6.6. NSLP IDs and Router Alert Option Values . . . . . . . . . 81 6.6. NSLP IDs and Router Alert Option Values . . . . . . . . . 81
7. Security Considerations . . . . . . . . . . . . . . . . . . . 82 7. Security Considerations . . . . . . . . . . . . . . . . . . . 81
7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 83 7.1. Trust Relationship Model . . . . . . . . . . . . . . . . . 82
7.2. Authorization Model Examples . . . . . . . . . . . . . . . 85 7.2. Authorization Model Examples . . . . . . . . . . . . . . . 84
7.2.1. Authorization for the Two Party Approach . . . . . . . 85 7.2.1. Authorization for the Two Party Approach . . . . . . . 84
7.2.2. Token-based Three Party Approach . . . . . . . . . . . 86 7.2.2. Token-based Three Party Approach . . . . . . . . . . . 85
7.2.3. Generic Three Party Approach . . . . . . . . . . . . . 87 7.2.3. Generic Three Party Approach . . . . . . . . . . . . . 86
7.3. Computing the Authorization Decision . . . . . . . . . . . 87 7.3. Computing the Authorization Decision . . . . . . . . . . . 87
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 88 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 87
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 88 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 88
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 88
10.1. Normative References . . . . . . . . . . . . . . . . . . . 88 10.1. Normative References . . . . . . . . . . . . . . . . . . . 88
10.2. Informative References . . . . . . . . . . . . . . . . . . 88 10.2. Informative References . . . . . . . . . . . . . . . . . . 88
Appendix A. Appendix A. Abstract NSLP-RMF API . . . . . . . . . . 90 Appendix A. Appendix A. Abstract NSLP-RMF API . . . . . . . . . . 90
A.1. Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 90 A.1. Triggers from QOS-NSLP towards RMF . . . . . . . . . . . . 90
A.2. Triggers from RMF/QOSM towards QOS-NSLP . . . . . . . . . 92 A.2. Triggers from RMF/QOSM towards QOS-NSLP . . . . . . . . . 92
A.3. Configuration interface . . . . . . . . . . . . . . . . . 94 A.3. Configuration interface . . . . . . . . . . . . . . . . . 94
Appendix B. Appendix B. Glossary . . . . . . . . . . . . . . . . 94
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 95 Appendix B. Appendix B. Glossary . . . . . . . . . . . . . . . . 95
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 96
Intellectual Property and Copyright Statements . . . . . . . . . . 97 Intellectual Property and Copyright Statements . . . . . . . . . . 97
1. Introduction 1. Introduction
This document defines a Quality of Service (QoS) NSIS Signaling Layer This document defines a Quality of Service (QoS) NSIS Signaling Layer
Protocol (NSLP), henceforth referred to as the "QoS NSLP". This Protocol (NSLP), henceforth referred to as the "QoS NSLP". This
protocol establishes and maintains state at nodes along the path of a protocol establishes and maintains state at nodes along the path of a
data flow for the purpose of providing some forwarding resources for data flow for the purpose of providing some forwarding resources for
that flow. It is intended to satisfy the QoS-related requirements of that flow. It is intended to satisfy the QoS-related requirements of
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
skipping to change at page 5, line 30 skipping to change at page 5, line 30
The design of the QoS NSLP is conceptually similar to RSVP, RFC 2205 The design of the 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 signaling path). The QoS NSLP end-to-end fashion along the complete signaling path). The QoS NSLP
extends the set of reservation mechanisms to meet the requirements of extends the set of reservation mechanisms to meet the requirements of
RFC 3726 [RFC3726], in particular support of sender or receiver- RFC 3726 [RFC3726], in particular support of sender or receiver-
initiated reservations, as well as, a type of bi-directional initiated reservations, as well as, a type of bi-directional
reservation and support of reservations between arbitrary nodes, reservation and support of reservations between arbitrary nodes,
e.g., edge-to-edge, end-to-access, etc. On the other hand, there is e.g., edge-to-edge, end-to-access, etc. On the other hand, there is
no support for IP multicast. currently no support for IP multicast.
A distinction is made between the operation of the signaling protocol A distinction is made between the operation of the signaling protocol
and the information required for the operation of the Resource and the information required for the operation of the Resource
Management Function (RMF). This document describes the signaling Management Function (RMF). This document describes the signaling
protocol, whilst [I-D.ietf-nsis-qspec] describes the RMF-related protocol, whilst [I-D.ietf-nsis-qspec] describes the RMF-related
information carried in the QSPEC (QoS Specification) object in QoS information carried in the QSPEC (QoS Specification) object in QoS
NSLP messages. This is similar to the decoupling between RSVP and NSLP messages. This is similar to the decoupling between RSVP and
the IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries the IntServ architecture, RFC 1633 [RFC1633]. The QSPEC carries
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.
skipping to change at page 12, line 17 skipping to change at page 12, line 17
whilst leaving the validation of RMF behavior to contracts external whilst leaving the validation of RMF behavior to contracts external
to the protocol itself. The RMF may make use of various elements to the protocol itself. The RMF may make use of various elements
from the QoS NSLP message, not only the QSPEC object. from the QoS NSLP message, not only the QSPEC object.
Still, this specification assumes that resource sharing is possible Still, this specification assumes that resource sharing is possible
between flows with the same SESSION_ID that originate from the same between flows with the same SESSION_ID that originate from the same
QNI or between flows with a different SESSION_ID that are related QNI or between flows with a different SESSION_ID that are related
through the BOUND_SESSION_ID object. For flows with the same through the BOUND_SESSION_ID object. For flows with the same
SESSION_ID, resource sharing is only applicable when the existing SESSION_ID, resource sharing is only applicable when the existing
reservation is not just replaced (which is indicated by the REPLACE reservation is not just replaced (which is indicated by the REPLACE
flag in the common header. We assume that the QoS model supports flag in the common header). We assume that the QoS model supports
resource sharing between flows. A QoS Model may elect to implement a resource sharing between flows. A QoS Model may elect to implement a
more general behavior of supporting relative operations on existing more general behavior of supporting relative operations on existing
reservations, such as ADDING or SUBTRACTING a certain amount of reservations, such as ADDING or SUBTRACTING a certain amount of
resources from the current reservation. A QoS Model may also elect resources from the current reservation. A QoS Model may also elect
to allow resource sharing more generally, e.g., between all flows to allow resource sharing more generally, e.g., between all flows
with the same DSCP. with the same DSCP.
The QSPEC carries a collection of objects that can describe QoS The QSPEC carries a collection of objects that can describe QoS
specifications in a number of different ways. A generic template is specifications in a number of different ways. A generic template is
defined in [I-D.ietf-nsis-qspec]. A QSPEC describing the resources defined in [I-D.ietf-nsis-qspec]. A QSPEC describing the resources
skipping to change at page 12, line 29 skipping to change at page 12, line 29
more general behavior of supporting relative operations on existing more general behavior of supporting relative operations on existing
reservations, such as ADDING or SUBTRACTING a certain amount of reservations, such as ADDING or SUBTRACTING a certain amount of
resources from the current reservation. A QoS Model may also elect resources from the current reservation. A QoS Model may also elect
to allow resource sharing more generally, e.g., between all flows to allow resource sharing more generally, e.g., between all flows
with the same DSCP. with the same DSCP.
The QSPEC carries a collection of objects that can describe QoS The QSPEC carries a collection of objects that can describe QoS
specifications in a number of different ways. A generic template is specifications in a number of different ways. A generic template is
defined in [I-D.ietf-nsis-qspec]. A QSPEC describing the resources defined in [I-D.ietf-nsis-qspec]. A QSPEC describing the resources
requested will usually contain objects which need to be understood by requested will usually contain objects which need to be understood by
all implementations, and it can also be enhanced with additional all implementations, and it can also be enhanced with additional
objects specific to a QoS model to provide a more exact definition to objects specific to a QoS model to provide a more exact definition to
the RMF, which may be better able to use its specific resource the RMF, which may be better able to use its specific resource
management mechanisms (which may, e.g., be link specific) as a management mechanisms (which may, e.g., be link specific) as a
result. result.
A QoS Model defines the behavior of the RMF, including inputs and A QoS Model defines the behavior of the RMF, including inputs and
outputs, and how QSPEC information is used to describe resources outputs, and how QSPEC information is used to describe resources
available, resources required, traffic descriptions, and control available, resources required, traffic descriptions, and control
information required by the RMF. A QoS Model also describes the information required by the RMF. A QoS Model also describes the
minimum set of parameters QNEs should use in the QSPEC when signaling minimum set of parameters QNEs should use in the QSPEC when signaling
about this QoS Model. about this QoS Model.
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). All QSPECs must follow the QSPEC template vendors). All QSPECs should follow the design of the QSPEC template
[I-D.ietf-nsis-qspec]. [I-D.ietf-nsis-qspec].
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
behavior should be implemented in the areas where the QoS NSLP gives behavior 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 behavior for how a RESERVE message that is forwarded recommended behavior for how a RESERVE message that is forwarded
relates to that received, or when additional signaling sessions relates to that received, or when additional signaling 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. A QoS model may specify reservation particular scenarios. A QoS model may specify reservation
preemption, e.g., an incoming resource request may cause removal of preemption, e.g., an incoming resource request may cause removal of
an earlier reservation. an earlier established reservation.
3.1.3. Policy Control 3.1.3. Policy Control
Getting access to network resources, e.g., network access in general Getting access to network resources, e.g., network access in general
or access to QoS, typically involves some kind of policy control. or access to QoS, typically involves some kind of policy control.
One example of this is authorization of the resource requester. One example of this is authorization of the resource requester.
Policy control for QoS NSLP resource reservation signaling is Policy control for QoS NSLP resource reservation signaling is
conceptually organized as illustrated below in Figure 3. conceptually organized as illustrated below in Figure 3.
+-------------+ +-------------+
skipping to change at page 13, line 51 skipping to change at page 13, line 50
From the QoS NSLP point of view, the policy control model is From the QoS NSLP point of view, the policy control model is
essentially a two-party model between neighboring QNEs. The actual essentially a two-party model between neighboring 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 policy 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 authorization of a resource request often depends on the identity The authorization of a resource request often depends on the identity
of the entity making the request. Authentication may be required The of the entity making the request. Authentication may be required.
GIST channel security mechanisms provide one way of authenticating The GIST channel security mechanisms provide one way of
the QoS NSLP peer which sent the request, and so may be used in authenticating the QoS NSLP peer which sent the request, and so may
making the authorization decision. be used in making the authorization decision.
Additional information might also be provided in order to assist in Additional information might also be provided in order to assist in
making the authorization decision. This might include alternative making the authorization decision. This might include alternative
methods of authenticating the request. methods of authenticating the request.
The QoS NSLP does not contain objects to carry authorization The QoS NSLP does not contain objects to carry authorization
information. A separate work [nslp-auth] defines this functionality information. A separate work [nslp-auth] defines this functionality
for the QoS NSLP and the NATFW NSLP. for the QoS NSLP and the NATFW NSLP.
It is generally assumed that policy enforcement is likely to It is generally assumed that policy enforcement is likely to
skipping to change at page 17, line 46 skipping to change at page 17, line 44
binding can indicate either a unidirectional or bidirectional binding can indicate either a unidirectional or bidirectional
dependency relation between two messages by including in one of the dependency relation between two messages by including in one of the
message the MSG_ID object ("binding message") and in the other message the MSG_ID object ("binding message") and in the other
message ("bound message") the BOUND_MSG_ID object. The message ("bound message") the BOUND_MSG_ID object. The
unidirectional dependency means that only RESERVE messages are bound unidirectional dependency means that only RESERVE messages are bound
to each other whereas a bidirectional dependency means that there is to each other whereas a bidirectional dependency means that there is
also a dependency for the related RESPONSE messages. The message also a dependency for the related RESPONSE messages. The message
binding can be used to speed up signaling by starting two signaling binding can be used to speed up signaling by starting two signaling
exchanges simultaneously that are synchronized later by using message exchanges simultaneously that are synchronized later by using message
IDs. This can be used as an optimization technique for example in IDs. This can be used as an optimization technique for example in
scenarios where aggregate reservations are used. Section 4.7 scenarios where aggregate reservations are used. Section 4.6
provides more details. provides more details.
3.2.10. Layering 3.2.10. Layering
The QoS NSLP supports layered reservations. Layered reservations may The QoS NSLP supports layered reservations. Layered reservations may
occur when certain parts of the network (domains) implement one or occur when certain parts of the network (domains) implement one or
more local QoS models, or when they locally apply specific transport more local QoS models, or when they locally apply specific transport
characteristics (e.g., GIST unreliable transfer mode instead of characteristics (e.g., GIST unreliable transfer mode instead of
reliable transfer mode). They may also occur when several per-flow reliable transfer mode). They may also occur when several per-flow
reservations are locally combined into an aggregate reservation. reservations are locally combined into an aggregate reservation.
skipping to change at page 20, line 36 skipping to change at page 20, line 35
the outgoing interface towards GIST peer). These mechanisms can the outgoing interface towards GIST peer). These mechanisms can
provide implementation specific optimizations, and are outside the provide implementation specific optimizations, and are outside the
scope of this specification. scope of 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 sending a new the reservation on the new path. This is done by sending a new
RESERVE message. If the next QNE is, in fact, unchanged then this RESERVE message. If the next QNE is, in fact, unchanged then this
will be used to refresh/update the existing reservation. Otherwise will be used to refresh/update the existing reservation. Otherwise
it will lead to the reservation being installed on the new path. it will lead to the reservation being installed on the new path.
Note that the operation for a receiver-initiated reservation session
differs a bit from the above description. If the routing changes in
the middle of the session, the QNE that notices that its downstream
path changed, the divergence point, must send a QUERY with the R-flag
downstream. It will be processed as above, and at some point hits a
QNE for which the path downstream towards the QNI remains (the
convergence point). This node must then send a full RESERVE upstream
to set up the reservation state along the new path. It should not
send the QUERY further downstream, since this would have no real use.
Similarly, when the QNE that sent the QUERY receives the RESERVE, it
should not send the RESERVE further upstream.
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
may want to tear down the reservation on the old path (sooner than may want to tear down the reservation on the old path (sooner than
would result from normal soft-state time-out). This functionality is would result from normal soft-state time-out). This functionality is
supported by keeping track of the old SII-Handle provided over the supported by keeping track of the old SII-Handle provided over the
GIST API. This handle can be used by the QoS NSLP to route messages GIST API. This handle can be used by the QoS NSLP to route messages
explicitly to the next node. explicitly to the next node.
If the old path is downstream, the QNE can send a tearing RESERVE
using the old SII-Handle. If the old path is upstream, the QNE can
send a NOTIFY with the code for "Route Change". This is forwarded
upstream until it hits a QNE that can issue a tearing RESERVE
downstream. A separate document discusses in detail the effect of
mobility on the QoS NSLP signaling
[I-D.ietf-nsis-applicability-mobility-signaling].
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 provided in the QoS NSLP common header, which, when a REPLACE flag is provided in the QoS NSLP common header, which, when
not set, indicates that the reservation on the old branch should be not set, indicates that the reservation on the old branch should be
kept. kept.
Note that keeping old reservations affects the resources available to Note that keeping old reservations affects the resources available to
other nodes. Thus, the operator of the access network must make the other nodes. Thus, the operator of the access network must make the
skipping to change at page 22, line 50 skipping to change at page 23, line 6
+-+ \-/ /-\ +-+ \-/ /-\
\ /-\ / |x| = QoS NSLP unaware \ /-\ / |x| = QoS NSLP unaware
\--|C|--/ \-/ \--|C|--/ \-/
\-/ \-/
\ ^ \ ^
\-------/ Updated route \-------/ Updated route
Figure 5: Path Truncation Figure 5: Path Truncation
When rerouting occurs, the data path again changes from A-B-D to A-C- When rerouting occurs, the data path again changes from A-B-D to A-C-
D. The signaling path initially ends at C, but this node is not on D. The signaling path initially ends at B, but this node is not on
the new path. In this case, the normal GIST path change detection 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. procedures at A will detect the path change and notify the QoS NSLP.
GIST will also notify the signaling application that no downstream GIST will also notify the signaling application that no downstream
GIST nodes supporting the QoS NSLP are present. Node A will take GIST nodes supporting the QoS NSLP are present. Node A will take
over as the last node on the signaling path. over as the last node on the signaling path.
3.2.12.2. Handling Spurious Route Change Notifications 3.2.12.2. Handling Spurious Route Change Notifications
The QoS NSLP is notified by GIST (with the NetworkNotification The QoS NSLP is notified by GIST (with the NetworkNotification
primitive) when GIST believes that a rerouting event may have primitive) when GIST believes that a rerouting event may have
occurred. In some cases, events that are detected as possible route occurred. In some cases, events that are detected as possible route
changes will turn out not to be. The QoS NSLP will not always be changes will turn out not to be. The QoS NSLP will not always be
skipping to change at page 23, line 49 skipping to change at page 24, line 4
Figure 6: Spurious reroute alerting Figure 6: Spurious reroute alerting
In this example the initial route A-B-C uses links (1) and (3). In this example the initial route A-B-C uses links (1) and (3).
After link (1) fails, the path is rerouted using links (2) and (3). After link (1) fails, the path is rerouted using links (2) and (3).
The set of QNEs along the path is unchanged (it is A-C in both cases, The set of QNEs along the path is unchanged (it is A-C in both cases,
since B does not support the QoS NSLP). since B does not support the QoS NSLP).
When the outgoing interface at A has changes, GIST may signal across When the outgoing interface at A has changes, GIST may signal across
its API to the NSLP with a NetworkNotification. The QoS NSLP at A its API to the NSLP with a NetworkNotification. The QoS NSLP at A
will then attempt to repair the path by installing the reservation on will then attempt to repair the path by installing the reservation on
the path'. In this case, however, the old and new paths are the the path (2),(3). In this case, however, the old and new paths are
same. the same.
To install the new reservation A will send a RESERVE message, which To install the new reservation A will send a RESERVE message, which
GIST will transport to C (discovering the new next peer as GIST will transport to C (discovering the new next peer as
appropriate). The RESERVE also requests a RESPONSE from the QNR. appropriate). The RESERVE also requests a RESPONSE from the QNR.
When this RESERVE message is received through the RecvMessage API When this RESERVE message is received through the RecvMessage API
call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged call from GIST at the QoS NSLP at C, the SII-Handle will be unchanged
from its previous communications from A. from its previous communications from A.
A RESPONSE message will be sent by the QNR, and be forwarded from C A RESPONSE message will be sent by the QNR, and be forwarded from C
to A. This confirms that the reservation was installed on the new to A. This confirms that the reservation was installed on the new
skipping to change at page 24, line 27 skipping to change at page 24, line 31
path. The RESERVE message with the TEAR flag set is sent down the path. The RESERVE message with the TEAR flag set is sent down the
old path by using the GIST explicit routing mechanism and specifying old path by using the GIST explicit routing mechanism and specifying
the SII-Handle relating to the 'old' peer QNE. the SII-Handle relating to the 'old' peer QNE.
If RSNs were being incremented for each of these RESERVE and RESERVE- If RSNs were being incremented for each of these RESERVE and RESERVE-
with-TEAR messages the reservation would be torn down at C and any with-TEAR messages the reservation would be torn down at C and any
QNEs further along the path. To avoid this the RSN is used in a QNEs further along the path. To avoid this the RSN is used in a
special way. The RESERVE down the new path is sent with the new special way. The RESERVE down the new path is sent with the new
current RSN set to the old RSN plus 2. The RESERVE-with-TEAR down current RSN set to the old RSN plus 2. The RESERVE-with-TEAR down
the old path is sent with an RSN set to the new current RSN minus 1. the old path is sent with an RSN set to the new current RSN minus 1.
This in the peer from which it was receiving RESERVE messages. This is the peer from which it was receiving RESERVE messages.
3.2.13. Pre-emption 3.2.13. Pre-emption
The QoS NSLP provides building blocks to implement pre-emption. This The QoS NSLP provides building blocks to implement pre-emption. This
specification does not define how pre-emption should work, but only specification does not define how pre-emption should work, but only
provides signaling mechanisms that can be used by QoS Models. For provides signaling mechanisms that can be used by QoS Models. For
example, an INFO_SPEC object can be added to messages to indicate example, an INFO_SPEC object can be added to messages to indicate
that the signaled session was pre-empted. A BOUND_SESSION_ID object that the signaled session was pre-empted. A BOUND_SESSION_ID object
can carry the Session ID of the flow that caused the pre-emption to can carry the Session ID of the flow that caused the pre-emption to
happen for the signaled session. How these are used by QoS Models is happen for the signaled session. How these are used by QoS Models is
skipping to change at page 26, line 47 skipping to change at page 27, line 5
NSLP. GIST service interface supports this with the 'priority' NSLP. GIST service interface supports this with the 'priority'
transfer attribute. transfer attribute.
3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes 3.3.5. Knowledge of Intermediate QoS NSLP Unaware Nodes
In some cases it is useful to know that there are routers along the In some cases it is useful to know that there are routers along the
path where QoS cannot be provided. The GIST service interface path where QoS cannot be provided. The GIST service interface
supports this by keeping track of IP-TTL and Original-TTL in the supports this by keeping track of IP-TTL and Original-TTL in the
RecvMessage primitive. A difference between the two indicates the RecvMessage primitive. A difference between the two indicates the
number of QoS NSLP unaware nodes. In this case the QNE that detects number of QoS NSLP unaware nodes. In this case the QNE that detects
this difference can set the "B" (BREAK) flag. If a QNE generates a this difference should set the "B" (BREAK) flag. If a QNE generates
QUERY, RESERVE or RESPONSE message, after receiving a QUERY or a QUERY, RESERVE or RESPONSE message, after receiving a QUERY or
RESERVE message with a "Break" flag set, it can set the "B" (BREAK) RESERVE message with a "Break" flag set, it can set the "B" (BREAK)
flag in these messages. There are however, situations where the flag in these messages. There are however, situations where the
egress QNE in a local domain may have some other means to provide QoS egress QNE in a local domain may have some other means to provide QoS
[I-D.ietf-nsis-qspec]. For example, in an RMD-QOSM
[I-D.ietf-nsis-qspec]. For example, in a RMD-QOSM
[I-D.ietf-nsis-rmd] (or RMD-QOSM like) aware local domain that uses [I-D.ietf-nsis-rmd] (or RMD-QOSM like) aware local domain that uses
either NTLP stateless nodes or NSIS unaware nodes the end to end either NTLP stateless nodes or NSIS unaware nodes the end to end
RESERVE or QUERY message bypasses these NTLP stateless or NSIS RESERVE or QUERY message bypasses these NTLP stateless or NSIS
unaware nodes. However, the reservation within the local domain can unaware nodes. However, the reservation within the local domain can
be signaled by the RMD-QOSM (or RMD-QOSM like QOSM). In such be signaled by the RMD-QOSM (or RMD-QOSM like QOSM). In such
situations, the "B" (BREAK) flag in the end to end RESERVE or QUERY situations, the "B" (BREAK) flag in the end to end RESERVE or QUERY
message should not be set by the edges of the local domain. message should not be set by the edges of the local domain.
4. Examples of QoS NSLP Operation 4. Examples of QoS NSLP Operation
skipping to change at page 29, line 26 skipping to change at page 29, line 35
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. Various includes a Request Identification Information (RII) object. Various
objects from the received QUERY message have to be copied into the objects from the received QUERY message have to be copied into the
RESPONSE message. It is then passed to GIST to be forwarded peer-to- RESPONSE message. It is then passed to GIST to be forwarded peer-to-
peer back along the path. peer back along the 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 GIST to be forwarded back down the path. to GIST to be forwarded upstream.
If there was an error in processing a RESERVE, instead of an RII, the If there was an error in processing a RESERVE, instead of an RII, the
RESPONSE may carry an RSN. Thus, a QNE must also be prepated to look RESPONSE may carry an RSN. Thus, a QNE must also be prepared to look
for an RSN object if no RII was present, and act based on the error for an RSN object if no RII was present, and act based on the error
code set in the INFO_SPEC of the RESPONSE. code set in the INFO_SPEC of the RESPONSE.
4.3. Basic Receiver-initiated Reservation 4.3. Basic Receiver-initiated Reservation
As described in the NSIS framework [RFC4080] in some signaling As described in the NSIS framework [RFC4080] in some signaling
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
skipping to change at page 31, line 5 skipping to change at page 31, line 13
path, up to the flow receiver. The receiver detects that this QUERY path, up to the flow receiver. The receiver detects that this QUERY
message carries the RESERVE-INIT flag and by using the information message carries the RESERVE-INIT flag and by using the information
contained in the received QUERY message, such as the QSPEC, contained in the received QUERY message, such as the QSPEC,
constructs a RESERVE message. constructs a RESERVE 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 GIST reverse path state). Similar that the QUERY message took (using GIST reverse path state). Similar
to the sender-initiated approach, any node may include an RII in its to the sender-initiated approach, any node may include an RII in its
RESERVE messages. The RESPONSE is sent back to confirm the resources RESERVE messages. The RESPONSE is sent back to confirm the resources
are set up. The reservation can subsequently be refreshed with are set up. The reservation can subsequently be refreshed with
RESERVE messages in the same way as for the sender-initiated RESERVE messages in the upstream direction.
approach.
4.4. Bidirectional Reservations 4.4. Bidirectional Reservations
The term "bidirectional reservation" refers to two different cases The term "bidirectional reservation" refers to two different cases
that are supported by this specification: that are supported by this specification:
o Binding two sender-initiated reservations together, e.g., one o Binding two sender-initiated reservations together, e.g., one
sender-initiated reservation from QNE A to QNE B and another one from sender-initiated reservation from QNE A to QNE B and another one from
QNE B to QNE A. QNE B to QNE A.
skipping to change at page 32, line 29 skipping to change at page 32, line 47
| | | | | | | |
| | FLOW-2 | | | | FLOW-2 | |
|<===============================| |<===============================|
| | |RESERVE-2 | | | |RESERVE-2 |
|RESERVE-2 | |<---------+QNI |RESERVE-2 | |<---------+QNI
QNR|<--------------------+ | QNR|<--------------------+ |
| | | | | | | |
Figure 10: Bi-directional reservation for sender+receiver scenario Figure 10: Bi-directional reservation for sender+receiver scenario
4.5. Use of Local QoS Models 4.5. Aggregate Reservations
In some cases it may be required to use a different QoS model along a
particular segment of the signaling path. In this case a node at the
edge of this region needs to add additional local QSPEC information,
based on the end-to-end QSPEC. This allows the QoS description to be
tailored to the QoS provisioning mechanism available in the network.
+-------- QoSM2 domain -------+
| |
| |
+----+ +----+ +----+ +----+ +----+
|QNI | |edge| |int.| |edge| |QNR |
| |========>|QNE |========>|QNE |========>|QNE |========>| |
+----+ RESERVE +----+ RESERVE +----+ RESERVE +----+ RESERVE +----+
QSPEC1 | QSPEC2 QSPEC2 | QSPEC1
| {QSPEC1} {QSPEC1} |
| |
+-----------------------------+
Figure 11: Reservation with local QoS Models
The QNI starts the signaling communication by sending a RESERVE
message, which contains QSPEC1. However, within a region of the
network a different QoS model (QoSM2) needs to be used. At the edge
of this region the QNEs support both the end-to-end and local QoS
models. When the RESERVE message reaches the QNE at the ingress, the
initial processing of the RESERVE proceeds as normal. However, the
QNE also determines the appropriate description using QoSM2. The
RESERVE message to be sent out is constructed mostly as usual but
with a second QSPEC object added on top, which becomes the 'current'
one.
When this RESERVE message is received at an node internal to the
QoSM2 domain the QoS NSLP only uses the local QSPEC, rather than the
end-to-end QSPEC. Otherwise, processing proceeds as usual. The
RESERVE message that it generates should include both of the QSPECs
from the message it received.
At the QNE at the egress of the region the local QSPEC is removed
from the message so that subsequent QNEs receive only the end-to-end
QSPEC.
A message can contain at most two QSPEC objects, i.e., the end-to-end
QSPEC and a local QSPEC.
4.6. Aggregate Reservations
In order to reduce signaling and per-flow state in the network, the In order to reduce signaling and per-flow state in the network, the
reservations for a number of flows may be aggregated. reservations for a number of flows may be aggregated.
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator aggregator deaggregator
| | | | | | | | | | | |
| RESERVE | | | | | | RESERVE | | | | |
+--------->| | | | | +--------->| | | | |
| | RESERVE | | | | | | RESERVE | | | |
skipping to change at page 34, line 31 skipping to change at page 33, line 31
| | | | | RESPONSE | | | | | | RESPONSE |
| | | | RESPONSE |<---------+ | | | | RESPONSE |<---------+
| | |<--------------------+ | | | |<--------------------+ |
| | RESPONSE | | | | | | RESPONSE | | | |
| |<---------+ | | | | |<---------+ | | |
| RESPONSE | | | | | | RESPONSE | | | | |
|<---------+ | | | | |<---------+ | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
Figure 12: Sender Initiated Reservation with Aggregation Figure 11: Sender Initiated Reservation with Aggregation
An end-to-end per-flow reservation is initiated with the messages An end-to-end per-flow reservation is initiated with the messages
shown in Figure 12 as "RESERVE". shown in Figure 11 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 12 as "RESERVE'"). This may use the same QoS model (shown in Figure 11 as "RESERVE'"). This may use the same QoS model
as the end-to-end reservation but has an MRI identifying the as the end-to-end reservation but has an MRI identifying 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.
The messages used for the signaling of the individual reservation The messages used for the signaling of the individual reservation
need to be marked such that the intermediate routers will not inspect need to be marked such that the intermediate routers will not inspect
them. In the QoS NSLP the following marking possibility is applied, them. In the QoS NSLP the following marking possibility is applied,
see also RFC3175. see also RFC3175.
skipping to change at page 35, line 26 skipping to change at page 34, line 26
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
Figure 13: Reservation aggregation Figure 12: Reservation aggregation
The deaggregator acts as the QNR for the aggregate reservation. The deaggregator acts as the QNR for the aggregate reservation.
Session binding information carried in the RESERVE message enables Session binding information carried in the RESERVE message enables
the deaggregator to associate the end-to-end and aggregate the deaggregator to associate the end-to-end and aggregate
reservations with one another (using the BOUND_SESSION_ID). reservations with one another (using the BOUND_SESSION_ID).
The key difference between this example and the one shown in Section The key difference between this example and the one shown in Section
4.5 is that the flow identifier for the aggregate is expected to be 4.5 is that the flow identifier for the aggregate is expected to be
different to that for the end-to-end reservation. The aggregate different to that for the end-to-end reservation. The aggregate
reservation can be updated independently of the per-flow end-to-end reservation can be updated independently of the per-flow end-to-end
reservations. reservations.
4.7. Message Binding 4.6. Message Binding
Section 4.6 sketches the interaction of an aggregated end-to-end flow Section 4.5 sketches the interaction of an aggregated end-to-end flow
and an aggregate. For this scenario, and probably others, it is and an aggregate. For this scenario, and probably others, it is
useful to have a method for synchronizing signaling message exchanges useful to have a method for synchronizing signaling message exchanges
of different sessions. This can be used to speed up signaling, of different sessions. This can be used to speed up signaling,
because some message exchanges can be started simultaneously and can because some message exchanges can be started simultaneously and can
be processed in parallel until further processing of a message from be processed in parallel until further processing of a message from
one particular session depends on another message from a different one particular session depends on another message from a different
session. For instance, in Figure 12 there is a case where inclusion session. For instance, in Figure 11 there is a case where inclusion
of a new reservation requires to increase the capacity of the of a new reservation requires to increase the capacity of the
encompassing aggregate first. So the RESERVE (bound message) for the encompassing aggregate first. So the RESERVE (bound message) for the
individual flow arriving at the deaggregator should wait until the individual flow arriving at the deaggregator should wait until the
RESERVE' (binding message) for the aggregate arrived successfully RESERVE' (binding message) for the aggregate arrived successfully
(otherwise the individual flow could not be included into the (otherwise the individual flow could not be included into the
existing aggregate and cannot be admitted). Another alternative existing aggregate and cannot be admitted). Another alternative
would be to increase the aggregate first and then to reserve would be to increase the aggregate first and then to reserve
resources for a set of aggregated individual flows. In this case the resources for a set of aggregated individual flows. In this case the
binding and synchronization between the (RESERVE and RESERVE') binding and synchronization between the (RESERVE and RESERVE')
messages is not needed. messages is not needed.
skipping to change at page 36, line 29 skipping to change at page 35, line 29
carries the associated MSG_ID object. The BOUND_SESSION_ID should carries the associated MSG_ID object. The BOUND_SESSION_ID should
also be set accordingly. Only one MSG_ID or BOUND_MSG_ID object per also be set accordingly. Only one MSG_ID or BOUND_MSG_ID object per
message is allowed. If the dependency relation between the two message is allowed. If the dependency relation between the two
messages is bidirectional then the Message_Binding_Type flag is SET messages is bidirectional then the Message_Binding_Type flag is SET
(value is 1). Otherwise, the Message_Binding_Type flag is UNSET. In (value is 1). Otherwise, the Message_Binding_Type flag is UNSET. In
most cases an RII object must be included in order to get a most cases an RII object must be included in order to get a
corresponding RESPONSE back. corresponding RESPONSE back.
The receiving QNE enqueues (probably after some pre-processing) this The receiving QNE enqueues (probably after some pre-processing) this
message for the corresponding session. It also starts a MsgIDWait message for the corresponding session. It also starts a MsgIDWait
timer (period must be smaller than the retransmission timeout period) timer in order to discard the message in case the related
in order to discard the message in case the related "triggering" "triggering" message (RESERVE' in Figure 15) does not arrive. The
message (RESERVE' in Figure 15) does not arrive. At the same time, timeout period for this time SHOULD be set to the default
the "triggering" message including a MSG_ID object, carrying the same retransmission timeout period (QOSNSLP_REQUEST_RETRY). In case a
value as the BOUND_MSG_ID object is sent by the same initiating QNE retransmitted RESERVE message arrives before the timeout it will
(QNI' in Figure 15). The intermediate QNE' sees the MSG_ID object, simply override the waiting message (i.e. the latter is discarded and
but can determine that it is not the endpoint for the session (QNR') the new message is now waiting with the MsgIDWait timer being reset).
and therefore simply forwards the message after normal processing. At the same time, the "triggering" message including a MSG_ID object,
The receiving QNE (QNR') as endpoint for the aggregate session (i.e., carrying the same value as the BOUND_MSG_ID object is sent by the
deaggregator) interprets the MSG_ID object and looks for a same initiating QNE (QNI' in Figure 13). The intermediate QNE' sees
corresponding waiting message with a BOUND_MSG_ID of the same value the MSG_ID object, but can determine that it is not the endpoint for
whose waiting condition is satisfied now. Depending on successful the session (QNR') and therefore simply forwards the message after
processing of the RESERVE' (3), processing of the waiting RESERVE normal processing. The receiving QNE (QNR') as endpoint for the
will be resumed and the MsgIDWait timer will be stopped as soon as aggregate session (i.e., deaggregator) interprets the MSG_ID object
the related RESERVE' arrived. and looks for a corresponding waiting message with a BOUND_MSG_ID of
the same value whose waiting condition is satisfied now. Depending
on successful processing of the RESERVE' (3), processing of the
waiting RESERVE will be resumed and the MsgIDWait timer will be
stopped as soon as the related RESERVE' arrived.
QNI QNE QNE/QNI' QNE' QNR'/QNE QNR QNI QNE QNE/QNI' QNE' QNR'/QNE QNR
aggregator deaggregator aggregator deaggregator
| | | | | | | | | | | |
| RESERVE | | | | | | RESERVE | | | | |
+--------->| | | | | +--------->| | | | |
| | RESERVE | | | | | | RESERVE | | | |
| +--------->| | | | | +--------->| | | |
| | | RESERVE | | | | | | RESERVE | | |
| | | (1) | | | | | | (1) | | |
skipping to change at page 37, line 39 skipping to change at page 36, line 39
| |<---------+ | | | | |<---------+ | | |
| RESPONSE | | | | | | RESPONSE | | | | |
|<---------+ | | | | |<---------+ | | | |
| | | | | | | | | | | |
| | | | | | | | | | | |
(1): RESERVE: SESSION_ID=F, BOUND_MSG_ID=x, BOUND_SESSION_ID=A (1): RESERVE: SESSION_ID=F, BOUND_MSG_ID=x, BOUND_SESSION_ID=A
(2)+(3): RESERVE': SESSION_ID=A, MSG_ID=x (2)+(3): RESERVE': SESSION_ID=A, MSG_ID=x
(4): RESERVE: SESSION_ID=F (MSG_ID object was removed) (4): RESERVE: SESSION_ID=F (MSG_ID object was removed)
Figure 14: Example for using message binding Figure 13: Example for using message binding
Several further cases have to be considered in this context: Several further cases have to be considered in this context:
o "Triggering message" (3) arrives before waiting (bound) message o "Triggering message" (3) arrives before waiting (bound) message
(1): In this case the processing of the triggering message depends (1): In this case the processing of the triggering message depends
on the value of the Message_Binding_Type flag. If on the value of the Message_Binding_Type flag. If
Message_Binding_Type is UNSET (value is 0) then the triggering Message_Binding_Type is UNSET (value is 0) then the triggering
message can be processed normally, but the MSG_ID and the result message can be processed normally, but the MSG_ID and the result
(success or failure) should be saved for the waiting message. (success or failure) should be saved for the waiting message.
Thus the RESPONSE' can be sent by the QNR' immediately. If the Thus the RESPONSE' can be sent by the QNR' immediately. If the
waiting message (1) finally arrives at the QNR', it can be waiting message (1) finally arrives at the QNR', it can be
detected that the waiting condition was already satisfied, because detected that the waiting condition was already satisfied, because
the triggering message already arrived earlier. If the triggering message already arrived earlier. If
Message_Binding_Type is SET (value is 1) then the triggering Message_Binding_Type is SET (value is 1) then the triggering
message interprets the MSG_ID object and looks for the message interprets the MSG_ID object and looks for the
corresponding waiting message with a BOUND_MSG_ID of the same corresponding waiting message with a BOUND_MSG_ID of the same
value, which in this case has not yet arrived. It then starts a value, which in this case has not yet arrived. It then starts a
MsgIDWait timer in order to discard the message in case the MsgIDWait timer in order to discard the message in case the
related message (RESERVE (1) in Figure 15) does not arrive. related message (RESERVE (1) in Figure 14) does not arrive.
Depending on successful processing of the RESERVE (1), processing Depending on successful processing of the RESERVE (1), processing
of the waiting RESERVE' will be resumed, the MsgIDWait timer will of the waiting RESERVE' will be resumed, the MsgIDWait timer will
be stopped as soon as the related RESERVE arrived and the be stopped as soon as the related RESERVE arrived and the
RESPONSE' can be sent by the QNR' towards the QNI'. RESPONSE' can be sent by the QNR' towards the QNI'.
o The "triggering message" (3) does not arrive at all: this may be o The "triggering message" (3) does not arrive at all: this may be
the case due to message loss (which will cause a retransmission by the case due to message loss (which will cause a retransmission by
the QNI') or due to a reservation failure at an intermediate node the QNI' if the RII object is included) or due to a reservation
(QNE' in the example). The MsgIDWait timeout will then simply failure at an intermediate node (QNE' in the example). The
discard the waiting message at QNR'. In this case the QNR' MAY MsgIDWait timeout will then simply discard the waiting message at
send a RESPONSE message towards the QNI informing that the QNR'. In this case the QNR' MAY send a RESPONSE message towards
synchronisation of the two messages has failed. the QNI informing that the synchronisation of the two messages has
failed.
o Retransmissions should use the same MSG_ID, because usually only o Retransmissions should use the same MSG_ID, because usually only
one message of the two related messages is retransmitted. one message of the two related messages is retransmitted. As
mentioned above: retransmissions will only occur if the RII object
is set in the RESERVE. If a retransmitted message with a MSG_ID
arrives while a bound message with the same MSG_ID is still
waiting, the retransmitted message will replace the bound message.
For a receiving node there are conceptually two lists indexed by For a receiving node there are conceptually two lists indexed by
message IDs. One list contains the IDs and results of triggering message IDs. One list contains the IDs and results of triggering
messages (those carrying a MSG_ID object), the other list contains messages (those carrying a MSG_ID object), the other list contains
the IDs and message contents of the bound waiting messages (those who the IDs and message contents of the bound waiting messages (those who
carried a BOUND_MSG_ID). The former list is used when a triggering carried a BOUND_MSG_ID). The former list is used when a triggering
message arrives before the bound message. The latter list is used message arrives before the bound message. The latter list is used
when a bound message arrives before a triggering message. when a bound message arrives before a triggering message.
4.8. 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 GIST and NSLP functionality which allows the conjunction with GIST and NSLP functionality which allows the
interior nodes to avoid storing GIST and QoS NSLP state. As a result interior nodes to avoid storing GIST and QoS NSLP state. As a result
the interior nodes only store the QSPEC-related reservation state, or the interior nodes only store the QSPEC-related reservation state, or
even no state at all. This allows the QoS model to use a form of even no state at all. This allows the QoS model to use a form of
"reduced-state" operation, where reservation states with a coarser "reduced-state" operation, where reservation states with a coarser
granularity (e.g., per-class) are used, or a "stateless" operation granularity (e.g., per-class) are used, or a "stateless" 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
reservation, i.e., GIST 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.
4.8.1. Sender-initiated Reservation 4.7.1. Sender-initiated Reservation
The QNI initiates a RESERVE message (see Fig. 14). At the QNEs on The QNI initiates a RESERVE message (see Fig. 14). At the QNEs on
the edges of the stateless or reduced-state region the processing is the edges of the stateless or reduced-state region the processing is
different and the nodes support two QoS models. At the ingress the different and the nodes support two QoS models. At the ingress the
original RESERVE message is forwarded but ignored by the stateless or original RESERVE message is forwarded but ignored by the stateless or
reduced-state nodes. This is accomplished by marking this message, reduced-state nodes. This is accomplished by marking this message,
i.e., modifying the QoS NSLP default NSLP-ID value to another NSLP-ID i.e., modifying the QoS NSLP default NSLP-ID value to another NSLP-ID
predefined value (see Section 4.6). The marking must be accomplished predefined value (see Section 4.6). The marking must be accomplished
by the ingress by modifying the QoS_NSLP default NSLP-ID value to a by the ingress by modifying the QoS_NSLP default NSLP-ID value to a
NSLP-ID predefined value. The egress must reassign the QoS NSLP NSLP-ID predefined value. The egress must reassign the QoS NSLP
skipping to change at page 39, line 29 skipping to change at page 38, line 31
The egress node is the next QoS NSLP hop for the end-to-end RESERVE The egress node is the next QoS NSLP hop for the end-to-end RESERVE
message. Reliable GIST transfer mode can be used between the ingress message. Reliable GIST transfer mode can be used between the ingress
and egress without requiring GIST state in the interior. At the and egress without requiring GIST state in the interior. At the
egress node the RESERVE message is then forwarded normally. egress node the RESERVE message is then forwarded normally.
At the ingress a second RESERVE' message is also built (Fig. 14). At the ingress a second RESERVE' message is also built (Fig. 14).
This makes use of a QoS model suitable for a reduced state or This makes use of a QoS model suitable for a reduced state or
stateless form of operation (such as the RMD per hop reservation). stateless form of operation (such as the RMD per hop reservation).
Since the original RESERVE and the RESERVE' messages are addressed Since the original RESERVE and the RESERVE' messages are addressed
identically, the RESERVE' message also arrives at the same egress QNE identically, the RESERVE' message also arrives at the same egress QNE
that was also traversed by the RESERVE message. that was also traversed by the RESERVE message. Message binding is
used to synchronize the messages.
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 GIST use different transport characteristics NSLP also requests that GIST use different transport characteristics
(e.g., sending of messages in unreliable GIST transfer mode). It (e.g., sending of messages in unreliable GIST transfer mode). It
also requests the local GIST processing not to retain messaging also requests the local GIST processing not to retain messaging
association state or reverse message routing state. association state or reverse message routing state.
skipping to change at page 40, line 31 skipping to change at page 39, line 35
|<---------------------------------------------+ |<---------------------------------------------+
| | | | RESERVE | | | | RESERVE
| | | +--------> | | | +-------->
| | | | RESPONSE | | | | RESPONSE
| | | |<-------- | | | |<--------
| | | RESPONSE | | | | RESPONSE |
|<---------------------------------------------+ |<---------------------------------------------+
RESPONSE| | | | RESPONSE| | | |
<--------| | | | <--------| | | |
Figure 15: Sender-initiated reservation with Reduced State Interior Figure 14: Sender-initiated reservation with Reduced State Interior
Nodes Nodes
4.8.2. Receiver-initiated Reservation 4.7.2. Receiver-initiated Reservation
Since NSLP neighbor relationships are not maintained in the reduced- Since NSLP neighbor relationships are not maintained in the reduced-
state region, only sender-initiated signaling can be supported within state region, only sender-initiated signaling can be supported within
the reduced state region. If a receiver-initiated reservation over a the reduced state region. If a receiver-initiated reservation over a
stateless or reduced state domain is required this can be implemented stateless or reduced state domain is required this can be implemented
as shown in Figure 16. as shown in Figure 15.
QNE QNE QNE QNE QNE QNE
ingress interior egress ingress interior egress
GIST stateful GIST stateless GIST stateful GIST stateful GIST stateless GIST stateful
| | | | | |
QUERY | | | QUERY | | |
-------->| QUERY | | -------->| QUERY | |
+------------------------------>| +------------------------------>|
| | | QUERY | | | QUERY
| | +--------> | | +-------->
skipping to change at page 41, line 25 skipping to change at page 40, line 25
| | |<-------- | | |<--------
| | RESERVE | | | RESERVE |
|<------------------------------+ |<------------------------------+
| RESERVE' | RESERVE' | | RESERVE' | RESERVE' |
|-------------->|-------------->| |-------------->|-------------->|
| | RESPONSE' | | | RESPONSE' |
|<------------------------------+ |<------------------------------+
RESERVE | | | RESERVE | | |
<--------| | | <--------| | |
Figure 16: Receiver-initiated reservation with Reduced State Interior Figure 15: Receiver-initiated reservation with Reduced State Interior
Nodes Nodes
The RESERVE message that is received by the egress QNE of the The RESERVE message that is received by the egress QNE of the
stateless domain is sent transparently to the ingress QNE (known as stateless domain is sent transparently to the ingress QNE (known as
the source of the QUERY message). When the RESERVE message reaches the source of the QUERY message). When the RESERVE message reaches
the ingress, the ingress QNE needs to send a sender- initiated the ingress, the ingress QNE needs to send a sender- initiated
RESERVE' over the stateless domain. The ingress QNE needs to wait RESERVE' over the stateless domain. The ingress QNE needs to wait
for a RESPONSE'. If the RESPONSE' notifies that the reservation was for a RESPONSE'. If the RESPONSE' notifies that the reservation was
accomplished successfully then the ingress QNE sends a RESERVE accomplished successfully then the ingress QNE sends a RESERVE
message further upstream. message further upstream.
4.9. Proxy Mode 4.8. Proxy Mode
Besides the sender- and receiver-initiated reservations, the QoS NSLP Besides the sender- and receiver-initiated reservations, the QoS NSLP
includes a functionality we refer to as Proxy Mode. Here a QNE is includes a functionality we refer to as Proxy Mode. Here a QNE is
set by administrator assignment to work as a proxy QNE (P-QNE) for a set by administrator assignment to work as a proxy QNE (P-QNE) for a
certain region, e.g., for an administrative domain. A node certain region, e.g., for an administrative domain. A node
initiating the signaling may set the PROXY scope flag to indicate initiating the signaling may set the PROXY scope flag to indicate
that the signaling is meant to be confined within the area controlled that the signaling is meant to be confined within the area controlled
by the proxy, e.g., the local access network. by the proxy, e.g., the local access network.
The Proxy Mode has two uses. First it allows to confine the QoS NSLP The Proxy Mode has two uses. First it allows to confine the QoS NSLP
skipping to change at page 43, line 50 skipping to change at page 42, line 50
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |B|A|P|S| | Reserved |B|A|P|S|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
SCOPING (S) - 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").
PROXY (P) - when set, indicates that the message is scoped, and PROXY (P) - when set, indicates that the message is scoped, and
should not travel down the entire path but only as far as the P- QNE. should not travel down the entire path but only as far as the P-QNE.
By default, this flag is not set. By default, this flag is not set.
ACK-REQ (A) - when set, indicates that the message should be ACK-REQ (A) - when set, indicates that the message should be
acknowledged by the receiving peer. The flag is only used between acknowledged by the receiving peer. The flag is only used between
stateful peers, and only used with RESERVE and QUERY messages. stateful peers, and only used with RESERVE and QUERY messages.
Currently, the flag is only used with refresh messages. By default Currently, the flag is only used with refresh messages. By default
the flag is not set. the flag is not set.
BREAK (B) - when set, indicates that there are routers along the path BREAK (B) - when set, indicates that there are routers along the path
where QoS cannot be provided. where QoS cannot be provided.
The set of appropriate flags depends on the particular message being The set of appropriate flags depends on the particular message being
processed. Any bit not defined as a flag for a particular message processed. Any bit not defined as a flag for a particular message
MUST be set to zero on sending and MUST be ignored on receiving. MUST be set to zero on sending and MUST be ignored on receiving.
The ACK-REQ flag is useful when a QNE wants to make sure the messages The ACK-REQ flag is useful when a QNE wants to make sure the messages
received by the downstream QNE are truly processed by the QoS NSLP, received by the downstream QNE are truly processed by the QoS NSLP,
not just delivered by GIST. This is useful for faster dead peer not just delivered by GIST. This is useful for faster dead peer
diagnostics on the NSLP layer. This liveliness test can only be used diagnostics on the NSLP layer. This liveliness test can only be used
with refresh RESERVE mesasages. The ACK-REQ-flag must not be set for with refresh RESERVE messages. The ACK-REQ-flag must not be set for
RESERVE messages that already include an RII object, since a RESERVE messages that already include an RII object, since a
confirmation has already been requested from the QNR. Reliable confirmation has already been requested from the QNR. Reliable
transmission of messages between two QoS NSLP peer should be handled transmission of messages between two QoS NSLP peer should be handled
by GIST, not the NSLP by itself. by GIST, not the NSLP by itself.
5.1.2. Message Formats 5.1.2. Message Formats
5.1.2.1. RESERVE 5.1.2.1. RESERVE
The format of a RESERVE message is as follows: The format of a RESERVE message is as follows:
skipping to change at page 45, line 5 skipping to change at page 44, line 5
PACKET_CLASSIFIER is not provided, then the full set of information PACKET_CLASSIFIER is not provided, then the full set of information
provided in the GIST MRI for the session should be used for packet provided in the GIST MRI for the session should be used for packet
classification purposes. classification purposes.
Subsequent RESERVE messages meant as reduced refreshes, where no Subsequent RESERVE messages meant as reduced refreshes, where no
QSPEC is provided, MUST NOT include a PACKET_CLASSIFIER either. QSPEC is provided, MUST NOT include a PACKET_CLASSIFIER either.
There are no requirements on transmission order, although the above There are no requirements on transmission order, although the above
order is recommended. order is recommended.
Three message-specific flags are defined for use in the common header Two message-specific flags are defined for use in the common header
with the RESERVE message. These are: with the RESERVE message. These are:
+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+
|Reserved |Q|T|R| |Reserved |T|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. The former is indicated to the operation state should be torn down. The former is indicated to the
RMF. Depending on the QoS model, the tear message may include a RMF. Depending on the QoS model, the tear message may include a
QSPEC to further specify state removal, e.g., for an aggregation, the QSPEC to further specify state removal, e.g., for an aggregation, the
QSPEC may specify the amount of resources removed from the aggregate. QSPEC may specify the amount of resources removed from the aggregate.
REPLACE (R) - when set the flag has two uses. First, it indicates REPLACE (R) - when set the flag has two uses. First, it indicates
that a RESERVE with different MRI (but same SID) replaces an existing that a RESERVE with different MRI (but same SID) replaces an existing
one, so the old one MAY be torn down immediately. This is the one, so the old one MAY be torn down immediately. This is the
default situation. This flag may be unset to indicate a desire from default situation. This flag may be unset to indicate a desire from
an upstream node to keep an existing reservation on an old branch in an upstream node to keep an existing reservation on an old branch in
place. Second, this flag is also used to indicate whether the place. Second, this flag is also used to indicate whether the
reserved resources on the old branch should be torn down or not when reserved resources on the old branch should be torn down or not when
a data path change happens. In this case, the MRI is the same and a data path change happens. In this case, the MRI is the same and
only the route path changes. only the route path changes.
REQUEST REDUCED REFRESHES (Q) - when set, indicates the sender of the
RESERVE proposes to use the reduced refresh for this session.
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 SHOULD include the SESSION_ID of that other session RESERVE message SHOULD include the SESSION_ID of that other session
in a BOUND_SESSION_ID object. In the situation of aggregated in a BOUND_SESSION_ID object. In the situation of aggregated
tunnels, the aggregated session MAY not include the SESSION_ID of its tunnels, the aggregated session MAY not include the SESSION_ID of its
bound sessions in BOUND_SESSION_ID(s). bound sessions in BOUND_SESSION_ID(s).
A "reservation collision" may occur if the sender believes that a The negotiation of whether to perform sender or receiver-initiated
sender-initiated reservation should be performed for a flow, whilst signaling is done outside the QoS NSLP. Yet, in theory, it is
the other end believes that it should be starting a receiver- possible that a "reservation collision" may occur if the sender
initiated reservation. If different session identifiers are used believes that a sender-initiated reservation should be performed for
then this error condition is transparent to the QoS NSLP though it a flow, whilst the other end believes that it should be starting a
may result in an error from the RMF, otherwise the removal of the receiver- initiated reservation. If different session identifiers
duplicate reservation is left to the QNIs/QNRs for the two sessions. are used then this error condition is transparent to the QoS NSLP
though it may result in an error from the RMF, otherwise the removal
of the duplicate reservation is left to the QNIs/QNRs for the two
sessions.
If a reservation is already installed and a RESERVE message is If a reservation is already installed and a RESERVE message is
received with the same session identifier from the other direction received with the same session identifier from the other direction
(i.e., going upstream where the reservation was installed by a (i.e., going upstream where the reservation was installed by a
downstream RESERVE message, or vice versa) then an error indicating downstream RESERVE message, or vice versa) then an error indicating
"RESERVE received from wrong direction" MUST be sent in a RESPONSE "RESERVE received from wrong direction" MUST be sent in a RESPONSE
message to the signaling message source for this second RESERVE. message to the signaling message source for this second RESERVE.
A refresh right along the path can be forced by requesting a RESPONSE A refresh right along the path can be forced by requesting a RESPONSE
from the far end (i.e., by including an RII object in the RESERVE from the far end (i.e., by including an RII object in the RESERVE
skipping to change at page 46, line 21 skipping to change at page 45, line 21
A QNE may ask for confirmation of tear operation by including an RII A QNE may ask for confirmation of tear operation by including an RII
object. Retransmissions SHOULD be disabled. A QNE sending a tearing object. Retransmissions SHOULD be disabled. A QNE sending a tearing
RESERVE with an RII included MAY ask GIST to use reliable transport. RESERVE with an RII included MAY ask GIST to use reliable transport.
When the QNE sends out a tearing RESERVE, it MUST NOT send refresh When the QNE sends out a tearing RESERVE, it MUST NOT send refresh
messages anymore. messages anymore.
If the routing path changed due to mobility and the mobile node's IP If the routing path changed due to mobility and the mobile node's IP
address changed, and it sent a Mobile IP binding update, the address changed, and it sent a Mobile IP binding update, the
resulting refresh is a new RESERVE. This RESERVE includes a new MRI resulting refresh is a new RESERVE. This RESERVE includes a new MRI
and will be propagated end-to-end without requesting a RESPONSE. and will be propagated end-to-end; there is no need to force end-to-
end forwarding by including an RII.
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 refreshing RESERVE messages. It force the QNEs on the path to send refreshing RESERVE messages. It
may, therefore, be appropriate for QNEs to perform rate limiting on may, therefore, be appropriate for QNEs to perform rate limiting on
the refresh messages that they send. the refresh messages that they send.
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
skipping to change at page 54, line 11 skipping to change at page 52, line 51
* 0x06 - Mismatching RSN in RSN LIST * 0x06 - Mismatching RSN in RSN LIST
o Success: o Success:
* 0x01 - Reservation successful * 0x01 - Reservation successful
* 0x02 - Tear down successful * 0x02 - Tear down successful
* 0x03 - Acknowledgement * 0x03 - Acknowledgement
* 0x04 - Refresh successful o Protocol Error: * 0x04 - Refresh successful
o Protocol Error:
* 0x01 - Illegal message type: the type given in the Message Type * 0x01 - Illegal message type: the type given in the Message Type
field of the common header is unknown. field of the common header is unknown.
* 0x02 - Wrong message length: the length given for the message does * 0x02 - Wrong message length: the length given for the message does
not match the length of the message data. not match the length of the message data.
* 0x03 - Bad flags value: an undefined flag or combination of flags * 0x03 - Bad flags value: an undefined flag or combination of flags
was set in the generic flags was set in the generic flags
skipping to change at page 57, line 22 skipping to change at page 56, line 20
This object provides information about the type of object which This object provides information about the type of object which
caused the error. caused the error.
If a field in an object had an incorrect value, the following If a field in an object had an incorrect value, the following
optional error-specific information may be added at the end of the optional error-specific information may be added at the end of the
INFO_SPEC. INFO_SPEC.
Object Value Info: Object Value Info:
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 0 1 2 3
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
Rsvd | Real Object Length | Offset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rsvd | Real Object Length | Offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// Object // // Object //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Real Object Length: Since the length in the original TLV header may Real Object Length: Since the length in the original TLV header may
be inaccurate, this field provides the actual length of the object be inaccurate, this field provides the actual length of the object
(including the TLV Header) included in the error message. (including the TLV Header) included in the error message.
Offset: The byte in the object at which the QNE found the error. Offset: The byte in the object at which the QNE found the error.
When this byte is set to "0", the complete object is included. When this byte is set to "0", the complete object is included.
skipping to change at page 64, line 43 skipping to change at page 64, line 12
After detecting an upstream route change a QNE SHOULD consider the After detecting an upstream route change a QNE SHOULD consider the
new upstream peer as current and not fall back to the old upstream new upstream peer as current and not fall back to the old upstream
peer unless: peer unless:
- it stops receiving refreshes from the old upstream peer for at - it stops receiving refreshes from the old upstream peer for at
least the soft state timeout period and then starts receiving least the soft state timeout period and then starts receiving
messages from the old upstream peer again messages from the old upstream peer again
- or, it stops receiving refreshes from the new upstream peer for at - or, it stops receiving refreshes from the new upstream peer for at
least the soft state timeout period least the soft state timeout period.
GIST routing state keeps track of the latest upstream peer it has GIST routing state keeps track of the latest upstream peer it has
seen, and so may spuriously indicate route changes occur when the old seen, and so may spuriously indicate route changes occur when the old
upstream peer refreshes its routing state until the state at that upstream peer refreshes its routing state until the state at that
node is explicitly torn down or times out. node is explicitly torn down or times out.
5.3. Object Processing 5.3. Object Processing
This section presents processing rules for individual QoS NSLP This section presents processing rules for individual QoS NSLP
objects. objects.
skipping to change at page 77, line 12 skipping to change at page 76, line 35
reverse path state. In this case, if the QNE is not the QNI, it reverse path state. In this case, if the QNE is not the QNI, it
creates a new QUERY message to send downstream. If the QUERY creates a new QUERY message to send downstream. If the QUERY
contained a QSPEC, it MUST be passed to the RMF where it may be contained a QSPEC, it MUST be passed to the RMF where it may be
modified by the QoS Model specific QUERY processing. If the QNE is modified by the QoS Model specific QUERY processing. If the QNE is
the QNI, the QNE creates a RESERVE message, which contains a QSPEC the QNI, the QNE creates a RESERVE message, which contains a QSPEC
received from the RMF and which may be based on the received QSPEC. received from the RMF and which may be based on the received QSPEC.
If this node was not expecting to perform a receiver-initiated If this node was not expecting to perform a receiver-initiated
reservation then an error MUST be sent back along the path. reservation then an error MUST be sent back along the path.
If an RII object is present, and if the QNE is the QNR, the SCOPING If an RII object is present, and if the QNE is the QNR, the SCOPING
flag is set or the PROXY scope flag is set and the QNE is a p-QNE, flag is set or the PROXY scope flag is set and the QNE is a P-QNE,
the QNE MUST generate a RESPONSE message and pass it back along the the QNE MUST generate a RESPONSE message and pass it back along the
reverse of the path used by the QUERY. 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 GIST 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)
skipping to change at page 79, line 30 skipping to change at page 79, line 4
may be sent in either direction (upstream or downstream). may be sent in either direction (upstream or downstream).
A special case of synchronous NOTIFY is when the upstream QNE asked A special case of synchronous NOTIFY is when the upstream QNE asked
to use reduced refresh by setting the appropriate flag in the to use reduced refresh by setting the appropriate flag in the
RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY RESERVE. The QNE receiving such a RESERVE MUST reply with a NOTIFY
and a proper INFO_SPEC code whether the QNE agrees to use reduced and a proper INFO_SPEC code whether the QNE agrees to use reduced
refresh between the upstream QNE. refresh between the upstream QNE.
The Transient error code 0x07 "Reservation preempted" is sent to the The Transient error code 0x07 "Reservation preempted" is sent to the
QNI whose resources were preempted. The NOTIFY message carries QNI whose resources were preempted. The NOTIFY message carries
information to the QNI that one QNE no longer has a reservation for information to the QNI that one QNE no longer has a reservation for
the session. It is up to the QNI to decice what to do based on the the session. It is up to the QNI to decide what to do based on the
QoS Model being used. The QNI would normally tear down the preempted QoS Model being used. The QNI would normally tear down the preempted
reservation by sending a RESERVE with the TEAR flag set using the SII reservation by sending a RESERVE with the TEAR flag set using the SII
of the preempted reservation. However, the QNI can follow other of the preempted reservation. However, the QNI can follow other
procedures as specified in its QoS Model. More discussion on procedures as specified in its QoS Model. More discussion on
preemption can be found in the QSPEC Template [I-D.ietf-nsis-qspec] preemption can be found in the QSPEC Template [I-D.ietf-nsis-qspec]
and the individual QoS Model specifications. and the individual QoS Model specifications.
6. IANA Considerations 6. IANA Considerations
This section provides guidance to the Internet Assigned Numbers This section provides guidance to the Internet Assigned Numbers
skipping to change at page 81, line 41 skipping to change at page 81, line 18
is identified by a 4 bit value. The value 0 is reserved, all other is identified by a 4 bit value. The value 0 is reserved, all other
values are assigned on a basis of Specification Required, except for values are assigned on a basis of Specification Required, except for
14 and 15 which are for Experimental/Private Use. 14 and 15 which are for Experimental/Private Use.
Initial assignments are given in section 5.1.3.4. Initial assignments are given in section 5.1.3.4.
6.6. NSLP IDs and Router Alert Option Values 6.6. NSLP IDs and Router Alert Option Values
This specification defines an NSLP for use with GIST. Furthermore it This specification defines an NSLP for use with GIST. Furthermore it
specifies that a number of NSLP-ID values are used for the support of specifies that a number of NSLP-ID values are used for the support of
bypassing intermediary nodes (see Section [FIXME]). Consequently, bypassing intermediary nodes. Consequently, new identifiers must be
new identifiers must be assigned for them from the GIST NSLP assigned for them from the GIST NSLP identifier registry. The QoS
identifier registry. The QoS NSLP requires that 32 NSLP-ID values be NSLP requires that 32 NSLP-ID values be assigned, corresponding to
assigned, corresponding to QoS NSLP Aggregation Levels 0 to 31. QoS NSLP Aggregation Levels 0 to 31.
The GIST specification also requires that NSLP-IDs be associated with The GIST specification also requires that NSLP-IDs be associated with
specific Router Alert Option (RAO) values (although multiple NSLP-IDs specific Router Alert Option (RAO) values (although multiple NSLP-IDs
may be associated with the same value). For the purposes of the QoS may be associated with the same value). For the purposes of the QoS
NSLP, each of its NSLP-ID values should be associated with a NSLP, each of its NSLP-ID values should be associated with a
different RAO value. This requires that a block of 32 new IPv4 RAO different RAO value. This requires that a block of 32 new IPv4 RAO
values and a block of 32 new IPv6 RAO values be assigned, values and a block of 32 new IPv6 RAO values be assigned,
corresponding to QoS NSLP Aggregation Levels 0 to 31. corresponding to QoS NSLP Aggregation Levels 0 to 31.
7. Security Considerations 7. Security Considerations
skipping to change at page 84, line 31 skipping to change at page 83, line 40
Legend: Legend:
----> Peering relationship which allows neighboring ----> Peering relationship which allows neighboring
networks/entities to charge each other for the networks/entities to charge each other for the
QoS reservation and data traffic QoS reservation and data traffic
====> Data flow ====> Data flow
.... Communication to the end host .... Communication to the end host
Figure 44: New Jersey Turnpike Model Figure 42: New Jersey Turnpike Model
The model shown in Figure 44 uses peer-to-peer relationships between The model shown in Figure 42 uses peer-to-peer relationships between
different administrative domains as a basis for accounting and different administrative domains as a basis for accounting and
charging. As mentioned above, based on the peering relationship a charging. As mentioned above, based on the peering relationship a
chain-of-trust is established. There are several issues which come chain-of-trust is established. There are several issues which come
to mind when considering this type of model: to mind when considering this type of model:
o The model allows authorization on a request basis or on a per- o The model allows authorization on a request basis or on a per-
session basis. Authorization mechanisms are elaborated in Section session basis. Authorization mechanisms are elaborated in Section
4.9. The duration for which the QoS authorization is valid needs to 4.9. The duration for which the QoS authorization is valid needs to
be controlled. Combining the interval with the soft-state interval be controlled. Combining the interval with the soft-state interval
is possible. Notifications from the networks also seem to be viable is possible. Notifications from the networks also seem to be viable
skipping to change at page 85, line 9 skipping to change at page 84, line 20
charged entity is attached. Protocols providing Advice of Charge charged entity is attached. Protocols providing Advice of Charge
functionality are out of scope. functionality are out of scope.
o This architecture is simple enough to allow a scalable solution o This architecture is simple enough to allow a scalable solution
(ignoring reverse charging, multicast issues and price distribution). (ignoring reverse charging, multicast issues and price distribution).
Charging the data sender as performed in the model simplifies Charging the data sender as performed in the model simplifies
security handling by demanding only peer-to-peer security protection. security handling by demanding only peer-to-peer security protection.
Node A would perform authentication and key establishment. The Node A would perform authentication and key establishment. The
established security association (together with the session key) established security association (together with the session key)
would allow the user to protect QoS signaling messages. The identity would allow the user to protect QoS signaling messages. The identity
used during the authentication and key establishment phase would be used during the authentication and key establishment phase would be
used by Network X (see Figure 44) to perform the so-called policy- used by Network X (see Figure 42) to perform the so-called policy-
based admission control procedure. In our context this user based admission control procedure. In our context this user
identifier would be used to establish the necessary infrastructure to identifier would be used to establish the necessary infrastructure to
provide authorization and charging. Signaling messages later provide authorization and charging. Signaling messages later
exchanged between the different networks are then also subject to exchanged between the different networks are then also subject to
authentication and authorization. The authenticated entity thereby authentication and authorization. The authenticated entity thereby
is, however, the neighboring network and not the end host. is, however, the neighboring network and not the end host.
The New Jersey Turnpike model is attractive because of its The New Jersey Turnpike model is attractive because of its
simplicity. S. Schenker et. al. [shenker] discuss various accounting simplicity. S. Schenker et. al. [shenker] discuss various accounting
implications and introduced the edge pricing model. The edge pricing implications and introduced the edge pricing model. The edge pricing
skipping to change at page 85, line 34 skipping to change at page 84, line 44
the exception that mobility and the security implications itself are the exception that mobility and the security implications itself are
not addressed. not addressed.
7.2. Authorization Model Examples 7.2. Authorization Model Examples
Various authorization models can be used in conjunction with the QoS Various authorization models can be used in conjunction with the QoS
NSLP. NSLP.
7.2.1. Authorization for the Two Party Approach 7.2.1. Authorization for the Two Party Approach
The two party approach (Figure 45) is conceptually the simplest The two party approach (Figure 43) is conceptually the simplest
authorization model. authorization model.
+-------------+ QoS request +--------------+ +-------------+ QoS request +--------------+
| Entity |----------------->| Entity | | Entity |----------------->| Entity |
| requesting | | authorizing | | requesting | | authorizing |
| resource |granted / rejected| resource | | resource |granted / rejected| resource |
| |<-----------------| request | | |<-----------------| request |
+-------------+ +--------------+ +-------------+ +--------------+
^ ^ ^ ^
+...........................+ +...........................+
compensation compensation
Figure 45: Two party approach Figure 43: Two party approach
In this example the authorization decision only involves the two In this example the authorization decision only involves the two
entities, or makes use of previous authorization using an out-of-band entities, or makes use of previous authorization using an out-of-band
mechanism to avoid the need for active participation of an external mechanism to avoid the need for active participation of an external
entity during the NSIS protocol execution. entity during the NSIS protocol execution.
This type of model may be applicable, e.g., between two neighboring This type of model may be applicable, e.g., between two neighboring
networks (inter-domain signaling) where a long-term contract (or networks (inter-domain signaling) where a long-term contract (or
other out-of-band mechanisms) exists to manage charging and provides other out-of-band mechanisms) exists to manage charging and provides
sufficient information to authorize individual requests. sufficient information to authorize individual requests.
7.2.2. Token-based Three Party Approach 7.2.2. Token-based Three Party Approach
An alternative approach makes use of tokens, such as those described An alternative approach makes use of tokens, such as those described
in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the in RFC 3520 [RFC3520] and RFC 3521 [RFC3521] or used as part of the
Open Settlement Protocol [osp]. Authorization tokens are used to Open Settlement Protocol [osp]. Authorization tokens are used to
associate two different signaling protocols runs (e.g., SIP and NSIS) associate two different signaling protocols runs (e.g., SIP and NSIS)
and their authorization decision with each other. The latter is a and their authorization decision with each other. The latter is a
form of assertion or trait. As an example, with the authorization form of assertion or trait. As an example, with the authorization
token mechanism, some form of authorization is provided by the SIP token mechanism, some form of authorization is provided by the SIP
proxy, which acts as the resource authorizing entity in Figure 46. proxy, which acts as the resource authorizing entity in Figure 44.
If the request is authorized, then the SIP signaling returns an If the request is authorized, then the SIP signaling returns an
authorization token which can be included in the QoS signaling authorization token which can be included in the QoS signaling
protocol messages to refer to the previous authorization decision. protocol messages to refer to the previous authorization decision.
The tokens themselves may take a number of different forms, some of The tokens themselves may take a number of different forms, some of
which may require the entity performing the QoS reservation to query which may require the entity performing the QoS reservation to query
external state. external state.
Authorization Authorization
Token Request +--------------+ Token Request +--------------+
+-------------->| Entity C | financial settlement +-------------->| Entity C | financial settlement
skipping to change at page 86, line 48 skipping to change at page 86, line 26
| | . | | .
| | . | | .
| | QoS request . | | QoS request .
+-------------+ + Authz. Token +--------------+ . +-------------+ + Authz. Token +--------------+ .
| Entity |----------------->| Entity B | . | Entity |----------------->| Entity B | .
| requesting | | performing | . | requesting | | performing | .
| resource |granted / rejected| QoS | <..+ | resource |granted / rejected| QoS | <..+
| A |<-----------------| reservation | | A |<-----------------| reservation |
+-------------+ +--------------+ +-------------+ +--------------+
Figure 46: Token based three party approach Figure 44: Token based three party approach
For the digital money type of systems (e.g., OSP tokens), the token For the digital money type of systems (e.g., OSP tokens), the token
represents a limited amount of credit. So, new tokens must be sent represents a limited amount of credit. So, new tokens must be sent
with later refresh messages once the credit is exhausted. with later refresh messages once the credit is exhausted.
7.2.3. Generic Three Party Approach 7.2.3. Generic Three Party Approach
Another method is for the node performing the QoS reservation to Another method is for the node performing the QoS reservation to
delegate the authorization decision to a third party, as illustrated delegate the authorization decision to a third party, as illustrated
in Figure 47. The authorization decision may be performed on a per- in Figure 45. The authorization decision may be performed on a per-
request basis, periodically, or on a per-session basis. request basis, periodically, or on a per-session basis.
+--------------+ +--------------+
| Entity C | | Entity C |
| authorizing | | authorizing |
| resource | | resource |
| request | | request |
+-----------+--+ +-----------+--+
^ | ^ |
QoS | | QoS QoS | | QoS
authz| |authz authz| |authz
req.| | res. req.| | res.
QoS | v QoS | v
+-------------+ request +--+-----------+ +-------------+ request +--+-----------+
| Entity |----------------->| Entity B | | Entity |----------------->| Entity B |
| requesting | | performing | | requesting | | performing |
| resource |granted / rejected| QoS | | resource |granted / rejected| QoS |
| A |<-----------------| reservation | | A |<-----------------| reservation |
+-------------+ +--------------+ +-------------+ +--------------+
Figure 47: Three party approach Figure 45: Three party approach
7.3. Computing the Authorization Decision 7.3. Computing the Authorization Decision
Whenever an authorization decision has to be made then there is the Whenever an authorization decision has to be made then there is the
question which information serves as an input to the authorizing question which information serves as an input to the authorizing
entity. The following information items have been mentioned in the entity. The following information items have been mentioned in the
past for computing the authorization decision (in addition to the past for computing the authorization decision (in addition to the
authenticated identity): authenticated identity):
Price Price
skipping to change at page 88, line 20 skipping to change at page 88, line 13
especially, has done deep reviews of the document, making sure the especially, has done deep reviews of the document, making sure the
protocol is well defined. Bob Braden provided helpful comments and protocol is well defined. Bob Braden provided helpful comments and
guidance which were gratefully received. guidance which were gratefully received.
9. Contributors 9. Contributors
This draft combines work from three individual drafts. The following This draft combines work from three individual drafts. The following
authors from these drafts also contributed to this document: Robert authors from these drafts also contributed to this document: Robert
Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia Hancock (Siemens/Roke Manor Research), Hannes Tschofenig and Cornelia
Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and Kappler (Siemens AG), Lars Westberg and Attila Bader (Ericsson) and
Maarten Buechli (Dante) and Eric Waegeman (Alcatel). Maarten Buechli (Dante) and Eric Waegeman (Alcatel). In addition,
Roland Bless has contributed considerable amounts of text all along
the writing of this specification.
Sven Van den Bosch was the first editor of the draft. Since version Sven Van den Bosch was the first editor of the draft. Since version
06 of the draft, Jukka Manner has taken the editorship. Yacine El 06 of the draft, Jukka Manner has taken the editorship. Yacine El
Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning Mghazli (Alcatel) contributed text on AAA. Charles Shen and Henning
Schulzrinne suggested the use of the reason field in the Schulzrinne suggested the use of the reason field in the
BOUND_SESSION_ID. BOUND_SESSION_ID.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-nsis-ntlp] [I-D.ietf-nsis-ntlp]
Schulzrinne, H. and R. Hancock, "GIST: General Internet Schulzrinne, H. and R. Hancock, "GIST: General Internet
Signalling Transport", draft-ietf-nsis-ntlp-13 (work in Signalling Transport", draft-ietf-nsis-ntlp-14 (work in
progress), April 2007. progress), July 2007.
[I-D.ietf-nsis-qspec] [I-D.ietf-nsis-qspec]
Ash, J., "QoS NSLP QSPEC Template", Ash, J., "QoS NSLP QSPEC Template",
draft-ietf-nsis-qspec-16 (work in progress), March 2007. draft-ietf-nsis-qspec-17 (work in progress), July 2007.
[RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982, [RFC1982] Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
August 1996. August 1996.
[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.
10.2. Informative References 10.2. Informative References
[I-D.ietf-nsis-applicability-mobility-signaling]
Lee, S., "Applicability Statement of NSIS Protocols in
Mobile Environments",
draft-ietf-nsis-applicability-mobility-signaling-07 (work
in progress), July 2007.
[I-D.ietf-nsis-rmd] [I-D.ietf-nsis-rmd]
Bader, A., "RMD-QOSM - The Resource Management in Diffserv Bader, A., "RMD-QOSM - The Resource Management in Diffserv
QOS Model", draft-ietf-nsis-rmd-09 (work in progress), QOS Model", draft-ietf-nsis-rmd-10 (work in progress),
March 2007. June 2007.
[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", Services in the Internet Architecture: an Overview",
RFC 1633, June 1994. RFC 1633, June 1994.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997. Functional Specification", RFC 2205, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
 End of changes. 85 change blocks. 
195 lines changed or deleted 183 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/