One document matched: draft-westberg-proposal-for-rsvpv2-01.txt
Differences from draft-westberg-proposal-for-rsvpv2-00.txt
Internet Draft Proposal for RSVPv2 October 2002
Internet Engineering Task Force L. Westberg
INTERNET-DRAFT G. Karagiannis
Expires April 2003 D. Partain
V. Rexhepi
Ericsson
October 2002
A Proposal for RSVPv2
draft-westberg-proposal-for-rsvpv2-01.txt
Status of this memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts. Internet-Drafts are draft documents valid for a maximum of
six months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet- Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2002). All Rights Reserved.
Westberg, et al. Expires April 2003 [Page 1]
Internet Draft Proposal for RSVPv2 October 2002
Abstract
The Resource ReSerVation Protocol (RSVPv1) has been on the standards
track within the IETF for a number of years. During that time, the
level of vendor support and deployment has been relatively slow,
despite the desire of many to deploy technology to deliver services
with different levels of quality of service (QoS) to their customers.
The reasons for this are arguably well-understood and documented and
are not the focus of this memo. This memo seeks to initiate a dialog
about the design of a new version of RSVPv1, which we call RSVPv2.
The RSVPv2 framework could use the combination of two concepts. The
concept of ALSP (Application Layer Signaling Protocol) and the
concept of Common Signaling Transport Protocol (CSTP).
This memo outlines the motivation for doing this work and provides
design guidelines and specifications for the development of the
RSVPv2 ALSP. RSVPv2 ALSP is an ALSP type that can be a part of the
RSVPv2 framework.
Westberg, et al. Expires April 2003 [Page 2]
Internet Draft Proposal for RSVPv2 October 2002
Table of Contents
1 Introduction ................................................. 5
1.1 Definitions/Terminology .................................... 5
2 Motivation for RSVPv2 ........................................ 10
2.1 Effects of the Design of RSVPv1 ............................ 10
2.1.1 Designed for Multicast Applications ...................... 11
2.1.2 Least Common Denominator Not Small Enough ................ 11
2.1.3 Sender-initiated versus Receiver-initiated Signalling
........................................................... 12
2.1.4 Designed for End-host to End-host Communication .......... 12
2.2 Different Network Signalling Requirements/Needs and RSVP
........................................................... 13
3 Design Goals and General Features for RSVPv2-ALSP ............ 14
3.1 Increased Modularity and Extendability ..................... 14
3.2 Increased Object Modularity ................................ 15
3.3 Hierarchical Object Structure .............................. 16
3.4 Global and Local Objects ................................... 16
3.5 Local information exchange ................................. 17
3.6 Object Re-use .............................................. 17
3.7 Reduced Focus on Multicast ................................. 17
3.8 Primarily Sender-initiated Signalling ...................... 17
3.9 Low latency in setup ....................................... 18
3.10 Highest possible network utilization ...................... 18
3.11 Uni / bi-directional reservation .......................... 18
3.12 End-to-end ................................................ 18
3.13 Edge-to-edge .............................................. 19
3.14 End-to-edge ............................................... 19
4 Overview of the RSVPv2-ALSP Framework ........................ 19
4.1 RSVPv2 protocol features provided by the intra-domain
level ..................................................... 23
4.1.1 PDR protocol part functions .............................. 23
4.1.2 PHR protocol part functions .............................. 24
4.2 CSTP protocol functions needed by the RSVPv2 ALSP .......... 26
4.3 RSVPv2 ALSP protocol features provided by the e2e service
level ..................................................... 27
5 RSVPv2 ALSP specification .................................... 28
5.1 RSVPv2 ALSP Object Classes structure ....................... 28
5.1.1 Combined CSTP and RSVPv2 ALSP Message Structure .......... 29
5.1.1.1 Message Structure for inter-domain signaling ........... 30
5.1.1.2 Message Structure for intra-domain signaling ........... 31
5.1.1.3 Format of RSVPv2 ALSP SAPUs ............................ 32
5.2 RSVPv2 ALSP Objects in RSVPv2 ALSP Object_Classes .......... 34
5.2.1 Example of mapping of RSVPv1 objects in RSVPv2 ob
ject_classes .............................................. 34
5.2.2 PDR/PHR objects .......................................... 38
5.3 RSVPv2 ALSP functionality on nodes used for inter-domain
Westberg, et al. Expires April 2003 [Page 3]
Internet Draft Proposal for RSVPv2 October 2002
signaling ................................................. 39
5.4 RSVPv2 ALSP functionality on nodes used for intra-domain
signaling ................................................. 39
6 Example of RSVPv2 ALSP Inter-domain signaling procedures ..... 39
6.1 Normal operation for uni-directional reservation ........... 39
6.2 Normal operation for bi-directional reservation ............ 44
7 Example of RSVPv2 ALSP Intra-domain signaling procedures ..... 44
7.1 Normal operation for uni-directional reservation ........... 44
7.2 Example of Fault Handling Operation ........................ 58
7.2.1 Loss of CSTP signalling messages ......................... 59
7.2.2 Severe Congestion Handling operation ..................... 59
7.2.2.1 Proportional marking ................................... 60
7.3 Example of Adaptation to load sharing operation ............ 61
7.4 Normal operation for bi-directional reservation ............ 62
8 Appendix 1 - Proposed modifications on the CSTP protocol ..... 62
8.1 Modified CSTP messages ..................................... 63
8.2 ALSP/CSTP interface ........................................ 64
8.3 Adaptation to load sharing operation ....................... 64
9 Appendix 2 - Examples of PHR and PDR object specifications
........................................................... 64
9.1 PHR objects ................................................ 64
9.2 PDR objects ................................................ 67
10 References .................................................. 72
11 Authors' Addresses .......................................... 75
Westberg, et al. Expires April 2003 [Page 4]
Internet Draft Proposal for RSVPv2 October 2002
1. Introduction
A number of different QoS solutions have been developed by the IETF,
amongst them IntServ and its signalling protocol, RSVPv1, defined in
[RFC2205]. RSVPv1 [RFC2205] is a resource reservation signalling
protocol that was designed to be applied in an end-to-end
communication path. It can be used by an application to make its QoS
requirements known and reserve resources in all the network nodes in
the path.
RSVPv1 has not enjoyed the level of deployment that might have been
expected. This is due to issues such as scalability, design
constraints as it is optimized for multicast, etc. [RFC2475, RFC3175,
etc]. This memo seeks to initiate a dialog about the design of a new
version of RSVPv1, which we call RSVPv2. The goal of RSVPv2
framework would be to rectify the issues that have been identified
with RSVPv1 and provide an evolutionary path forward.
The RSVPv2 framework could use the combination of two concepts that
have been introduced in [BrLi01]. The concept of ALSP (Application-
Level Signaling Protocol) and the concept of Common Signaling
Transport Protocol (CSTP).
This memo outlines the motivation for doing this work and provides
design guidelines and specifications for the development of the
RSVPv2 ALSP. RSVPv2 ALSP is an ALSP type that can be a part of the
RSVPv2 framework. In order to be able to communicate with the CSTP,
the RSVPv2 ALSP needs to use an ALSP Identifier that has to be
assigned by the NSIS (Next Steps In Signaling) WG.
1.1. Definitions/Terminology
Application-Layer Siganling Protocol (ALSP) (similar to [BrLi01]):
is a protocol level that implements the algorithms and data
structures for a particular signaling task.
RSVPv2 ALSP:
an ALSP type that can be a part of the RSVPv2 framework.
ALSP intra-domain:
Westberg, et al. Expires April 2003 [Page 5]
Internet Draft Proposal for RSVPv2 October 2002
a domain that supports NSIS intra-domain signaling.
Classifier - an entity which selects packets based on the content of
packet headers according to defined rules.
Common Signaling Transport Protocol (CSTP) (similar to [BrLi01]):
is a protocol level that CSTP implements transport and soft-state
functions. CSTP supports a suite of higher-level ALSPs.
CSTP aware node:
a node that implements and supports the CSTP protocol.
CSTP stateful neighbor:
a first hop CSTP aware neighbor node (of a CSTP aware node) that
maintains a CSTP state.
CSTP stateful node:
a CSTP aware node that maintains a CSTP state.
CSTP stateless neighbor:
a first hop CSTP aware neighbor node (of a CSTP aware node) that
does not maintain a CSTP state.
CSTP stateless node:
a CSTP aware node that does not maintain a CSTP state.
DS behavior aggregate (identical to [RFC2475]):
A collection of packets with the same DS codepoint crossing
a link in a particular direction.
DS-compliant (identical to [RFC2475]):
Enabled to support differentiated services functions and
behaviors as defined in [RFC2474], this document, and other
Westberg, et al. Expires April 2003 [Page 6]
Internet Draft Proposal for RSVPv2 October 2002
differentiated services documents; usually used in reference
to a node or device.
Interdomain traffic - Traffic that passes from one NSIS domain to
another ([identical to [Hanc02]).
Intra-domain NSIS signaling is where the NSIS signaling messages are
originated, processed and terminated within the same NSIS domain.
NSIS Domain (ND) - Administrative domain where an NSIS protocol
signals for a resource or set of resources (identical to [Hanc02]).
NSIS Entity (NE) - the function within a node which implements an
NSIS protocol (identical to [Hanc02]).
NE CSTP stateful - NE entity that is CSTP stateful.
NE CSTP stateless - NE entity that is CSTP stateless.
NSIS Forwarder (NF) - NSIS Entity on the path between a NI and NR
which may interact with local resource management function (RMF)
The NSIS Forwarder also propagates NSIS signaling further through the
network (identical to [Hanc02]). Note that NF can be also
considered as a RSVPv2 forwarder.
NF CSTP stateful - NF entity that is CSTP stateful.
NF CSTP stateless - NF entity that is CSTP stateless.
NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a
network resource (identical to [Hanc02]). Note that NI can be also
considered as a RSVPv2 initiator.
NSIS Responder (NR) - NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well
(identical to [Hanc02]). Note that NR can be also considered as a
RSVPv2 responder.
Westberg, et al. Expires April 2003 [Page 7]
Internet Draft Proposal for RSVPv2 October 2002
Path-coupled signaling - a mode of signaling where the signaling
messages follow a path that is tied to the data messages.
(see [Hanc02]).
Path-decoupled signaling - signaling with independent data and
signaling paths (see [Hanc02]).
Per Hop Behavior (PHB) (identical to [RFC2475]):
The externally observable forwarding behavior applied at
a DS-compliant node to a DS behavior aggregate.
Per Hop Reservation (PHR):
The per-hop resource reservation in a Diffserv domain,
extending the Diffserv PHB, e.g., the bandwidth allocated to
an AF PHB (see RFC2597]), with resource reservation. It is
implemented at both the interior nodes and the edge nodes.
Per Hop Reservation (PHR) protocol:
A type of protocol that is used to perform a per hop
reservation. A PHR protocol part is used in all nodes in the
Diffserv domain (both edge and interior nodes) on a hop by
hop basis.
Per Domain Behavior (PDB)(similar to [NiKa01]):
Describes the behavior experienced by a particular set of
packets as they cross a DS domain. A PDB is characterized
by specific metrics that quantify the treatment that a set
of packets with a particular DSCP (or set of DSCPs) will
receive as it crosses a DS domain.
Per Domain Reservation (PDR):
The resource reservation functionality in the complete Diffserv domain.
Per Domain Reservation (PDR) protocol:
A type of signaling protocol used to perform a per domain
reservation signaling.
A PDR protocol part is used by NF(edge) nodes (NF(ingress)
and NF(egress)),
but not by the NF(interior) nodes.
Westberg, et al. Expires April 2003 [Page 8]
Internet Draft Proposal for RSVPv2 October 2002
Resource - something of value in a network infrastructure to which
rules or policy criteria are first applied before access is granted.
Examples of resources include the buffers in a router and bandwidth
on an interface (identical to [Hanc02]).
Resource Management Function (RMF) - an abstract concept,
representing the management of resources in a domain or a node
(identical to [Hanc02]).
NF Edge nodes:
NF Nodes that are located at the boundary of a Diffserv domain.
This node is a CSTP aware node that maintains a CSTP state.
NF Interior node:
All the nodes that are part of a domain and are
not NF edge nodes. An interior node is a CSTP aware node that
does not maintain a CSTP state.
NF Ingress node:
An NF edge node that handles the traffic as it enters the
domain. This node is a CSTP aware node that maintains
a CSTP state.
NF Egress node:
An NF edge node that handles the traffic as it leaves the
domain. This node is a CSTP aware node that maintains
a CSTP state.
End Host:
QoS-aware end terminal, either fixed or mobile, i.e. running
QoS-aware applications. This node is a CSTP aware node that maintains
a CSTP state. This node can be considered as a NI or a NR.
SAPU (similar to [BrLi01]):
A Signaling Application Protocol Unit (SAPU) is the basic
transmission unit for signaling and it is used to set,
modify, or delete state in a CSTP aware node that maintains
a CSTP state.
Westberg, et al. Expires April 2003 [Page 9]
Internet Draft Proposal for RSVPv2 October 2002
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
2. Motivation for RSVPv2
Embarking on the adventure of creating RSVPv2 is not to be done
lightly. A great deal of effort was put into the design of the
IntServ model and its signalling protocol, RSVPv1. As such, there
must be a clear need for the evolution of RSVPv1. This section tries
to provides that motivation.
We believe that this work can be motivated by examining some of the
design constraints placed upon the development of RSVPv1 and in
considering whether those design constraints can be relaxed or
changed in designing RSVPv2.
Note that RSVPv2 uses the concept of ALSP's that has been introduced
in [BrLi01]. The RSVPv2 ALSP must be used in combination with the
Common Signaling Transport Protocol (CSTP) specified in [BrLi01]. In
order to be able to communicate with the CSTP, the RSVPv2 ALSP needs
to use an ALSP Identifier that has to be assigned by the NSIS (Next
Steps In Signaling) WG.
2.1. Effects of the Design of RSVPv1
This section outlines some of the design considerations that went
into the design of RSVPv1, which in turn led to decisions that make
it difficult to use RSVPv1 beyond its originally-intended scope.
RSVPv1 is well-designed for the applications for which it was
intended and worked hard to provide a modular protocol within the
constraints of its intended use. We see value in questioning the
applications chosen, thereby improving the protocol.
Westberg, et al. Expires April 2003 [Page 10]
Internet Draft Proposal for RSVPv2 October 2002
2.1.1. Designed for Multicast Applications
One of the most important design requirement for RSVPv1 was support
for multicast applications. RFC 1633 [RFC1633] states, "There are a
number of requirements to be met by the design of a reservation
setuop protocol. It should be fundamentally designed for a multicast
environment...."
Multicast support introduces a level of complexity into the protocol
that is not needed in support of unicast applications. For example,
RSVPv1's state maintenance is complex as it needs to support dynamic
membership changes in the multicast groups, such as reservation state
merging and maintenance.
Our working assumption is that RSVPv2 should be optimized for unicast
rather than multicast and that relaxing this design constraint will
in turn greatly simplify the protocol.
2.1.2. Least Common Denominator Not Small Enough
Rightfully so, RSVPv1 put a great deal of effort into creating a
modular protocol with the ability to use those pieces that apply in a
particular setting. However, this modularity was created with the
backdrop of multicast applications. This means that, while modular
to some degree, even the "least common denominator" of objects that
must be carried is too heavy in some networking contexts. That is,
while flexible, RSVPv1 does not allow for more lightweight
implementations if fewer features are needed in certain parts of the
network.
The fact that the least common denominator is too heavy means that:
* Some objects are always carried in RSVPv1 messages that are
not applicable in some settings.
* There is an expectation of the same level of protocol
functionality throughout the network(s). Clearly, different
parts of the network need different levels of functionality,
a differentiation not supported by RSVPv1.
On May 20, 2002, Bob Braden, one of the creators of RSVPv1, wrote the
following on the NSIS working group's mailing list [NSIS-ML1]:
"...RSVP may have had the modularity wrong.... RSVP design and
Westberg, et al. Expires April 2003 [Page 11]
Internet Draft Proposal for RSVPv2 October 2002
specification may ahve talked too much about int-serv specific
things like Tspecs. We should instead have defined RSVP strictly
in terms of transporting opaque QoS objects upstream and
downstream...."
Our working assumption is that RSVPv2 can be created with even more
modularity to enable its use in most (if not all) networking
contexts. In particular, we believe that RSVPv2 can be made more
suitable for use in the different parts of the network where
requirements on the signalling protocol differ greatly.
2.1.3. Sender-initiated versus Receiver-initiated Signalling
RSVPv1 is receiver-oriented, which is to say that the receiver of a
data flow initiates and maintains the resource reservation used for
that flow. This choice was made despite the fact that sender-
initiated reservations are "perhaps the most obvious choice" since
sender-initiated reservations "scale poorly for large, dynamic
multicast delivery trees and for heterogeneous receivers" (Section
5.1.3, RFC 1633 [RFC1633]). These two problems were solved by using
receiver-initiated reservations.
Our working assumption is that relaxation of the requirement for
multicast support will also allow for sender-initiated reservations
without introducing scalability problems.
2.1.4. Designed for End-host to End-host Communication
RSVPv1 was primarily designed with signalling between end-host
systems in mind. This communication implies a certain set of
requirements on the entities involved and on the kinds of information
that they need to signal.
In recent work (particularly in NSIS), it has become clear that there
are in fact several different kinds of signalling conversations that
may be needed in different parts of the network. Each of these kinds
of signalling implies a different -- and potentially conflicting --
set of requirements on the signalling protocol. For example, the
signalling requirements for the conversation between the end-host and
the network may indeed need more complexity than RSVPv1 whereas the
signalling needs in a DiffServ-capable access network would require
significantly less.
Westberg, et al. Expires April 2003 [Page 12]
Internet Draft Proposal for RSVPv2 October 2002
Our working assumption is that RSVPv2 must be designed to allow an
appropriate set of objects to be defined for the various "interfaces"
(e.g., host-to-network, edge-to-edge, end-to-end) used in various
parts of the network while not including any mandatory objects that
are not applicable in all parts of the network.
2.2. Different Network Signalling Requirements/Needs and RSVP
As previously mentioned, RSVPv1 put a great deal of effort into
creating a modular protocol with the ability to use those pieces that
apply in a particular setting. However, while flexible, RSVPv1 does
not allow for more lightweight implementations if fewer features are
needed in certain network scenarios.
This section provides a (non-exhaustive) list of scenarios where
there seems to be a need for new tools, either because the need for
optimization is sufficiently strong or the scenario was not
considered in the design of RSVPv1.
* Networks with semi-permanent trunk aggregation: In such
networks the transmission links are not expensive and
semi-permanent trunk aggregation can be applied.
* Networks with trusted end hosts: In these networks the
security requirements are less important. Such networks are
the networks used between PSTN (Public Switched Telephone
Networks) gateways and backbone routers [PAN-SSP].
* Networks with untrusted mobile end hosts: In these networks
the security requirements between the first hop access router
and the untrusted mobile end host are very significant. Such
networks are the networks that use wireless LAN (WLAN)
access [RFC2002].
* Networks that have to support fast and frequent mobility
procedures (e.g., handover), where the transmission links
are expensive, and the majority of the traffic is unicast.
Cellular radio access networks are examples of such networks.
[RAN-ISSUE].
Westberg, et al. Expires April 2003 [Page 13]
Internet Draft Proposal for RSVPv2 October 2002
3. Design Goals and General Features for RSVPv2-ALSP
This section briefly outlines some of the guiding principles behind
the design of RSVPv2 ALSP. Moreover, the RSVPv2 ALSP general features
are described. These design goals and features are in line with some
of the NSIS requirements described in [Bru02] and [Hanc02].
3.1. Increased Modularity and Extendability
The essential design goal for RSVPv2 framework is to preserve the
flexibility of RSVPv1 while at the same time further expanding its
modularity. This is fulfilled by using the two-level architecture for
Internet Signaling proposed in [BrLi01]. In [BrLi01] is proposed
that the Internet Signaling should be composed by two protocol
levels:
(1) a common lower level that performs transport-layer functions.
This common lower level is called CSTP ("Common Signaling
Transport Protocol") to implement transport ans soft-state
functions.
(2) a set of upper-level signaling functions that are specific
to particular signaling applications. These upper-level
signaling tasks and functions are accomplished by a set of ALSPs
("Application Layer Signaling Protocols).
The CSTP together with the set of ALSPs will implement the Internet
Signaling Protocol Suite (ISPS).
The RSVPv2 ALSP protocol can be considered as an ALSP that will use
a subset of the transport layer functions provided by the CSTP (see
[BrLi01]) such as:
* Support of Path-Coupled (Path-Directed) Signaling;
* Reliable delivery of signaling messages: By using this feature
the CSTP signaling messages can be delivered reliably when needed
such that the sate can be reliably added, changed and explicitly
removed.
* Soft state support: This feature ensures that a state will be removed
if it is not periodically refreshed or explicitly removed.
* Modification of an already installed reservation state.
Westberg, et al. Expires April 2003 [Page 14]
Internet Draft Proposal for RSVPv2 October 2002
* Adaptation to load sharing. Load sharing allows NF interior
nodes to take advantage of multiple routes to the same
destination by sending via some or all of these available
routes. The CSTP protocol level has to adapt to load sharing once
it is used.
* The CSTP signaling protocol MUST be able to exchange local information
NSIS Forwarders located within one single administrative
domain. Local information might, for example, be IP addresses,
severe congestion notification, notification of successful or
erroneous processing of signaling messages.
3.2. Increased Object Modularity
The purpose of this object modularity is to increase processing
efficiency of RSVPv2 (ALSP and CSTP) messages by only including those
objects relevant in a particular part of the network.
RSVPv1 uses flexible object definitions that are opaque to RSVPv1 for
transporting and maintaining traffic and policy control parameters.
This type of object definition has certain advantages in terms of
flexibility, but one of its main disadvantages is that each RSVPv1
message may contain up to fourteen classes of attribute objects. Even
if some of the RSVPv1 objects are not needed in a scenario they will
have to be included in RSVPv1 messages and considered as mandatory
objects.
In order to achieve modularity, the RSVPv2 ALSP object structure will
need to have less (possibly no) "mandatory" functionality and allow a
more open object structure.
This open object structure can be solved by enhancing the RSVPv1
object structure and by introducing a concept of "profiles". A
profile is a specification of which RSVPv1 objects are needed for a
certain network scenario (see Section 2.2 above). In this way, the
RSVPv1 messages will only carry the RSVPv1 objects that are required
and specified by each profile. The profile concept makes use of
profile identifiers to separate different profiles used in RSVP aware
nodes.
Westberg, et al. Expires April 2003 [Page 15]
Internet Draft Proposal for RSVPv2 October 2002
3.3. Hierarchical Object Structure
RSVPv1, even in its simplest form, still uses objects and features
that are not needed in all routers (nodes) used in a network
scenario. For example, in a network scenario with WLAN access, the
QoS signaling protocol used between the access router and the
untrusted mobile end host requires strong security procedures.
However, the QoS signaling protocol used in the same network scenario
between the same access router and another router will not require
the same security procedures. Another example is a network with
semi-permanent trunk aggregation, where the edges of such a network
have to provide aggregator/deaggregator features, e.g., maintenance
of both per micro-flow and per aggregated flow reservation states,
while the interior nodes require only simpler functionality, e.g.,
maintenance of per aggregated flow reservation states.
The RSVPv2 framework will endeavor to improve this by providing a
hierarchical structure and positioning of the RSVPv2 ALSP objects
within RSVPv2 (ALSP and CSTP) messages for each networking scenario.
Each profile used for a network scenario will have to specify how the
objects are structured into the RSVPv2 ALSP SAPU (Signaling
Application Protocol Unit)and how they should be processed by a
router. The objects that will be processed by all routers used in a
network scenario will be placed as the first ones in the object
sequence. Objects that will be processed only in specific routers
can be placed later in the sequence.
3.4. Global and Local Objects
ALSP RSVPv2's object space will consist of globally-understood
objects ("global objects") and locally-understood objects ("local
objects"). The purpose of this division is to provide additional
flexibility in defining the objects carried by the RSVPv2 protocol
such that only those objects that are applicable in a particular
setting are used.
The appropriate fora for defining these objects and how to manage the
object space is obviously still a very open question. By using this
feature the requirement described in Section 5.4.2 (Possibility to
add and remove local domain information) of [Bru02] will be
satisfied.
Westberg, et al. Expires April 2003 [Page 16]
Internet Draft Proposal for RSVPv2 October 2002
3.5. Local information exchange
The signaling protocol MUST be able to exchange local information
between NSIS Forwarders located within one single administrative
domain (see also Section 5.3.5 (Local information exchange) in
[Bru02]). Local information might, for example, be IP addresses,
severe congestion notification, notification of successful or
erroneous processing of signaling messages.
In some cases, the NSIS signaling protocol MAY carry identification
of the NSIS Forwarders located at the boundaries of a domain.
However, the identification of edge should not be visible to the end
host (NSIS Initiator) and only applies within one administrative
domain.
3.6. Object Re-use
Obviously, whenever it is appropriate, RSVPv2 will re-use objects
that are defined for RSVPv1.
3.7. Reduced Focus on Multicast
Given the complexity that multicast support introduces to QoS
signalling and the fact that the vast majority of the traffic in
typical IP networks is point-to-point unicast transport, RSVPv2 will
be optimized to operate as a sender-initiated protocol for unicast
data flows.
This should not be interpreted to mean that multicast support is not
important and should not be supported. Given the increased
modularity of RSVPv2 framework, it is entirely possible that
appropriate objects will be defined in support of multicast.
3.8. Primarily Sender-initiated Signalling
Given a reduced focus on multicast, the "obvious" choice of sender-
initiated signalling seems to be applicable to the ALSP RSVPv2. The
receiver-initiated reservations will undoubtedly still be needed in
some network scenarios, so the RSVPv2 framework will need to handle
such reservations as well. However, this feature will be optional.
Westberg, et al. Expires April 2003 [Page 17]
Internet Draft Proposal for RSVPv2 October 2002
3.9. Low latency in setup
The RSVPv2 framework SHOULD allow for low latency setup of
reservations in scenarios, where reservations are in a short time
scale (e.g. handover in mobile environments), or where human
interaction is immediately concerned (e.g., voice communication setup
delay) (see also Section 5.5.2 (Low latency in setup) of [Bru02]).
3.10. Highest possible network utilization
There are networking environments that require high network
utilization for various reasons, and the signaling protocol SHOULD to
its best ability support high resource utilization while maintaining
appropriate QoS.
In networks where resources are very expensive (as is the case for
many wireless networks), efficient network utilization is of critical
financial importance. On the other hand there are other parts of the
network where high utilization is not required (see also Section
5.5.5 (Highest possible network utilization) of [Bru02].
3.11. Uni / bi-directional reservation
Both unidirectional as well as bi-direction reservations SHOULD be
possible (see also Section 5.6.4 of [Bru02]). With bi-directional
reservations we mean here reservations having the same end-points.
But the path in the two directions does not need to be the same. The
goal of a bi-directional reservation is mainly an optimization in
terms of setup delay. There is no requirements on constrains such as
use the same data path etc.
3.12. End-to-end
When used end-to-end (see also [Hanc02]), the RSVPv2 ALSP protocol is
initiated by an end host and is terminated by another end host. In
this context, RSVPv2 ALSP can be applied as needed within all of the
RSVPv2 ALSP domains between the end hosts. In the end-to-end path,
RSVPv2 ALSP may be used both for intra-domain RSVPv2 ALSP signaling,
as well as for inter-domain signaling.
Westberg, et al. Expires April 2003 [Page 18]
Internet Draft Proposal for RSVPv2 October 2002
3.13. Edge-to-edge
In this scenario (see also [Hanc02]) the RSVPv2 ALSP protocol is
initiated by an edge node of a RSVPv2 ALSP domain and is terminated
by another edge node of the same (or possibly different) RSVPv2 NSIS
domain. RSVPv2 ALSP can be applied either within one single RSVPv2
ALSP domain, which is denoted as edge-to-edge in a single domain, or
within a concatenated number of RSVPv2 ALSP domains, which is denoted
as edge-to-edge in a multi-domain. When an appropriate security trust
relation exists between two or more concatenated RSVPv2 ALSP domains,
these concatenated RSVPv2 ALSP domains are considered, in terms of
RSVPv2 ALSP, to be a single, larger RSVPv2 ALSP domain.
3.14. End-to-edge
In this scenario (see also [Hanc02]) the RSVPv2 ALSP protocol is
either initiated by an end host and is terminated by an edge node or
is initiated by an edge node and is terminated by an end host. In the
path-coupled case, the edge node may be a proxy that is located on a
boundary node of a RSVPv2 ALSP domain.
4. Overview of the RSVPv2-ALSP Framework
The RSVPv2 protocol can be considered as an ALSP that will use a
subset of the transport layer functions provided by the CSTP protocol
level (see [BrLi01]). The RSVPv2 protocol can be used for End-to-
End, Edge-to-Edge, and End-to-Edge scenarios. In the End-to-End
scenario the both NSIS end nodes are functioning as NSIS Initiators
(NI) and NSIS Responders (NR). In the Edge-to-Edge scenario, both
NSIS edge nodes are functioning as NI, NR and NSIS Forwarders (NF).
In the End-to-Edge scenario the NSIS end host is functioning as a NI
or NR and the edge node is functioning as a NI, NR and NF.
The RSVPv2 ALSP framework shown in Figure 1 is separated in different
levels. The lowest hierarchical level in Figure 1 represents the CSTP
level protocol. This level provides basic resource management
functionality related to soft state maintenance and to transport
functions, such as reliable delivery of signaling messages,
congestion control notification and load sharing adaptation. Note
that the NF nodes are usually considered to be CSTP stateful nodes.
This holds also for the NF nodes used at the boundary of a domain,
i.e., the NF edge nodes. However, the interior nodes of a domain can
be considered to be CSTP stateless nodes, i.e., NF stateless nodes.
Westberg, et al. Expires April 2003 [Page 19]
Internet Draft Proposal for RSVPv2 October 2002
The NF CSTP stateful nodes are NF CSTP aware nodes that maintain a
CSTP state by using the CSTP soft state principle and are able to
process and modify the CSTP information that is transported by the
CSTP protocol. The NF CSTP stateless nodes are NF CSTP aware nodes
that do not maintain a CSTP state, but they are able to process and
modify the CSTP information that is transported by the CSTP protocol.
The RSVPv2 ALSP framework is separated in two levels:
* the intra-domain level (located above the CSTP level), that is
composed by two protocol parts the Per Domain Reservation (PDR)
protocol part and the Per Hop Reservation (PHR) level. Note that these
two protocol parts are simialr to the two protocols (PDR and PHR) that
are described in the Resource management in Diffserv (RMD)
scheme [RMD-frame].
In order to maximize the scalability in the RSVPv2 intra-domain
the complexity imposed by the combination of the RSVPv2 ALSP and CSTP
has to be moved as much as possible away from the interior nodes.
Therefore, the RSVPv2 ALSP separates the problem of a
complex reservation within a domain from a simple reservation
within a node. This is accomplished by specifying two types
of resource reservation protocol parts into the RSVPv2 ALSP
intra-doamin.
The first resource reservation protocol part type is denoted as Per
Hop Reservation (PHR) that enables the signaling of the resources
to be reserved per traffic class (e.g., Diffserv Per Hop Behavior
(PHB) class) in each node within a domain. This protocol type is
optimized to reduce the requirements placed on the functionality
of the NF interior nodes of the domain. For example, the nodes
that implement this protocol type do not have per flow
responsibilities. This protocol can be either reservation-based or
measurement-based. In the reservation-based PHR, each node keeps
only one reservation state per each supported traffic class. In the
measurement-based PHR no reservation states are installed and the
resource availability is checked by measuring traffic (user) data
load. In the NF interior nodes there is no CSTP state
and there is no PDR functionality. Note that these NF interior
nodes are CSTP stateless nodes.
The second protocol type is denoted as Per Domain Reservation
(PDR) and is responsible for the resource reservation signaling
on the NF edge nodes. The PDR is used by NF edge nodes
(ingress and egress) but not by the interior nodes. This
protocol introduces strict and complex requirements on the
Westberg, et al. Expires April 2003 [Page 20]
Internet Draft Proposal for RSVPv2 October 2002
functionality implemented on the edge nodes. An example of such
functionality is the mapping of the "global" traffic parameters
signalled by the e2e service level (see Figure 1) to "local"
parameters that are useful to the intra-domain scheme.
Note that in the NF edge nodes (NF ingress and NF egress) a
CSTP state is maintained and both PDR and PHR functionalities
are active.
* the e2e service level is located above the PDR/PHR level and
includes a set of upper-level signaling functions that are specific
to particular signaling applications. Such functions could, for
example, be end to end resource reservation signaling, security,
policy, billing, etc.
The interface between the RSVPv2 ALSP and CSTP complies to the
interface specified in [BrLi01]. However, a number of modifications
on the CSTP protocol level are proposed in Appendix 1. Note that
Appendix 1 describes a possible manner of enhancing the CSTP protocol
level described in [BrLi01] such that it can be used in combination
with the RSVPv2 ALSP. However, these proposed CSTP modifications
should be seen as an example and should not preclude other ways of
achieving the interaction between the CSTP protocol level and the
RSVPv2 ALSP level.
An RSVPv2 ALSP SAPU (Signaling Application Protocol Unit)) caries the
objects used by the e2e service and PDR/PHR ALSP protocol levels.
The RSVPv2 ALSP SAPU similar to the proposal given in [BrLi01]
contains a (<key>, <value>) pair. The <key> part contains the SAPU-
id. The <value> part is a container that contains the "e2e service"
objects that are "global" objects and the "PDR/PHR" objects that are
"local" objects.
Note however, that there are certain differences in the CSTP level
functionalities that are required by this ALSP with the CSTP level
functionalities described in [BrLi01]. The proposed main differences
of the CSTP level that has to be used in combination with the RMD
ALSP and the CSTP level described in [BrLi01] are the following:
(Note that Appendix 1 describes a possible manner of enhancing the
CSTP protocol level described in [BrLi01] such that it can be used in
combination with the RSVPv2 ALSP. However, these proposed CSTP
modifications should be seen as an example and should not preclude
other ways of achieving the interaction between the CSTP protocol
level and the RSVPv2 ALSP level)
Westberg, et al. Expires April 2003 [Page 21]
Internet Draft Proposal for RSVPv2 October 2002
* in the CSTP level described in [BrLi01] the CSTP states have to be
created by all CSTP aware nodes.
* in the CSTP level used in the RSVPv2 ALSP the CSTP states do not have
to be created in all CSTP aware nodes. There are nodes, such as the
NF interior nodes, that are not creating and maintaining such CSTP
states. These NF nodes are called NF CSTP stateless nodes. The NF
nodes that are creating and maintaining such CSTP states are called
NF CSTP stateful nodes. The consequence of this difference is that
the information that has to be carried by some CSTP messages and
the ALSP/CSTP interface has to be modified.
* Adaptation to load sharing. Load sharing allows NF interior
nodes to take advantage of multiple routes to the same
destination by sending via some or all of these available
routes. The CSTP protocol level has to adapt to load sharing once
it is used.
As shown in Figure 1, the two ALSP hierarchical levels might be
applied on different NSIS entities.
This architecture for NSIS (e.g., RSVPv2) signaling can be provided
by using:
*) a single end-to-end NSIS (e.g., RSVPv2) protocol that supports both
ALSP hierarchical levels
*) two independent NSIS (e.g., RSVPv2) protocols: the e2e service
level is supported by an end-to-end NSIS protocol, and the PDR/PHR
level is supported by another edge-to-edge NSIS (e.g., RSVPv2)
protocol.
Westberg, et al. Expires April 2003 [Page 22]
Internet Draft Proposal for RSVPv2 October 2002
|------| |-------| |-------| |------|
| e2e |<--| e2e |<------------------------->| e2e |<->| e2e |
service|<--|service| |service|<->|service
| | |-------| |-------| |------|
| | | | | | | |
| | |-------| |-------| |-------| |-------| | |
| | |PDR/PHR|<->| PHR |<->| PHR |<->|PDR/PHR| | |ALSP
| | | | | | | | | | | | ^
| | |-------| |-------| |-------| |-------| | | |
---------------------------------------------------------------------
| | | | | | | | |
|------| |-------| |-------| |-------| |-------| |------| V
| level|<->| level |<->| level |<->| level |<->| level |<->|level |CSTP
| CSTP |<->| CSTP |<->| CSTP |<->| CSTP |<->| CSTP |<->|CSTP |
|st.ful| |st.ful | |st.less| |st.less| |st.full| |st.ful|
|------| |-------| |-------| |-------| |-------| |------|
NI NF NF NF NF NR
(edge) (interior) (interior) (edge)
CSTP st.ful : CSTP stateful
CSTP st.less : CSTP stateless
Figure 1: Combination of RSVPv2 ALSP framework and CSTP level
The hierarchical level separation can be provided by supporting a
hierarchical object structure. In other words, the NSIS protocol
objects should be structured and positioned within the NSIS messages
in a hierarchical way, i.e., first the "CSTP level" objects, then the
"PDR/PHR" objects and finally the "e2e service" objects.
4.1. RSVPv2 protocol features provided by the intra-domain level
The RSVPv2 protocol functions provided by the intra-domain level are
composed by the protocol functions provided by the PDR and PHR
protocol parts (similar to [RMD-frame], [RODA], [RIMA]).
4.1.1. PDR protocol part functions
The RSVPv2 ALSP PHR and PDR protocol parts that implement the RSVPv2
ALSP intra-domain level are listed below.
A PDR protocol part implements all or a subset of the following
functions:
Westberg, et al. Expires April 2003 [Page 23]
Internet Draft Proposal for RSVPv2 October 2002
* Admission control and/or resource reservation signaling within
a domain (i.e., on the edge nodes).
* Stores the PDR flow identifier and PDR reservation state
per flow (or aggregated flows).
* Mapping of external QoS request provided by the e2e service level
to a traffic class identifier, e.g., Diffserv Code Point
(DSCP).
* Modification of an already installed reservation state.
* Notification of the NF ingress node IP address to the NF egress
node.
* Notification of resource availability in all the nodes
located in the communication path from the NF ingress to the
NF egress nodes.
* Severe congestion handling. Due to a route change or a
link failure, a severe congestion situation may occur.
The NF egress node is notified by PHR when such a severe
congestion situation occurs. Using PDR, the egress node
notifies the NF ingress node about this severe congestion
situation. The NF ingress node resolves this situation by using
a predefined policy, e.g., refusing new incoming flows and
terminating a portion of the affected flows.
* Uni / bi-directional reservation. Both unidirectional as well
as bi-direction reservations SHOULD be possible
4.1.2. PHR protocol part functions
A RSVPv2 ALSP PHR protocol part implements all or a subset of the
following functions:
* Admission control and/or resource reservation signaling within a
node.
* Management of one reservation state (i.e., PHR state) per traffic
class by using a combination of the reservation soft state and
explicit release signaling principles (see e.g., [RODA]). Note that
the PHR state is maintained by using the CSTP soft state principle.
Westberg, et al. Expires April 2003 [Page 24]
Internet Draft Proposal for RSVPv2 October 2002
Each NF node in the communication path from an NF ingress node to an
NF egress node keeps only one reservation state per traffic class.
The reservation signaling is done in terms of resource units,
which may be based on a single parameter, such as bandwidth,
or on more sophisticated parameters. These resources are
requested dynamically per traffic class (e.g., per DSCP) and
reserved on demand on all nodes in the communication path from an
NF ingress node to an NF egress node. This concept is denoted as
reservation based "PHR".
* Measurement of the user traffic load (see e.g., [RIMA]). This
PHR function is used to check the availability of resources before
flows are admitted and without installing any reservation state.
That is, the resource management function that is used is actually
a Measurement Based Admission Control (MBAC) algorithm, which
performs measurements on the traffic (user) data load. The main
advantage of this PHR group is that the PHR functionality
that is executed at the edge and interior nodes will not
have to maintain any reservation states. This concept is denoted
as measurement based "PHR".
* Stores a pre-configured threshold value on maximal allowable
traffic load (or resource units) per traffic class, e.g., PHB.
When the resource management function (RMF) that is used
in combination with this PHR protocol function maintains a
reservation state per traffic class it also has to maintain a
threshold for each trafic class (e.g., PHB) that specifies the
maximum number of reservable resource units. This threshold could,
for example, be statically configured.
When the resource management function (RMF) that is used
in combination with this PHR protocol function is an MBAC algorithm
it also has to maintain one state per traffic class that stores the
measured user traffic load associated to the traffic class, e.g., PHB
and another state per traffic class, e.g., PHB that stores the
maximum allowable traffic load per traffic class, e.g., PHB.
* Severe congestion notification. This situation occurs as
a result of route changes or a link failure. The PHR
has to notify the NF edges about the occurrence of this
situation.
Westberg, et al. Expires April 2003 [Page 25]
Internet Draft Proposal for RSVPv2 October 2002
Once detected the severe congestion should be signalled to the
NF(edges).
As previously mentioned, the NF(egress) node will first be notified,
after which the NF(egress) will notify the NF(ingress) node using the
ALSP PDR functionality.
Below is a list of several notification methods that can be used:
* Greedy marking: all user data packets which pass through
a severe congested interior node and are associated with a
certain traffic class, e.g., DSCP, will be remarked into a
another traffic class, e.g., a domain specific (DSCP)
* Proportional marking: this method is similar to the previous
method, with the difference that the number of the remarked
packets is proportional to the detected overload
* PHR message marking: only PHR objects that
pass through a severely congested interior node will be
marked. The marking is done by setting a special flag in
the "PHR" object, i.e., "S" (see [RODA]).
The last method can only be applied on the reservation-based "PHR"
concept, while the other two can be applied on both "PHR" concept
types. A comparison between different severe congestion solutions is
given in [CsTa02].
4.2. CSTP protocol functions needed by the RSVPv2 ALSP
The main CSTP protocol level should provide all or a subset of the
following functions:
* Soft state support of the PHR state. This functionality is provided
by the CSTP soft state support functionality.
* Notification that lost signalling messages (containing PHR and PDR
information) occurred in the communication path from the ingress
to the egress nodes. This functionality is provided by the CSTP
reliable delivery functionality.
In the RMD ALSP the PHR and PDR protocol parts have to be generated
and discarded at the edge nodes (ingress and egress nodes) and not at
the end hosts.
Westberg, et al. Expires April 2003 [Page 26]
Internet Draft Proposal for RSVPv2 October 2002
4.3. RSVPv2 ALSP protocol features provided by the e2e service level
The e2e service level protocol features that are used by this ALSP
should satisfy all or a subset of the application signaling
requirements provided in [Bru02]. The detailed description of these
features will be included in the next updated versions of this draft.
Westberg, et al. Expires April 2003 [Page 27]
Internet Draft Proposal for RSVPv2 October 2002
5. RSVPv2 ALSP specification
RSVPv2 is considered in this draft to be primarily optimised for
unicast and sender initiated signaling. This section provides a first
step in the RSVPv2 ALSP specification.
5.1. RSVPv2 ALSP Object Classes structure
In order to have a flexible and modular RSVPv2 ALSP object class
structure, we propose a grouping of signalling information into
RSVPv2 ALSP object classes, called RSVPv2 ALSP Object_Classes. These
will contain objects that are defined globally and/or locally. A
locally defined object will allow signalling of information relevant
to nodes belonging to a certain domain, while the globally defined
objects will be used anywhere on the Internet. The globally defined
objects are denoted as "e2e service objects" and the locally defined
objects are denoted as ""PDR/PHR" objects.
In the RSVPv2 ALSP structure the following RSVPv2 ALSP Object_Classes
are defined:
* Service_Class
This object class carries the information related to the
service desired from the network, i.e. QoS. This class
includes all information related to the requested/expected
network service. The resource reservation is related
to the QoS request as well as to the response on this
QoS request. This object class is flexible in order to
support different kinds of QoS requests for different kinds
of networking scenarios such as a end-to-edge (proxy) scenario,
bi-directional reservations, receiver-initiated, etc.
* Reservation_State_Management_Class
This object class includes information related to the
management of reservation states. This object will contain
a reservation state identifier and information such as
refresh period information, flags for receiver or
sender-initiated reservation, etc.
The reservation state identifier has to identify a data flow
and has to remain unchanged for the complete duration of a
Westberg, et al. Expires April 2003 [Page 28]
Internet Draft Proposal for RSVPv2 October 2002
data flow. Moreover, the reservation state identifier has to
be associated with the flow ID information included in the
Flow_Specification_Class object. In other words, for the
duration of a data flow, the reservation state identifier
remains the same while the flow ID information associated
with the same data flow might change. For example, in a
mobile IP scenario, during handover the IP address of a
mobile node might change, causing a change in the flow ID
of an ongoing data flow. However, the reservation state
identifier associated with that data flow should not change.
* Flow_Specification_Class
This object class specifies the relation of the addressing
(IP address/mask/port) to the reservation and if/how the
reservation is shared between many addresses. In general,
Flow_Specification contains information that identifies
a particular data flow for which the specific service
is requested from the network. For example, a flow
ID consisting of a combination of source IP address,
destination IP address, Source port, Destination port,
Protocol number will be typical information belonging to
the Flow_Specification_Class.
* Security_class
This object class includes information related to the
protection, authorization and authentication of the
information in the message. This object class is optional.
* Error_message_class
This class includes information related to the errors that
occur during reservation state processing.
5.1.1. Combined CSTP and RSVPv2 ALSP Message Structure
A possible message structure in RSVPv2 is using a combined CSTP and
ALSP information. The exact object structure and the object sequence
will have to be defined for each network scenario by a pre-defined
"profile" (see Section 3.2). A profile can be either standardized or
it could be an agreement between two or more participants.
Westberg, et al. Expires April 2003 [Page 29]
Internet Draft Proposal for RSVPv2 October 2002
There are two types of RSVPv2 (ALSP and CSTP) message structures:
* RSVPv2 (ALSP and CSTP) messages that are used for inter-domain
signaling
* RSVPv2 (ALSP and CSTP) messages that are used for intra-domain
signaling
5.1.1.1. Message Structure for inter-domain signaling
The structure of the RSVPv2 (ALSP and CSTP) messages that are used
for inter-domain signaling is based on the one proposed in [BrLi01].
Note that this structure contains also the CSTP Info message, which
transports a SAPU type with neither reliable delivery nor refreshing.
Moreover, note that the SAPU type that is transported within a CSTP
NEW or CSTP MOD message is transported without reliable delivery.
CSTP NEW: xSig(NEW, h-src, SAPUid, SAPU, R)
CSTP MOD: xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R)
CSTP TEAR: xSig(TEAR, h-src, SAPUid)
CSTP REFRESH: xSig(REFRESH, h-src, SAPUid, R)
CSTP ACK: xSig(ACK, h-src, SAPUid-list)
CSTP NACK: xSig(NACK, h-src, SAPUid)
CSTP EVENT: xSig(EVENT, h-src, SAPUid, SAPU)
CSTP CHALLENGE: xSig(CHALLENGE, h-src, challenge-object)
CSTP RESPONSE: xSig(RESPONSE, h-src, challenge-object)
CSTP INFO: xSig(INFO, h-src, SAPUid, SAPU, SAPUinfo)
Where the parameters are identical to the ones described in [BrLi01].
The only additional parameter is the SAPUinfo parameter. SAPUinfo
that will be used to report information related to how the a SAPU has
been processed along the path. Note that the SAPUinfo is associated
to a SAPUid and a SAPU, which includes reporting information related
to the SAPU that is identified by the SAPUid.
Westberg, et al. Expires April 2003 [Page 30]
Internet Draft Proposal for RSVPv2 October 2002
5.1.1.2. Message Structure for intra-domain signaling
The structure of the RSVPv2 (ALSP and CSTP) messages that are used
for intra-domain signaling is similar on the one proposed in
[BrLi01]. Note that this structure contains also the CSTP INFO
message, which transports a SAPU type with neither reliable nor
refreshing delivery. Moreover, note that the SAPU type that is
transported within a CSTP NEW or CSTP MOD message is transported
without reliable delivery.
CSTP NEW: xSig(NEW, h-src, SAPUid, SAPU, R, LocalSAPU)
CSTP MOD: xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R,
LocalSAPU)
CSTP TEAR: xSig(TEAR, h-src, SAPUid, LocalSAPU)
CSTP REFRESH: xSig(REFRESH, h-src, SAPUid, R, LocalSAPU)
CSTP ACK: xSig(ACK, h-src, SAPUid-list)
CSTP NACK: xSig(NACK, h-src, SAPUid)
CSTP EVENT: xSig(EVENT, h-src, SAPUid, SAPU)
CSTP CHALLENGE: xSig(CHALLENGE, h-src, challenge-object)
CSTP RESPONSE: xSig(RESPONSE, h-src, challenge-object)
CSTP INFO: xSig(INFO, h-src, SAPUid, SAPU, SAPUinfo)
Where the parameters are identical to the ones described in [BrLi01].
The only additional parameters are the SAPUinfo and LocalSAPU
parameters. The SAPUinfo parameter is used to report information
related to how the a SAPU has been processed along the path. Note
that the SAPUinfo is associated to a SAPUid and a SAPU, which
includes reporting information related to the SAPU that is identified
by the SAPUid.
The LocalSAPU information includes locally defined objects that are
only used in a domain.
Westberg, et al. Expires April 2003 [Page 31]
Internet Draft Proposal for RSVPv2 October 2002
5.1.1.3. Format of RSVPv2 ALSP SAPUs
Based on the above defined RSVPv2 object-class structure the format
of the RSVPv2 ALSP SAPUs may be as follows:
<Path SAPU and LocalSAPU> ::= <Common Header>
<Service_Class>
<Reservation_State_Management_Class>
<Flow_Specification_Class>
[<Security_class>]
Path SAPU contains globally defined objects and Path LocalSAPU
contain locally defined objects
<Resv SAPU and LocalSAPU> ::= <Common Header>
<Service_Class>
<Reservation_State_Management_Class>
<Flow_Specification_Class>
[<Security_class>]
Resv SAPU contains globally defined objects and Resv LocalSAPU
contain locally defined objects
<ACK SAPUinfo> ::= <Common Header>
<Service_Class>
[<Security_class>]
The ACK SAPUinfo is used to report to ALSP that an ALSP has
been succesfully processed. It can contain globally and/or
locally defined objects.
<NACK SAPUinfo> ::= <Common Header>
<Service_Class>
[<Security_class>]
The NACK SAPUinfo is used to report to ALSP that an ALSP has
not been processed successfully. It can contain globally and/or
locally defined objects.
<PathError SAPU> ::= <Common Header>
<Service_Class>
<Reservation_State_Management_Class>
<Flow_Specification_Class>
Westberg, et al. Expires April 2003 [Page 32]
Internet Draft Proposal for RSVPv2 October 2002
[<Security_class>]
<Error_message_class>
<Resv_Error SAPU> ::= <Common Header>
<Service_Class>
<Reservation_State_Management_Class>
<Flow_Specification_Class>
[<Security_class>]
<Error_message_class>
The above listed SAPU types of the RSVPv2 ALSP protocol will be
mapped and transported by the following CSTP messages (see [BrLi01]):
Meaning of SAPUs SAPU Type CSTP Message Type
__________________________ _____________ _________________
Initiation Path NEW
Initiation Resv NEW
Modification Path MOD
Modification Resv MOD
Positive ACK report ACK SAPUinfo INFO
Negative NACK report NACK SAPUinfo INFO
Local Path initiation info LocalSAPU NEW
Local Path modification info LocalSAPU MOD
Local Path refreshing info LocalSAPU REFRESH
Local Path tear info LocalSAPU TEAR
Local Resv initiation info LocalSAPU NEW
Local Resv modification info LocalSAPU MOD
Local Resv refreshing info LocalSAPU REFRESH
Local Resv tear info LocalSAPU TEAR
Local positive ACK report ACK SAPUinfo INFO
Local negative ACK report NACK SAPUinfo INFO
Path Tear down Path TEAR
Resv Tear down Resv TEAR
Path Error report PathErr EVENT
Resv Error report ResvErr EVENT
Resv Confirm ResvErr EVENT
Westberg, et al. Expires April 2003 [Page 33]
Internet Draft Proposal for RSVPv2 October 2002
5.2. RSVPv2 ALSP Objects in RSVPv2 ALSP Object_Classes
This section presents a generic method of mapping globally and
locally defined RSVPv2 ALSP objects into RSVPv2 ALSP classes. Based
on the definitions of the RSVPv2 ALSP object classes, an RSVPv2 ALSP
Object_Class might contain globally and locally defined objects.
Below is shown a possible way of mapping globally and locally defined
objects into the RSVPv2 ALSP Object_Classes. The locally defined
objects are the "PHR" (Per Hop Reservation) and "PDR" (Per Domain
Reservation). These objects are used for intra-domain signaling and
are described in more detail in Section 5.2.2.
Service_Class:
[<PHR>]
[<PDR>]
<any globally defined e2e service objects>
Flow_Specification_Class:
<any globally defined e2e service Flow_Specification objects>
Reservation_State_Management_Class:
<any globally defined e2e service Reservation_State objects>
Security_Class:
<any globally defined e2e service Security objects>
Error_Message_Class:
<any globally defined e2e service Error_Message objects>
where:
[] is optional for unicast and multicast support and
sender-initiated and receiver-initiated approach
5.2.1. Example of mapping of RSVPv1 objects in RSVPv2 object_classes
This section gives an example of mapping the RSVPv1 objects into the
RSVPv2 object_classes when RSVPv1 is optimized for unicast and sender
initiated signaling.
If RSVPv1 is to be optimized for unicast and sender initiated
signaling certain changes in the mandatory usage of RSVPv1 objects
Westberg, et al. Expires April 2003 [Page 34]
Internet Draft Proposal for RSVPv2 October 2002
have to be provided. Based on the ALSP RSVPv2 object-class structure
an example of a possible mapping of RSVPv1 objects in RSVPv2 object
structure is given.
The main design constraint for RSVPv1 was multicast support. Because
of this, RSVPv1 is a receiver-initiated protocol with complex "soft"
state maintenance in order to support dynamic membership changes in
the multicast group, i.e. reservation state merging and maintenance.
Given that the vast majority of traffic in typical IP networks is
point-to-point unicast, the need to optimize RSVPv2 for unicast is
clear. If optimized for unicast, RSVPv1 does not have to be receiver-
initiated. Optimization for unicast support as a design requirement
will introduce some beneficial changes in the RSVPv2 protocol. These
changes will lead to a reduced complexity in reservation state
maintenance, for example there will be no need for dynamic membership
changes in a multicast group.
In RSVPv1 there are a number of mandatory objects related to the
multicast support and receiver-initiated approach. These objects will
not be needed, i.e. will not be mandatory if the protocol is
optimized for unicast and is sender-initiated.
The RSVPv1 Objects dedicated to multicast support and received-
initiated approach are:
* SCOPE
Carries an explicit list of sender hosts towards which the
information in the message is to be forwarded. This object
is an object for multicast support and it may appear in a
Resv, ResvErr, or ResvTear RSVPv1 messages.
* STYLE
Defines the reservation style plus style-specific information
that is not in FLOWSPEC or FILTER_SPEC objects. It is
mandatory in every Resv RSVPv1 message. This is also
an multicast object. Once the protocol is optimized for
unicast there will only be one style of reservation, i.e.
explicit reservation style.
* FILTER_SPEC
Defines a subset of session data packets that should
receive the desired QoS (specified by a FLOWSPEC object),
Westberg, et al. Expires April 2003 [Page 35]
Internet Draft Proposal for RSVPv2 October 2002
in a Resv message. This is an object that is related to
multicast and receiver-initiated approach. In a unicast
sender-initiated approach due to a single reservation style
there will only be one filter used, i.e. Fixed Filter (FF)
by a single unicast session.
* RSVP_HOP object
This object carries the IP address of the RSVP-capable node
that sent this message and a logical outgoing interface
handle. In RSVPv1, RSVP_HOP object is referred as a PHOP
("previous hop") object for downstream messages or as
a NHOP (" next hop") object for upstream messages. Thus
it is used for backward routing that is only useful in
receiver-initiated approach.
* FLOWSPEC
This object contains the QoS request desired by the
receiver. Thus it is needed only for the receiver-initiated
approach.
* ADSPEC
This object carries the OPWA data in a Path message in the
communication path from the sender to the receiver. It is
only useful in a receiver-initiated approach.
* RESV_CONFIRM
Carries the IP address of a receiver that requested a
confirmation. This object is only required in the receiver
initiated approach.
Therefore the mandatory objects that will be needed in an sender-
initiated ALSP RSVPv2 optimized for unicast are:
* SESSION
It contains the IP destination address (DestAddress), the
IP protocol id, and some form of generalized destination
port, to define a specific session for the other objects
that follow. This object contains information that is used
to define the flow ID.
Westberg, et al. Expires April 2003 [Page 36]
Internet Draft Proposal for RSVPv2 October 2002
* SENDER_TSPEC
Defines the traffic characteristics of a sender's data
flow. Required in a Path message. This object is used to
specify the QoS service required by the sender.
* SENDER_TEMPLATE
Contains a sender IP address and perhaps some additional
de-multiplexing information to identify a sender. Required
in a Path message. This object contains information that
is used to define the flow ID.
* TIME_VALUES
Contains the value for the refresh period R used by the
creator of the message. Required in every Path and Resv
message.
* ERROR_SPEC
Specifies an error in a PathErr, ResvErr, or a confirmation
in a ResvConf message.
* POLICY_DATA
Carries information that will allow a local policy module to
decide whether an associated reservation is administratively
permitted. May appear in Path, Resv, PathErr, or ResvErr
message. The use of POLICY_DATA objects is not fully
specified at this time; a future document will fill this gap.
* INTEGRITY
Carries cryptographic data to authenticate the originating
node and to verify the contents of this RSVPv1 message. The
use of the INTEGRITY object is described in [RFC2747].
Based on the definitions of the RSVPv2 object classes, RSVPv1 objects
(see [RFC2205]) can be re-used in a RSVPv2 object-class structure.
During the RSVPv2 design phase the RSVPv1 objects may be changed or
removed completely and also some other objects may be defined as
well. The goal is to reuse as much as possible of RSVPv1 objects.
Based on the description of RSVPv2 object classes and the current
RSVPv1 objects the mapping of RSVPv1 objects into the RSVPv2 object-
Westberg, et al. Expires April 2003 [Page 37]
Internet Draft Proposal for RSVPv2 October 2002
class structure is rather simple. This mapping is given below and it
is done for all RSVPv1 objects. Note that the Service_Class contains
the PHR and PDR objects that are locally defined objects and are used
for intra-domain signaling.
Service_Class:
[<PHR>]
[<PDR>]
<SENDER_TSPEC>
{<ADSPEC>}
{<FLOWSPEC>}
{<RESV_CONFIRM>}
[<POLICY_DATA>]
Flow_Specification_Class:
<SESSION>
<SENDER_TEMPLATE>
{<FILTER_SPEC>}
{<SCOPE>}
Reservation_State_Management_Class:
<SESSION>
<TIME_VALUES>
{<STYLE>}
{<RSVP_HOP>}
Security_Class:
[<INTEGRITY>]
Error_Message_Class:
<ERROR_SPEC>
where:
{} is mandatory only for multicast support and
receiver-initiated approach
[] is optional for unicast and multicast support and
sender-initiated and receiver-initiated approach
5.2.2. PDR/PHR objects
The PHR and PDR objects are locally defined objects that are used for
intra-domain signaling. The information contained in these objects
Westberg, et al. Expires April 2003 [Page 38]
Internet Draft Proposal for RSVPv2 October 2002
is similar to the information contained in the PHR and PDR messages
described in [RMD-frame] and [RODA].
The PDR and PHR information is encapsulated into two different ALSP
RSVPv2 object. Appendix 2 provides an example of PHR and PDR object
specifications
5.3. RSVPv2 ALSP functionality on nodes used for inter-domain
signaling
This section describes the RSVPV2 functionality on the different
nodes used for inter-domain signaling. These nodes are NI (NSIS
Initiator), NF (NSIS Forwarder) and NR (NSIS Responder). Note that
this functionality is already described in Section 6.
<<To be done>>
5.4. RSVPv2 ALSP functionality on nodes used for intra-domain
signaling
This section describes the RSVPV2 functionality on the different
nodes used for intra-domain signaling. These nodes are NF (ingress),
NF (interior) and NF (egress). Note that this functionality is
already described in Section 7.
<<to be done>>
6. Example of RSVPv2 ALSP Inter-domain signaling procedures
This section gives a brief description of the main flow diagram used
by the RSVPv2 protocol for inter-domain signaling procedures. RSVPv2
is considered in this section to be optimized for unicast and sender-
initiated protocol. This means that the ALSP Path SAPU initiates and
activates a reservation in each node that is passing through. The
Inter-domain signaling procedures are mainly using globally defined
objects, i.e., e2e service objects, see Figure 1.
6.1. Normal operation for uni-directional reservation
This section presents examples of RSVPv2 inter-domain signaling
procedures for RSVPv2 normal operation, i.e., operation without
Westberg, et al. Expires April 2003 [Page 39]
Internet Draft Proposal for RSVPv2 October 2002
failures.
Figure 2 shows the main flow diagram used by the RSVPv2 protocol in
case of a succesful reservation assuming that no intra-domain
signaling procedures are used. In this situation only the uni-
directional feature is considered. The NI(sender) after creating an
ALSP Path reservation state it generates an ALSP Path SAPU. The ID of
the ALSP Path reservation state can be included in the
Flow_Specificaton_Class (<Session> and <Sender_template> objects) and
Reservation_State_Management_Class (<Session> and <Time_Values>
objects). The information that is related to the service desired
from the network, i.e., requested QoS, can be included into the
Service_Class object class (<Session> and <Sender_Tspec> objects).
This ALSP Path reservation state will be associated to a SAPUid.
Note that in this situation the ALSP Path reservation state does not
contain any back-routing information. This SAPU Path and its SAPUid
is encapsulated into a CSTP NEW message (see [BrLi01]). Note that the
ALSP SAPU and SAPU-id that is encapsulated into the CSTP NEW message
should be stored by the CSTP level functionality for a certain and
predefined duration. The CSTP NEW message is processed by all CSTP
stateful nodes that is passing through, up to the NR (receiver). Each
node that processes the CSTP NEW message it will create a CSTP state
and will activate the ALSP "e2e service" functionality by using the
transported SAPU Path and creating an ALSP Path reservation state.
This ALSP Path reservation state will be associated to a SAPUid.
Note that the CSTP states it will have to store back-ward routing
information, which will be used by CSTP ACK messages in case that the
reliable transmission feature is supported. When the NR(receiver)
receives the CSTP NEW messsages it will create a CSTP state and it
will activate the ALSP functionality by using the SAPU Path and by
creating an ALSP Path reservation state, which is associated with the
SAPUid that is carried by the CSTP NEW message. Subsequently the
ALSP "e2e service" functionality will create an ALSP ACK SAPUinfo
that will be used to report information related to how the ALSP Path
SAPU has been processed along the path. Note that the SAPUinfo is
associated to a SAPUid and a SAPU, which includes reporting
information related to the SAPU that is identified by the SAPUid.
This ALSP ACK SAPUinfo will be encapsulated into a CSTP INFO message
and it will only be processed by the ALSP "e2e service" functionality
at NI (sender). Note that in this RSVP2 scenario the ALSP Path SAPU
is not using the CSTP reliable transmission feature, i.e., no CSTP
ACK message is used to confirm the reception of the CSTP NEW message.
The NI(sender) can then start transmitting traffic user data. Figure
2 also shows how the refresh procedure is performed. The RSVPv2
Westberg, et al. Expires April 2003 [Page 40]
Internet Draft Proposal for RSVPv2 October 2002
refresh procedure is a pure CSTP refresh procedure, meaning that a
CSTP REFRESH message that contains the SAPUid is periodicaly sent
though all the CSTP stateful nodes located between NI (sender) and NR
(receiver). The CSTP REFRESH message is using the CSTP reliable
transmission feature, i.e., each CSTP REFRESH message is
acknowledged.
NI (sender) NF (router) NF (router) NR (receiver)
CSTP stateful CSTP stateful CSTP stateful CSTP stateful
NEW(PATH SAPUid, SAPU, R) | |
|------------------->| | |
| |NEW(PATH SAPUid, SAPU, R) |
| | |NEW(PATH SAPUid,SAPU,R)
| |------------------->| |
| | |------------------->|
| |INFO (ACK SAPUid, SAPU, SAPUinfo) |
|<-------------------|--------------------|--------------------|
| | | |
| | Traffic(user) Data | |
|------------------->|------------------->|------------------->|
| | |
|REFRESH(PATH SAPUid, R) | |
|------------------->| | |
| |REFRESH(PATH SAPU-id, R) |
| | |REFRESH(PATH SAPU-id,R)
| |------------------->| |
| | |------------------->|
| | | ACK(PATH SAPU-id) |
| | ACK(PATH SAPU-id) |<-------------------|
| |<-------------------| |
|ACK(PATH SAPU-id) | | |
|<-------------------| | |
Figure 2: Inter-domain signaling normal operation for successful
reservation
Figure 3 depicts the RSVPv2 tearing down procedure. The ALSP "e2e
service" functionality of the NI(sender) informs the CSTP functionality
of the same node to start a tear down procedure for the specific SAPUid.
A CSTP TEAR message is created that encapsulates the SAPUid and is sent
towards the NR (receiver). This message will tear down all the CSTP and
ALSP states that are associated with the SAPUid of all CSTP stateful
Westberg, et al. Expires April 2003 [Page 41]
Internet Draft Proposal for RSVPv2 October 2002
nodes that process the CSTP TEAR message. Note that in this RSVP2
scenario the CSTP TEAR message is not using the CSTP reliable
transmission feature, i.e., no CSTP ACK message is used to confirm the
reception of the CSTP TEAR message.
NI (sender) NF (router) NF (router) NR (receiver)
CSTP stateful CSTP stateful CSTP stateful CSTP stateful
|TEAR(Path SAPUid) | | |
|------------------->| | |
| |TEAR(Path SAPUid) | |
| |------------------->|TEAR(Path SAPUid) |
| | |------------------->|
Figure 3: Inter-domain signaling normal operation for tearing down a
reservation
Figure 4 shows the main flow diagram used by the RSVPv2 protocol in case
of an unsuccesful reservation assuming that no intra-domain signaling
procedures are used. In this situation only the uni-directional feature
is considered. In this situation the ALSP Path SAPU and CSTP NEW
messages are created and transmitted in the same way as during the
successful reservation. The main differece is related to the fact that
one of the NF(routers) is not able to satisfy the ALSP Path SAPU
request. In this situation this ALSP "e2e service" functionality of this
particular NF(router) will generate an ALSP NACK SAPUinfo to report to
NI(sender) that the ALSP PATH SAPU request could not be satisfied. This
ALSP NACK SAPUinfo will be encapsulated into an INFO message and it will
only be processed by the ALSP "e2e service" functionality at NI
(sender).
NI (sender) NF (router) NF (router) NR (receiver)
CSTP stateful CSTP stateful CSTP stateful CSTP stateful
NEW(PATH SAPUid, SAPU, R) | |
|------------------->| | |
| |NEW(PATH SAPUid, SAPU, R) |
| | | |
| |------------------->| |
| | | |
| |INFO (NACK SAPUid, SAPU, SAPUinfo) |
|<-------------------|--------------------| |
| | | |
Figure 4: Inter-domain signaling normal operation for unsuccessful
reservation
Westberg, et al. Expires April 2003 [Page 42]
Internet Draft Proposal for RSVPv2 October 2002
Figure 5 shows the main flow diagram used by the RSVPv2 protocol in case
of a modification of a reservation procedures assuming that no intra-
domain signaling procedures are used. In this situation only the uni-
directional feature is considered. The modification of the reservation
is included in a new SAPU Path. The ID of the ALSP Path reservation
state can be included in the Flow_Specificaton_Class (<Session> and
<Sender_template> objects) and Reservation_State_Management_Class
(<Session> and <Time_Values> objects). The information that has to be
modified that can be included into the Service_Class object class
(<Session> and <Sender_Tspec> objects).
The old-SAPUid (ID of the stored SAPU before the modification), the
SAPUid and the SAPU are encapsulated in a CSTP MOD message and sent
towards the NR (receiver). The ALSP information is read by each CSTP
stateful node that processes the CSTP MOD message. The ALSP Path
reservation state that is associated to the old-SAPUid is modified using
the Path SAPU that is carried by the CSTP MOD message. When the
NR(receiver) receives the CSTP MOD messsages it will activate the ALSP
"e2e service" functionality. The ALSP reservation state that is
associated to the old-SAPUid is modified using the Path SAPU that is
carried by the CSTP MOD message. Subsequently the ALSP "e2e service"
functionality will create an ALSP ACK SAPUinfo that will be used to
report information related to how the ALSP Path SAPU has been processed
along the path. Note that the SAPUinfo is associated to a SAPUid and a
SAPU, which includes reporting information related to the SAPU that is
identified by the SAPUid. This ALSP ACK SAPUinfo will be encapsulated
into a CSTP INFO message and it will only be processed by the ALSP
functionality at NI (sender). Note that in this RSVP2 scenario the ALSP
Path SAPU is not using the CSTP reliable transmission feature, i.e., no
CSTP ACK message is used to confirm the reception of the CSTP MOD
message.
NI (sender) NF (router) NF (router) NR (receiver)
CSTP stateful CSTP stateful CSTP stateful CSTP stateful
MOD(PATH old-SAPUid, SAPU, SAPUid, R) | |
|------------------->| | |
| MOD(PATH old-SAPUid, SAPU, SAPUid, R) |
| | MOD(PATH old-SAPUid, SAPU, SAPUid, R)
| |------------------->| |
| | |------------------->|
| |INFO (ACK SAPUid, SAPU, SAPUinfo) |
|<-------------------|--------------------|--------------------|
| | | |
Figure 5: Inter-domain signaling normal operation for modification of
reservation
Westberg, et al. Expires April 2003 [Page 43]
Internet Draft Proposal for RSVPv2 October 2002
6.2. Normal operation for bi-directional reservation
This section describes the RSVPv2 ALSP signaling used for bi-
directional reservations. With bi-directional reservations we mean
here reservations having the same end-points. But the path in the
two directions does not need to be the same.
<< To be done >>
7. Example of RSVPv2 ALSP Intra-domain signaling procedures
This section gives a brief description of the main flow diagram used
by the RSVPv2 protocol for intra-domain signaling procedures. RSVPv2
is considered in this section to be optimized for unicast and sender-
initiated protocol. Intra-domain signaling is where the RSVPv2
signaling messages are originated, processed and terminated within
the same domain.
The Intra-domain signaling procedures are mainly using ALSP PHR/PDR
objects, (see Section 5.2.2) that are originated, processed and
terminated within the same domain.
7.1. Normal operation for uni-directional reservation
This section presents examples of RSVPv2 intra-signaling procedures
for RSVPv2 normal operation, i.e., operation without failures.
Figure 6 shows the main flow diagram intra-domain signaling used by
the RSVPv2 protocol in case of a succesful reservation. In this
situation only the uni-directional feature is considered. Note that
the same figure shows how the ALSP RSVPv2 inter-domain and intra-
domain signaling can inter-operate. When an ALSP Path SAPU that
requests the initiation of a reservation state arrives at the ALSP
functionality of the ingress node of a domain (see Figure 6), the
NF(ingress) node uses the ALSP "e2e service" functionality and
creates an ALSP Path reservation state. The NF(ingress) after
creating an ALSP Path reservation state it generates an ALSP Path
SAPU. The ID of the ALSP reservation state can be included in the
Flow_Specificaton_Class (<Session> and <Sender_template> objects) and
Reservation_State_Management_Class (<Session> and <Time_Values>
objects). The information that is related to the service desired
from the network, i.e., requested QoS, can be included into the
Westberg, et al. Expires April 2003 [Page 44]
Internet Draft Proposal for RSVPv2 October 2002
Service_Class object class (<Session> and <Sender_Tspec> objects).
This ALSP Path reservation state will be associated to a SAPUid.
Subsequntly, the ALSP "PDR" protocol functionality is activated (see
Figure 1) classifying the flow (i.e., Flow_Specification_Class) that
is associated with the ALSP Path SAPU into an appropriate traffic
class, e.g., Diffserv class. The ALSP PDR functionality uses the
information included in the Flow_Specification_Class and creates a
PDR state. This PDR state will be used to associate the PHR and PDR
objects with the flow that created the ALSP Path reservation state in
the NF(ingress) node. The ALSP PDR functionality is subsequently
using the Service_Class (<SENDER_Tspec> object) translates the
requested bandwidth parameter into a number of resource units. The
PDR state will be associated with a flow specification ID and the
SAPUid. If the QoS request is satisfied locally, then the ingress
node will generate a reservation request PHR object denoted as
"PHR_Resource_Request" and a reservation request PDR object denoted
as "PDR_Reservation_Request", (see Section 5.2.2). The PDR object
MAY contain information such as the IP address of the NF(ingress)
node and the per-flow specification ID. These PHR and PDR objects
will form the LocalSAPU. The ALSP SAPU Path, its SAPUid and the
LocalSAPU are encapsulated into a CSTP NEW message. Note that the
ALSP SAPU, SAPU-id and LocalSAPU that is encapsulated into the CSTP
NEW message should be stored by the CSTP level functionality for a
certain and predefined duration. The CSTP NEW message is processed
by all CSTP stateless NF(interior) nodes that is passing through, up
to the NF (egress). Each node that processes the CSTP NEW message it
will not create a CSTP state but it will activate the ALSP
functionality by using the transported ALSP LocalSAPU. The CSTP
level functionality of the CSTP stateless NF(interior) nodes
receiving the CSTP "NEW" message and by using the ALSP/CSTP Upcall
interface will send the ALSP LocalSAPU that contains the
"PHR_Resource_Request" and "PDR_Reservation_Request" to the ALSP
"PHR/PDR" functionality.
The ALSP "PHR" functionality of these NF(interior) nodes will use the
information included in the PHR object ("PHR_Resource_Request") and
it will identify the ID of the traffic class, e.g., Diffserv class.
If there is enough bandwidth capacity, it will reserve the requested
resources. The NF(interior) node reserves the requested resources by
e.g., adding the requested amount to the total amount of reserved
resources for that traffic class, e.g., Diffserv class.
The behavior of the NF(egress) node on admission or rejection of the
CSTP "NEW" messsage that contains as ALSP LocalSAPU the
"PHR_Resource_Request" object is the same as in the NF(interior)
Westberg, et al. Expires April 2003 [Page 45]
Internet Draft Proposal for RSVPv2 October 2002
nodes. After processing the "PHR_Resource_Request" object, the ALSP
PDR functionality of the NF(egress) node uses the
"PDR_Reservation_Request" object and creates/identifies the flow
specification ID and the state associated with it. Subsequently, the
ALSP "e2e service" functionality is activated and by using the ALSP
SAPU Path it will create an ALSP Path reservation state, which is
associated with the SAPUid that is carried by the CSTP NEW message.
Subsequently, the CSTP NEW message is forwarded towards the NR
(receiver), and it will be processed by all CSTP stateful nodes that
is passing through as an inter-domain signaling procedure, see
Section 6. Note that this CSTP NEW message will not include the
LocalSAPU information.
Moreover, the ALSP "PDR" functionality of the NF(egress) node will
report the successful reservation to the ALSP "PDR" functionality of
the NF(ingress) node by using a "PDR_Reservation_Report" PDR object
that will be encapsulated into a CSTP INFO message as an ALSP ACK
SAPUinfo. Note that the SAPUinfo is associated to a SAPUid and a
SAPU, which includes reporting information related to the SAPU that
is identified by the SAPUid. This ALSP ACK SAPUinfo will be
encapsulated into a CSTP INFO message and it will only be processed
by the ALSP functionality at NF (ingress). Note that in this RSVP2
scenario the ALSP Path SAPU is not using the CSTP reliable
transmission feature, i.e., no CSTP ACK message is used to confirm
the reception of the CSTP NEW message.
When the NR(receiver) receives the CSTP NEW messsage, similar to the
procedure used in Section 6 it will create a CSTP state and it will
activate the ALSP "e2e service" functionality by using the SAPU Path
and by creating an ALSP Path reservation state, which is associated
with the SAPUid that is carried by the CSTP NEW message.
Subsequently the ALSP "e2e service" functionality will create an ALSP
ACK SAPUinfo that will be used to report information related to how
the ALSP Path SAPU has been processed along the path. Note that the
SAPUinfo is associated to a SAPUid and a SAPU, which includes
reporting information related to the SAPU that is identified by the
SAPUid. This ALSP ACK SAPUinfo will be encapsulated into a CSTP INFO
message and it will only be processed by the ALSP functionality at NI
(sender). Note that in this RSVP2 scenario the ALSP Path SAPU is not
using the CSTP reliable transmission feature, i.e., no CSTP ACK
message is used to confirm the reception of the CSTP NEW message.
The NI(sender) can then start transmitting traffic user data.
Figure 6 also shows how the refresh procedure is performed. The
Westberg, et al. Expires April 2003 [Page 46]
Internet Draft Proposal for RSVPv2 October 2002
inter-domain RSVPv2 refresh procedure is a pure CSTP refresh
procedure, see Section 6. However, the intra-domain RSVPv2 refresh
procedure is a combination of a CSTP and an ALSP "PHR/PDR" procedure.
When an CSTP REFRESH procedure is received by a NF(ingress) node the
CSTP functionality will activate the ALSP "PHR/PDR" functionality via
the SAPUid information that is carried by the CSTP REFRESH message.
By using the SAPUid the ALSP "PDR" functionality will identify its
associated PDR state. The ALSP "PDR" functionality of the
NF(ingress) node will generate a refresh request PHR object denoted
as "PHR_Refresh_Update" and a refresh request PDR object denoted as
"PDR_Refresh_Request", (see Section 5.2.2). The PDR object MAY
contain information such as the IP address of the NF(ingress) node
and the per-flow specification ID. These PHR and PDR objects will
form the LocalSAPU. The PATH SAPUid and the LocalSAPU are
encapsulated into a CSTP REFRESH message. Note that the ALSP SAPU-id
and LocalSAPU that is encapsulated into the CSTP REFRESH message
should be stored by the CSTP level functionality for a certain and
predefined duration. The CSTP REFRESH message is processed by all
CSTP stateless NF(interior) nodes that is passing through, up to the
NF (egress). Each node that processes the CSTP REFRESH message it
will refresh the CSTP state associated the SAPUid and it will
activate the ALSP "PHR" functionality by using the transported ALSP
LocalSAPU. The CSTP level functionality of the CSTP stateless
NF(interior) nodes receiving the CSTP REFRESH message and by using
the ALSP/CSTP Upcall interface will send the ALSP LocalSAPU that
contains the "PHR_Refresh_Update" and "PDR_Refresh_Request" to the
ALSP "PHR/PDR" functionality.
The ALSP "PHR" functionality of these NF(interior) nodes will use the
information included in the PHR object ("PHR_Refresh_Request") and it
will identify the ID of the traffic class, e.g., Diffserv class. This
object will refresh the requested resources included in the
"PHR_Refresh_Update" object.
The NF(egress)node that processes the CSTP REFRESH message it will
refresh the CSTP state associated the SAPUid and it will activate the
ALSP "PHR" functionality by using the transported ALSP LocalSAPU.
The behavior of the ALSP "PHR" functionality in the NF(egress) node
is similar to the ALSP "PHR" functionality provided in the
NF(interior) nodes.
Subsequently, the CSTP REFRESH message is forwarded towards the NR
(receiver), and it will be processed by all CSTP stateful nodes that
is passing through as an inter-domain signaling procedure, see
Westberg, et al. Expires April 2003 [Page 47]
Internet Draft Proposal for RSVPv2 October 2002
Section 6. Note that this CSTP REFRESH message will not include the
LocalSAPU information. When the NR(receiver) receives the CSTP
REFRESH messsage, similar to the procedure used in Section 6 it uses
the CSTP reliable delivery feature by sending a CSTP ACK message.
Note however, that the CSTP stateless (i.e., NF(interior)) nodes do
not process the CSTP ACK message.
Westberg, et al. Expires April 2003 [Page 48]
Internet Draft Proposal for RSVPv2 October 2002
NF (ingress) NF (interior) NF (interior) NF (egress)
CSTP stateful CSTP stateless CSTP stateless CSTP stateful
| | | |
NEW(PATH SAPUid, SAPU, R)| | |
--->|NEW(PATH SAPUid, SAPU, R, LocalSAPU): | |
|PHR_Resource_Request| | |
|PDR_ResReq |NEW(PATH SAPUid, SAPU, R, LocalSAPU): |
|------------------->|PHR_Resource_Request |
| |PDR_ResReq NEW(PATH SAPUid, SAPU, R, LocalSAPU):
| |------------------->|PHR_Resource_Request|
| | |PDR_ResReq |
| | |------------------->|
| | |NEW(PATH SAPUid, SAPU, R):
| | | |----->
| | |INFO (ACK SAPUid, SAPUinfo)
| | | |<------
| |INFO (ACK SAPUid, SAPU, SAPUinfo) |
| |PDR_Reservation_Report |
|<-------------------------------------------------------------|
INFO(ACK SAPUid, SAPUinfo) | |
<---| | | |
| | Traffic(user) Data | |
--->|------------------->|------------------->|------------------->|--->
| | | |
REFRESH(PATH SAPUid, R) | | |
--->| | | |
REFRESH(PATH SAPUid, R, LocalSAPU): | |
|PHR_Refresh_Update | | |
|PDR_RefReq |REFRESH(PATH SAPUid, R, LocalSAPU): |
|------------------->|PHR_Refresh_Update | |
| |PDR_RefReq REFRESH(PATH SAPUid, R, LocalSAPU):
| |------------------->|PHR_Refresh_Update |
| | |PDR_RefReq |
| | |------------------->|
| | | REFRESH(PATH SAPUid, R)
| | | |----->
| | | ACK (PATH SAPUid)
| | | |<------
| |ACK (PATH SAPUid) | |
|<-------------------------------------------------------------|
ACK (PATH SAPUid) | | |
<--------| | | |
(PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
This PDR object is processed only by the
NF(ingress) and NF(egress) nodes.
Westberg, et al. Expires April 2003 [Page 49]
Internet Draft Proposal for RSVPv2 October 2002
(PDR_RefReq) - represents the PDR_Refresh_Request PDR object
This PDR object is processed only by the NF(ingress) and
NF(egress) nodes.
Figure 6: Inter-domain signaling normal operation for successful
reservation
Figure 7 depicts the intra-domain RSVPv2 tearing down procedure. A
CSTP TEAR message that encapsulates the SAPUid is received by the
CSTP functionality of the NF(ingress) node. The CSTP functionality
activates the ALSP "PDR/PHR" functionality, that is related to the
SAPUid. The ALSP "PDR" functionality of the NF(ingress) node will
generate a release request PHR object denoted as
"PHR_Release_request" and a release request PDR object denoted as
"PDR_Release_Request", (see Section 5.2.2). The PDR object MAY
contain information such as the IP address of the NF(ingress) node
and the per-flow specification ID. These PHR and PDR objects will
form the LocalSAPU. The PATH SAPUid and the LocalSAPU are
encapsulated into a CSTP TEAR message and sent towards the NF(egress)
node. All the ALSP and CSTP states in the NF(ingress) node
associated to the same SAPUid will be teard down. The CSTP TEAR
message is processed by all CSTP stateless NF(interior) nodes that is
passing through, up to the NF (egress). Each node that processes the
CSTP TEAR message it will activate the ALSP "PHR" functionality by
using the transported ALSP LocalSAPU. The CSTP level functionality
of the CSTP stateless NF(interior) nodes receiving the CSTP TEAR
message and by using the ALSP/CSTP Upcall interface will send the
ALSP LocalSAPU that contains the "PHR_Release_Request" and
"PDR_Release_Request" to the ALSP "PHR/PDR" functionality.
The ALSP "PHR" functionality of these NF(interior) nodes will use the
information included in the PHR object ("PHR_Release_Request") and it
will identify the ID of the traffic class, e.g., Diffserv class. This
object will subtract the requested resources included in the
"PHR_Release_Request" object from the total reserved amount of
resources stored in the traffic class state.
The NF(egress) node that processes the CSTP TEAR message it will it
will activate the ALSP "PHR" functionality by using the transported
ALSP LocalSAPU.
The behavior of the ALSP "PHR" functionality in the NF(egress) node
is similar to the ALSP "PHR" functionality provided in the
NF(interior) nodes. All the ALSP and CSTP states in the NF(ingress)
node associated to the same SAPUid will be teard down. Subsequently,
Westberg, et al. Expires April 2003 [Page 50]
Internet Draft Proposal for RSVPv2 October 2002
the CSTP TEAR message is forwarded towards the NR (receiver), and it
will be processed by all CSTP stateful nodes that is passing through
as an inter-domain signaling procedure, see Section 6. Note that
this CSTP TEAR message will not include the LocalSAPU information.
NF (ingress) NF (interior) NF (interior) NF (egress)
CSTP stateful CSTP stateless CSTP stateless CSTP stateful
| | | |
| | Traffic(user) Data | |
-->|------------------->|------------------->|------------------->|--->
| | | |
TEAR(Path SAPUid) | | |
-->| | | |
TEAR(Path SAPUid, LocalSAPU): | |
|PHR_Release_Request | | |
|PDR_RelReq |Tear(Path SAPUid, LocalSAPU): |
|------------------->|PHR_Release_Request |
| |PDR_RelReq TEAR(Path SAPUid, LocalSAPU):
| |------------------->|PHR_Release_Request |
| | |PDR_RelReq |
| | |------------------->|
| | | Tear(Path SAPUid)
| | | |----->
(PDR_RelReq) - represents the PDR_Release_Request object. This object is
processed only by the NF(ingress) and NF(egress) nodes.
Figure 7: Intra-domain signaling normal operation for explicit release
Figure 8 shows the main intra-domain flow diagram used by the RSVPv2
protocol in case of an unsuccesful reservation. In this situation
only the uni-directional feature is considered. In this situation
the ALSP Path SAPU, SAPUid, LocalSAPU and CSTP NEW messages are
created and transmitted in the same way as during the successful
reservation. The main differece is related to the fact that one of
the CSTP stateless NF(interior) is not able to satisfy the request
carried by the "PHR_Resource_Request" PHR object. The ALSP "PHR"
functionality of this NF(interior) node will mark the "M" field of
the "PHR_Resource_Request" object. The ALSP "PHR" functionality will
also include the number of previous NF(interior) nodes that
successfully processed the ALSP "PHR_Resource_Request" PHR object
(see Appendix 2). This number can, for example, be identified by the
TTL (Time-To-Live) value included in the IP header of the received
CSTP NEW message. Note that each time that an IP packet passes a
Westberg, et al. Expires April 2003 [Page 51]
Internet Draft Proposal for RSVPv2 October 2002
node, its TTL value is decreased by one. Furthermore, note that the
NF(ingress) node should temporarily store the TTL value included in
the IP header of any CSTP NEW message in the ALSP PDR state
associated to the CSTP NEW message. In case of an unsuccesful
reservation, this information, that we denote as PDR_TTT_I will be
used in combination with the value included in the PDR_TTL field (see
Appendix 2) of a receiving "PDR" reporting object. The PDR_TTL field
is generated and sent by a NF(interior) node that could not
succesfuly process the "PHR" object, e.g., admit the requested "PHR"
reservation. The NF(Ingress) node using this information can
calculate how many NF(interior) nodes before the NF(interior) node
that rejected the "PHR_Resource_Request" object, processed this
object.
In particular, the NF(interior) node that is not admitting the
reservation request initiated by the "PHR_Resource_Request" PHR
object will copy the TTL value included in the IP header of the
received CSTP NEW message that carries the "PHR_Resource_Request"
object into the "PDR_TTL" field of "PDR_Reservation_Request" PDR
object. Moreover, the "T" field of the "PHR" object (see Appendix 2)
is set to "1". These "PHR" and "PDR" objects are inluded in the CSTP
NEW message as a LocalSAPU. This CSTP NEW message will be sent
towards the NF(egress) node, which will be transported by a CSTP NEW
message. Any NF(interior) node receiving a CSTP NEW message will
activate the ALSP "PHR" functionality. If the "PHR_Resource_Request"
PHR object is "M" marked, then the ALSP "PHR" functionality will not
further process the "PHR" object. The NF(egress) node receiving a
CSTP NEW message will activate the ALSP "PHR" functionality. If the
"PHR_Resource_Request" PHR object is "M" marked, then the ALSP "PHR"
functionality will activate the ALSP "PDR" functionality that will
create and "M" mark the "PDR_Reservation_Report" object. Moreover,
if the "T" field value included in the "PHR" object is "1" then the
PDR_TTL value that was included by the NF(interior) node into the
"PDR_Reservation_Request" object will be copied into the PDR_TTL
value of the "PDR_Reservation_Report" object. The "PDR" object will
be included in an CSTP INFO message as a NACK SAPUinfo that will be
sent towards the NF(ingress) node. This CSTP INFO message will only
be processed by the NF(ingress) node. The CSTP functionality of the
NF(ingress) node that receives the CSTP INFO message will activate
the ALSP "PDR" functionality. Due to the "M" marked
"PDR_Reservation_Report" object the "PDR" functionality will activate
the ALSP "e2e service". The ALSP "e2e service" functionality of the
NF(ingress) node will generate an ALSP NACK SAPUinfo to report to
NI(sender) that the ALSP PATH SAPU request could not be satisfied.
This ALSP NACK SAPUinfo will be encapsulated into an INFO message and
Westberg, et al. Expires April 2003 [Page 52]
Internet Draft Proposal for RSVPv2 October 2002
it will only be processed by the ALSP "e2e service" functionality at
NI (sender).
Simultaneously, the NF(ingress) node will start a partial explicit
release procedure, for releasing the unnecessarily reserved resources
in some interior nodes for the rejected flow. In this case, the ALSP
"PDR" functionality of the NF(ingress) node will generate a
"PHR_Release_Request" object, and it will include the amount of the
requested resources specified the PDR state. Moreover, the ALSP
"PDR" functionality will create the "PDR_Reservation_Request" PDR
object.
The ALSP "PDR" functionality of the NF(ingress) node can calculate
the number of NF(interior) nodes that before the NF(interior) node,
which rejected the "PHR_Resource_Request" object, processed this
object. This number can be calculated by subtracting the value
included in the PDR_TTL field that was included in the received
"PDR_Reservation_Report" PDR object from the value included in the
PDR_TTL_I variable that has been stored into the ALSP "PDR" state.
This calculated value will be included in the TTL - IP header field
of the CSTP TEAR message that is generated by the NF(ingress) node
and that will transport the "PHR_Resource_Release" object. The
"PHR_Release_Request" and "PDR_Release_Request" objects will be
encapsulated and transported by a CSTP TEAR message as a LocalSAPU.
The ALSP "PHR" functionality of any node that receives a
"PHR_Resource_Release" object must identify the traffic class, e.g.,
DSCP and release the requested resources associated with it. This
can be achieved by e.g., subtracting the amount of requested
resources, included in the "PHR_Release_Request" object, from the
total reserved amount of resources stored in the traffic class state.
Moreover, its TTL value of the CSTP TEAR message is decremented by
one. When this value becomes zero, the "PHR_Resource_Release"
message reached the interior node that marked the
"PHR_Resource_Request" message and it will be dropped. This means
that this message will not release any resources in this node.
Westberg, et al. Expires April 2003 [Page 53]
Internet Draft Proposal for RSVPv2 October 2002
NF (ingress) NF (interior) NF (interior) NF (egress)
CSTP stateful CSTP stateless CSTP stateless CSTP stateful
| | | |
NEW(PATH SAPUid, SAPU, R)| | |
--->|NEW(PATH SAPUid, SAPU, R, LocalSAPU): | |
|PHR_Resource_Request| | |
|PDR_ResReq |NEW(PATH SAPUid, SAPU, R, LocalSAPU): |
|------------------->|PHR_Resource_Request |
| |PDR_ResReq NEW(PATH SAPUid,SAPU,R,LocalSAPU):
| |------------------->M PHR_Resource_Request(M
| | M marked)
| | M PDR_ResReq |
| | M------------------->|
| |INFO (NACK SAPUid, SAPU, SAPUinfo(marked)):
| |PDR_Reservation_Report |
|<-------------------------------------------------------------|
INFO (ACK SAPUid, SAPUinfo) | |
<---| | | |
|TEAR(Path SAPUid, LocalSAPU): | |
|PHR_Resource_Release| | |
|PDR_RelReq | | |
|------------------->| | |
(PDR_ResReq*) - represents the "PDR_Reservation_Request" PDR object.
This PDR object is processed only by the
NF(ingress) and NF(egress) nodes.
(PDR_RelReq*) - represents the PDR_Release_Request object. This object is
processed only by the NF(ingress) and NF(egress) nodes.
Figure 8: Intra-domain signaling normal operation for unsuccessful
reservation
Figure 9 and Figure 10 show the intra-domain main flow diagram used
by the RSVPv2 protocol in case of a modification of a reservation
procedures. In this situation only the uni-directional feature is
considered. The modification of the reservation is included in a new
SAPU Path. A CSTP MOD message that encapsulates the PATH SAPUid and
SAPU is received by the CSTP functionality of the NF(ingress) node.
The CSTP functionality activates the ALSP "PDR/PHR" functionality,
that is related to the SAPUid. When the modification request
requires an increase on the number of reserved resources stored in
the PDR state (see Figure 9), then the ALSP "PHR" functionality of
the NF(ingress) node will have to subtract the old and already
reserved number of resources from the number of resources included in
Westberg, et al. Expires April 2003 [Page 54]
Internet Draft Proposal for RSVPv2 October 2002
the new modification request. The result of this subtraction should
be introduced within a "PHR_Resource_Request" PHR object as the
requested resources value. Furthermore, the number of resources that
were reserved for a certain flow should in a PDR state also be
replaced with the number of resources included in the modification
request.
The ALSP "PDR" functionality will create a "PDR_Modification_Request"
PDR object. These two objects will be encapsulated into a CSTP MOD
message as LocalSAPU. The ALSP "PHR" functionality of each NF node
processes the PHR object as a "PHR_Resource_Request" object. Each
NF(interior) node that receives the CSTP MOD messsage will activate
the ALSP "PHR" functionality.
Moreover, the ALSP "PDR" functionality of the NF(egress) node will
report the successful modification procedure to the ALSP "PDR"
functionality of the NF(ingress) node by using a
"PDR_Modification_Report" PDR object that will be encapsulated into a
CSTP INFO message as an ALSP ACK SAPUinfo. Note that the SAPUinfo is
associated to a SAPUid and a SAPU, which includes reporting
information related to the SAPU that is identified by the SAPUid.
This ALSP ACK SAPUinfo will be encapsulated into a CSTP INFO message
and it will only be processed by the ALSP functionality at NF
(ingress). The NF(egress) node forwards the CSTP MOD message towards
the NR(receiver).
If a ALSP "PHR" functionality of any node is not able to reserve the
number of requested resources, then the "PHR_Resource_Request" PHR
object will be marked. In this situation the ALSP PHR and PDR
protocol functionality associated with an unsuccessful reservation
procedure will be applied for this case (see Figure 8).
Westberg, et al. Expires April 2003 [Page 55]
Internet Draft Proposal for RSVPv2 October 2002
NF (ingress) NF (interior) NF (interior) NF (egress)
CSTP stateful CSTP stateless CSTP stateless CSTP stateful
MOD(PATH old-SAPUid, SAPU, SAPUid, R) | |
-->|MOD(PATH old-SAPUid, SAPU, SAPUid, R, LocalSAPU): |
|PHR_Resource_Request| | |
|PDR_ModReq |MOD(PATH old-SAPUid, SAPU, SAPUid, R, LocalSAPU):
| |PHR_Resource_Request| |
| |PDR_ModReq | |
| | MOD(PATH old-SAPUid,SAPU,SAPUid,R, LocalSAPU):
| |------------------->|PHR_Resource_Request|
| | |PDR_ModReq |
| | |------------------->|
| | MOD(PATH old-SAPUid, SAPU, SAPUid, R
| | | |------>
| |INFO (ACK SAPUid, SAPU, SAPUinfo): |
| |PDR_Modification_Report |
|<-------------------|--------------------|--------------------|
| | | |
| |INFO (ACK SAPUid, SAPU, SAPUinfo) |
<------------------------------------------------------------------------
| | | |
(PDR_ModReq*) - represents the "PDR_Modification_Request" PDR object.
This PDR object is processed only by the
NF(ingress) and NF(egress) nodes.
Figure 9: Intra-domain signaling normal operation for modification of
reservation when new number of resources is higher
than number of already reserved resources
When the modification request requires a decrease on the number of
reserved resources stored in the PDR state (see Figure 10), then the
ALSP "PHR" functionality of the NF(ingress) node will have to
subtract the number of resources included in the new modification
request from the old and already reserved number of resources. The
result of this subtraction should be introduced in an ALSP
"PHR_Release_Request" PHR object. Furthermore, the number of
resources that were reserved for a certain flow should in a PDR state
also be replaced with the number of resources included in the
modification request. The ALSP "PDR" functionality will create a
"PDR_Modification_Request" PDR object. These two objects will be
encapsulated into a CSTP MOD message as LocalSAPU. This message will
Westberg, et al. Expires April 2003 [Page 56]
Internet Draft Proposal for RSVPv2 October 2002
be sent towards the NF(egress) node. The ALSP "PHR" functionality of
each NF node processes the PHR object as a "PHR_Resource_Release"
object. Each NF(interior) node that receives the CSTP MOD messsage
will activate the ALSP "PHR" functionality. The ALSP "PHR"
functionality of these NF(interior) nodes will use the information
included in the PHR object ("PHR_Release_Request") and it will
identify the ID of the traffic class, e.g., Diffserv class. This
object will subtract the requested resources included in the
"PHR_Release_Request" object from the total reserved amount of
resources stored in the traffic class state. Moreover, the ALSP
"PDR" functionality of the NF(egress) node will report the successful
modification procedure to the ALSP "PDR" functionality of the
NF(ingress) node by using a "PDR_Modification_Report" PDR object that
will be encapsulated into a CSTP INFO message as an ALSP ACK
SAPUinfo. Note that the SAPUinfo is associated to a SAPUid and a
SAPU, which includes reporting information related to the SAPU that
is identified by the SAPUid. This ALSP ACK SAPUinfo will be
encapsulated into a CSTP INFO message and it will only be processed
by the ALSP functionality at NF (ingress). The NF(egress) node
forwards the CSTP MOD message towards the NR(receiver).
Westberg, et al. Expires April 2003 [Page 57]
Internet Draft Proposal for RSVPv2 October 2002
NF (ingress) NF (interior) NF (interior) NF (egress)
CSTP stateful CSTP stateless CSTP stateless CSTP stateful
MOD(PATH old-SAPUid, SAPU, SAPUid, R) | |
-->|MOD(PATH old-SAPUid, SAPU, SAPUid, R, LocalSAPU): |
|PHR_Release_Request| | |
|PDR_ModReq |MOD(PATH old-SAPUid, SAPU, SAPUid, R,LocalSAPU):
| |PHR_Release_Request| |
| |PDR_ModReq | |
| | MOD(PATH old-SAPUid,SAPU,SAPUid,R,LocalSAPU):
| |------------------>|PHR_Release_Request |
| | |PDR_ModReq |
| | |------------------->|
| | MOD(PATH old-SAPUid,SAPU,SAPUid,R)
| | | |------>
| |INFO (ACK SAPUid, SAPU, SAPUinfo): |
| |PDR_Modification_Report |
|<-------------------|-------------------|--------------------|
| | | |
| |INFO (ACK SAPUid, SAPU, SAPUinfo) |
<-----------------------------------------------------------------------
| | | |
(PDR_ModReq*) - represents the PDR_Modification_Request object. This
object is processed only by the NF(ingress) and NF(egress)
nodes.
Figure 10: Modification of reserved resources when new number of
resources is lower than number of already reserved resources
7.2. Example of Fault Handling Operation
Fault Handling Operation refers to the situations when there are
problems in the network, such as loss of CSTP messages route change,
link failure, etc. Two typical situations will be described: the loss
of the PHR signalling messages and severe congestion. The fault
handling operation described here is in general independent from the
type of the example scenarios, thus it can be applied in both cases.
Westberg, et al. Expires April 2003 [Page 58]
Internet Draft Proposal for RSVPv2 October 2002
7.2.1. Loss of CSTP signalling messages
The CSTP signaling messages and subsequently the "PHR" and "PDR"
objects might be dropped, for example due to route or link failure.
The loss of the "PHR" objects is especially problematic for the
reservation-based "PHR" concept, see e.g., [RODA], since the dropped
signalling messages might have reserved resources in some
NF(interior) nodes in the communication path that will now not be
used. This does not present a problem for the measurement-based
"PHR" concept, see e.g., [RIMA], since there are no reservation
states. The "PHR" objects that need to be sent reliable are:
PHR_Resource_Request
PHR_Refresh_Update
The reliable delivery of the "PHR_Refresh_Update" PHR object is
provided by using the CSTP Reliable Delivery of Signaling Messages
functionality for the CSTP REFRESH message.
The reliable delivery of the "PHR_Resource_Request" object is
provided by using the functionality provided by the ALSP "PDR"
functionality. When the ALSP "PDR" functionality sends the
"PHR_Resource_Request" object towards the NF(egress) node it starts a
timer. If the reply, e.g., "PDR_Reservation_Report" object, does not
arrive in a predefined time it assumes that the
"PHR_Resource_Request" object is lost.
7.2.2. Severe Congestion Handling operation
Severe congestion can be detected by any NF(interior) node by using
different methods. Moreover, the severe congestion situation can be
notified by any NF(interior) node to NF(egress) nodes by using three
approaches, i.e., "Greedy Marking", "Proportional Marking" and "PHR
message marking". The "PHR message marking" can only be applied on
the reservation-based "PHR" concept, while the other two methods can
be applied on both "PHR" concept types.
In this section the "Proportional Marking" severe congestion
notification methods is used.
Westberg, et al. Expires April 2003 [Page 59]
Internet Draft Proposal for RSVPv2 October 2002
7.2.2.1. Proportional marking
Using this severe congestion notification method, after detecting the
severe congestion situation, the NF(interior) node will notify the
NF(egress) node by using remarking of user data packets that pass
through the node (see Figure 11). Proportionally to the detected
overload the NF(interior) node will remark a number of user data
packets which are passing through a severe congested interior node
and are associated with a certain traffic class, e.g., DSCP, into a
domain specific DSCP.
When the marked packets arrive at the NF(egress) node, the NF(egress)
node will generate a "PDR_Congestion_Report" object and send it to
the NF(ingress) node containing the over-allocation volume of the
flow in question, e.g., a blocking probability. The
"PDR_Congestion_Report" PDR object should be encapsulated and
transported by the CSTP INFO message as a NACK SAPUinfo. For each
flow ID, the ALSP PDR functionality at the NF(egress) node will count
the number of marked bytes (# marked bytes) and the number of
unmarked bytes (#unmarked bytes).
Based on this information the ALSP PDR functionality at the
NF(egress) node will have to calculate the blocking estimation of
data. The NF(egress) node will actually calculate the blocking
probability (Pdrop), which will be used by an NF(ingress) node to
block this particular flow.
The blocking probability is calculated as the ratio between the
dropped bytes and the maximum number of bytes that can be supported
by the interior node:
Pdrop = (# marked bytes)/(# marked bytes + # unmarked bytes)
This blocking probability will be included in the
"PDR_Congestion_Report" object that will be sent to the NF(ingress).
The ALSP PDR functionality of the NF(ingress) node after receiving
the PDR_Congestion_Report object and based on the Pdrop blocking
probability, and depending on the used policy, might terminate the
flow, i.e., for a higher blocking probability there is a higher
chance that the flow is terminated.
If a flow needs to be terminated, then for this flow, the ingress
node will generate a "PHR_Release_Request" object that will be sent
by a CSTP TEAR message. The ALSP "e2e service" functionality will
Westberg, et al. Expires April 2003 [Page 60]
Internet Draft Proposal for RSVPv2 October 2002
create a PathError SAPU and it will be sent towards the NI(sender) in
a CSTP EVENT message.
NF (ingress) NF (interior) NF (interior) NF (egress)
CSTP stateful CSTP stateless CSTP stateless CSTP stateful
(sent)
user|(sent) user data | | |
data| | | |
---->|------------------>| (sent) user data | user data |
| |------------------->S(# marked bytes) |
| | S------------------->|
| | S(# unmarked bytes) |
| | S------------------->|
| |INFO(NACK SAPUid, SAPUinfo): |
| PDR_Congestion_Report ("S" marked + Pdrop) |
|<------------------|--------------------|--------------------|
Terminate | | |
flow?| | | |
Yes TEAR(Path SAPUid, LocalSAPU): | |
|PHR_Release_Request| | |
|PDR_RelReq |Tear(Path SAPUid, LocalSAPU): |
|------------------>|PHR_Release_Request |
| |PDR_RelReq TEAR(Path SAPUid, LocalSAPU):
| |------------------->|PHR_Release_Request |
| | |PDR_RelReq |
| | |------------------->|
| | | Tear(Path SAPUid)
| | | |-->
EVENT(PathErr SAPUid, SAPU) | |
<----| | | |
Figure 11: Intra-domain Severe Congestion handling Operation:
with proportional marking
(PDR_RelReq*) - represents the PDR_Release_Request object. This object is
processed only by the NF(ingress) and NF(egress) nodes.
7.3. Example of Adaptation to load sharing operation
This procedure has to be based on the solutions provided by the CSTP
protocol level on this issue. These CSTP protocol level solutions are
not yet defined. Therefore, this procedure will be specified in a
future version of this draft.
Westberg, et al. Expires April 2003 [Page 61]
Internet Draft Proposal for RSVPv2 October 2002
7.4. Normal operation for bi-directional reservation
There are situations where for example, the intra-domain signaling is
used for edge-to-edge signaling where the NI(sender) coincides with
the NF(ingress) and the NR(receiver) coincides with the NF(egress).
In this situation the intra-domain signaling could support in
addition to the unidirectional reservations also bi-directional
reservations. << To be done >>
8. Appendix 1 - Proposed modifications on the CSTP protocol
This section describes a possible manner of enhancing the CSTP
protocol level described in [BrLi01] such that it can be used in
combination with the RSVPv2 ALSP. Note that these proposed CSTP
modifications should be seen as an example and should not preclude
other ways of achieving the interaction between the CSTP protocol
level and the RSVPv2 ALSP level. In the CSTP level used in the
RSVPv2 ALSP the CSTP states do not have to be created in all CSTP
aware nodes.
In particular, the intra-domain signaling procedures use nodes such
as the NF(interior) nodes, that are not creating and maintaining such
CSTP states. These nodes are called CSTP stateless nodes. The nodes
that are creating and maintaining such CSTP states are called CSTP
statefull nodes. The consequence of this difference is that the
information that has to be carried by some CSTP messages and the
ALSP/CSTP interface has to be modified. Due to the use of the CSTP
stateless nodes, all or a subset of the CSTP messages might need to
be processed by the ALSP that is running on CSTP stateless nodes.
Note that these modifications should be optional and are depending on
the used ALSPs. Such CSTP messages are e.g., NEW, MOD, REFRESH and
TEAR messages. There migh be ALSPs that will not require from CSTP
stateless nodes to store and maintain the SAPUid information and the
only information that might be used by these ALSP's is the LocalSAPU
information. This applies to the RMD ALSP, where the CSTP stateless
nodes will only use the LocalSAPU information and it will not store
the SAPUid information.
The CSTP messages that should be used by the RMD ALSP in the CSTP
stateless nodes are the NEW, MOD, REFRESH and TEAR messages.
Westberg, et al. Expires April 2003 [Page 62]
Internet Draft Proposal for RSVPv2 October 2002
8.1. Modified CSTP messages
The INFO message that is used for inter-domain and intra-domain
signaling to carry a SAPU without reliable delivery and refreshing
will have to be modified in order to be able to carry a SAPUid and a
SAPUinfo. The SAPUinfo parameter is used to report information
related to how a SAPU has been processed along the path. Note that
the SAPUinfo is associated to a SAPUid and a SAPU, which includes
reporting information related to the SAPU that is identified by the
SAPUid. Note however, that SAPUinfo is used optionally. The format
is given below:
xSig(INFO, h-src, SAPUid, SAPU, SAPUinfo)
The REFRESH and TEAR CSTP messages that are used for intra-domain
signaling, compared to the ones specified in [BrLi01], have to be
modified since they will have to carry the LocalSAPU information.
Please note that this modification should be optional and should
depend on the ALSP.
The RSVPv2 ALSP (compared to the CSTP specification described in
[BrLi01]) requires that the format of the CSTP REFRESH message, used
for intra-domain signaling, has to be changed in the following way:
current: xSig(REFRESH, h-src, SAPUid, R)
proposed: xSig(REFRESH, h-src, SAPUid, R, LocalSAPU)
Note that this modification should be optional and is depending on
the used ALSP.
The RSVPv2 ALSP (compared to the CSTP specification described in
[BrLi01]) requires that the format of the format of the CSTP TEAR
message, used for intra-domain signaling, has to optionally include
the LocalSAPU object in the following way:
current: xSig(TEAR, h-src, SAPUid)
proposed: xSig(TEAR, h-src, SAPUid, LocalSAPU)
The RSVPv2 ALSP (compared to the CSTP specification described in
[BrLi01]) requires that the format of the format of the CSTP NEW
message, used for intra-domain signaling, has to optionally include
the LocalSAPU object in the following way:
Westberg, et al. Expires April 2003 [Page 63]
Internet Draft Proposal for RSVPv2 October 2002
current: xSig(NEW, h-src, SAPUid, SAPU, R)
proposed: xSig(NEW, h-src, SAPUid, SAPU, R, LocalSAPU)
The RSVPv2 ALSP (compared to the CSTP specification described in
[BrLi01]) requires that the format of the format of the CSTP MOD
message, used for intra-domain signaling, has to optionally include
the LocalSAPU object in the following way:
current: xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R)
proposed: xSig(MOD, h-src, SAPUid, SAPU, old-SAPUid, R, LocalSAPU)
Note that these modifications should be optional and are depending on
the used ALSP.
8.2. ALSP/CSTP interface
The ALSP/CSTP interface is dependend on the applied ALSP. The exact
specification of the ALSP/CSTP interface is currently an open issue.
8.3. Adaptation to load sharing operation
CSTP protocol solutions for adapation to load sharing are not yet
defined. Therefore, this is an open issue on the CSTP protocol
specification.
9. Appendix 2 - Examples of PHR and PDR object specifications
This appendix provides examples of how PHR and PDR objects could be
specified.
9.1. PHR objects
RSVPv2 should support both IP versions, i.e., IPv4 and IPv6. The
format of the PHR object that is based on both IPv4 and IPv6 versions
is depicted in Figure 12. On top of the PHR specific information of
the PHR object, the three (standard) RSVPv1 object fields are used,
i.e., Length, Class-Num and C-type.
Westberg, et al. Expires April 2003 [Page 64]
Internet Draft Proposal for RSVPv2 October 2002
0 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length(bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Unused |P-LEN| P-ID |S|M| C |T|Unused|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Resources | Delta T | Shared % |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 12: PHR object format based on IPv4 or IPv6
Length
(in octets): 16-bit field containing the total object length in
octets. It must always be a multiple of 4 and at least
4 octets.
Class-Num: 8-bit field identifying the object class. Each object
class has a name.
C-Type: 8-bit field identifying the object type, unique within
Class-Num. In this case a C-Type ID should be assigned
to the the PHR object.
P-LEN 3-bit field. This specifies the length in
(PHR length) octets of the specific PHR information data,
without including the "Variable length" field.
The value 0 specifies that this IP option
field contains only data in the "Variable length"
field.
This data MUST begin on the next 32-bit word
boundary after the P-LEN field (after the first
"unused" field). In this case, the sender MUST
set the "S", "M", "C", and "unused" fields to 0.
The P-ID MUST have the value 1.
If a receiver receives a packet with a P-LEN value
of 0, it MUST ignore the values in the "S", "M",
"C", and "unused" fields.
P-ID (PHR type) 4-bit field. This specifies the PHR type.
For the RODA PHR, the value MUST be 1.
Westberg, et al. Expires April 2003 [Page 65]
Internet Draft Proposal for RSVPv2 October 2002
S 1-bit field. The sender MUST set the "S"
(Severe field to 0. This field is set to 1
Congestion) by an NF(interior) or NF(edge) node when a severe
congestion situation occurs.
M 1-bit field. The sender MUST set the "M"
(Marked) field to 0. This field is set to 1 by an
NF(interior) or NF(edge) node when the node cannot
satisfy the "Requested Resources" value.
C 3-bit field. This field specifies the
(Object type) type of the PHR object.
C Description
-------------------------------
0 Reserved
1 "PHR_Resource_Request"
2 "PHR_Refresh_Update"
3 "PHR_Release_Request"
4-7 Unused
"PHR_Resource_Request": initiate or update the
traffic class reservation state on all nodes
located on the communication path between the
NF(ingress) and NF(egress) nodes according to an
external SAPU Path request.
"PHR_Refresh_Update": refresh the traffic class
reservation soft state on all nodes located on
the communication path between the NF(ingress) and
NF(egress) nodes according to a resource reservation
request that was successfully processed by the
ALSP PHR functionality during a previous refresh
period.
"PHR_Release_Request": explicitly release, by
subtraction, the reserved resources for a particular
flow from a traffic class reservation state.
T 1-bit field. The NF(ingress) node MUST set
(TTL active) the "T" field to 0. This field MAY be set to "1"
by a node when the node will have to include the
TTL value from the header of the IP packet into
the "PDR_TTL" field of the PDR object.
Westberg, et al. Expires April 2003 [Page 66]
Internet Draft Proposal for RSVPv2 October 2002
U A 3-bit field that is currently unused. Reserved for
future PHR object extensions.
Requested 16-bit field. This field specifies the requested
Resources number of units of resources to be reserved by
a node. The unit is not necessarily a simple
bandwidth value. It may be defined in terms of
any resource unit (e.g., effective bandwidth) to
support statistical multiplexing at message level.
Delta T 8 bit field. The value of this field MAY be set
by any NF(ingress) node into (only)
"PHR_Resource_Release" objects. It specifies a
percentage that represents the ratio between a
time lag, say T_lag, and the length of the refresh
period, say T_period. Where, T_lag represents
the difference between the departure time of the
previous sent "PHR_Refresh_Update" object and
the departure time of the "PHR_Resource_Release"
object. T_period represents the length of the
refresh period. This information MAY be used by
any node during an explicit release procedure.
Shared % 8 bit field. This value MAY be used to specify if a
(Shared load sharing situation occurred on a communication path
percentage) or not. The ingress node sets this value to 100. If
load sharing occurred in a node then the node
will divide the shared percentage value to the
number of equal cost paths.
Variable this field is currently unused. Reserved for
length future PHR object extensions.
9.2. PDR objects
The format of the PDR object that is based on the IPv4 version is
depicted in Figure 13. On top of the PDR specific information of the
PDR object, the three (standard) RSVPv1 object fields are used, i.e.,
Length, Class-Num and C-type.
Westberg, et al. Expires April 2003 [Page 67]
Internet Draft Proposal for RSVPv2 October 2002
0 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length(bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDRID |MsgType|S|M|B| Unused |F-Type |EP-Type| PDR-TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Requested Resources | Shared % |Dropping rate %|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Ingress (Egress) Address (IPv4) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Flow-ID (length varies) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Variable length field |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: PDR object format based on IPv4
Length
(in octets): 16-bit field containing the total object length in
octets. It must always be a multiple of 4 and at least
4 octets.
Class-Num: 8-bit field identifying the object class. Each object
class has a name.
C-Type: 8-bit field identifying the object type, unique within
Class-Num. In this case a C-Type ID should be assigned
to the the PHR object.
PDRID: 4-bit field identifying the ID of the PDR object. It is
zero for an experimental protocol.
MsgType: 4-bit field identifying the type of PDR object. See
below for a table of recognized values.
MsgType Description Sent with PHR object
-----------------------------------------------------
0 reserved
1 PDR_Reservation_Request PHR_Resource_Request
2 PDR_Refresh_Request PHR_Refresh_Update
3 PDR_Release_Request PHR_Resource_Release
Westberg, et al. Expires April 2003 [Page 68]
Internet Draft Proposal for RSVPv2 October 2002
4 PDR_Reservation_Report
5 PDR_Refresh_Report
6 PDR_Release_Report
7 PDR_Request_Info PHR_Resource_Request OR
PHR_Refresh_Update OR
PHR_Resource_Release OR
PHR_Modification_Request
8 PDR_Congestion_Report
9 PDR_Modification_Request
10 PDR_Modification_Report
11-16 unused
"PDR_Reservation_Request": generated by the NF(ingress)
node in order to initiate or update the ALSP PDR state
in the NF(egress) node
"PDR_Refresh_Request": generated by the NF(ingress) node
and sent to the NF(egress) node to refresh, in case
needed, the ALSP PDR states located in the NF(egress)
node
"PDR_Modification_Request": generated and sent by the
NF(ingress) node to the NF(egress) node to modify the
PDR states located in the NF(egress) node
"PDR_Release_Request": generated and sent by the
NF(ingress) node to the NF(egress) node to release the
flows explicitly
"PDR_Request_Info": an object that can be used as a
common "PDR_Reservation_Request", "PDR_Refresh_Request",
"PDR_Release_Request" and "PDR_Modification_Request"
"PDR_Reservation_Report": generated and sent by the
NF(egress) node to the NF(ingress) node to report that
a "PHR_Resource_Request" PHR object and a
"PDR_Reservation_Request" PDR object has been received
and that the request has been admitted or rejected
"PDR_Refresh_Report": generated and sent by the NF(egress)
node in case needed, to the NF(ingress) node to report that
a "PHR_Refresh_Update" PHR object and a
"PDR_Refresh_Request" PDR object have been received and have
been processed
Westberg, et al. Expires April 2003 [Page 69]
Internet Draft Proposal for RSVPv2 October 2002
"PDR_Congestion_Report": generated and sent by the
NF(egress) node to the NF(ingress) node and used for severe
congestion notification. They are only used when either the
"greedy marking" or "proportional marking" severe
congestion notification procedures are applied.
"PDR_Modification_Report": generated and sent by the
NF(egress) node to NF(ingress) node to report that the
combination of either the "PHR_Resource_Request" PHR
object and the "PDR_Modification_Request" PDR object or
the "PHR_Release_Request" PHR object and the
"PDR_Modification_Request" have been received and
processed
PDRID: 4-bit field. ID of the PDR object. It is
zero for an experimental protocol.
S (Severe : 1-bit field. specifies if a severe congestion
Congestion) situation occured. It can also carry the "S" flag of
the "PHR_Resource_Request" or "PHR_Refresh_Update"
PHR objects.
This flag only applies to "PDR_Reservation_Report",
"PDR_Refresh_Report", "PDR_Congestion_Report" and
"PDR_Modification_Report" objects.
M (Marked): 1-bit field. Carries the "M" value of the
"PHR_Resource_Request" or "PHR_Refresh_Update" PHR
objects.
This flag only applies to "PDR_Reservation_Report",
"PDR_Refresh_Report", "PDR_Congestion_Report" and
"PDR_Modification_Report" objects.
B : 1-bit field. secifyies that the "PHR" objects should be
(Bi-directional used for bi-directional reservations in intra-domain
reservation) signaling. Note that when the inter-domain signaling
procedures are applied for bi-directional reservations
it does not mean that the associated intra-domain
signaling procedures should also use bi-directional
reservations.
F-Type: 4-bit field. The Flow-ID type identifier. Defined by the
(Flow PDR protocol. It informs the NF(ingress) and NF(egress)
Type) nodes what kind of data is contained in the Flow-ID and
its length. Every NF(edge) node should be configured to
process the F-Types.
Westberg, et al. Expires April 2003 [Page 70]
Internet Draft Proposal for RSVPv2 October 2002
EP-Type: 4-bit field. Identifies the used external protocol.
(External Only usefull when the intra-domain signaling procedures
Protocol are used in combination with non-RSVPv2 inter-domain
Type) signaling procedures. It informs the NF(ingress) and
NF(egress) nodes what type of external protocol (EP)
data is contained in the Variable length field. Every
edge node MUST be configured to process the EP-Type. If
this field is 0000 then the Variable length field can be
used for other purposes, i.e., future specifications.
PDR-TTL: 8-bit field. The TTL value introduced by a node that
could not admit or process a "PHR_Resource_Request"
object.
Reverse : 16 bits. This field only applies when the "B" flag is
Requested set to "1".
Resources It specifies the requested number of
units of resources that have to be reserved by a node
in the reverse direction when the intra-domain signaling
procedures require a bi-directional reservation procedure.
The unit is not necessarily a simple bandwidth value: it
may be defined in terms of any resource unit (e.g.,
effective bandwidth) to support statistical multiplexing
at packet level.
Shared % : 8-bit field. This value specifies if a load sharing
(Shared situation occurred on a communication path or not. The
percentage): NF(ingress) node sets this value to 100. If load sharing
occurred in a node then the node will have to divide the
shared percentage value to the number of equal cost paths.
Dropping : 8-bit field: This value specifies the dropping rate
rate %: percentage and is used during severe congestion. The ingress
(Dropping rate node will use this rate as a blocking probability, to
percentage) terminate the particular flow.
Ingress : 32-bit field. For the case that the PDR object is sent by
(Egress) NF(ingress) to NF(egress) this field represents the
Address NF(ingress) IP address. In the other direction this field
represents the NF(egress) IP address.
Flow-ID: Length depends on F-Type. It specifyies the flow ID used
by the PDR state.
Variable : variable length field. It can be used either for
Westberg, et al. Expires April 2003 [Page 71]
Internet Draft Proposal for RSVPv2 October 2002
length including external protocol data or reserved for
field future PDR object extensions.
The format of the PDR object that is based on the IPv6 version is
depicted in Figure 14. Note that the only difference between the PDR
object format based on IPv4 and IPv6 versions is the Ingress (Egress)
Address field, i.e., in IPv6 is this field 128 bits long, while in
IPv4 is this field 32 bits long.
0 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length(bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PDRID |MsgType|S|M|B| Unused |F-Type |EP-Type| PDR-TTL |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reverse Requested Resources | Shared % |Dropping rate %|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Ingress (Egress) Address (IPv6) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Flow-ID (length varies) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Variable length field |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 14: PDR object format based on IPv6
10. References
[BrLi01] Braden, R., Lindell, B., "A Two-Level Architecture for
Internet Signaling", Internet Draft (work in progress),
2001.
[Bru02] Brunner, M., "Requirements for QoS Signaling Protocols",
draft-ietf-nsis-req-04.txt (work in progress), August 2002
[CsTa02] Csaszar, A., Takacs, A., Szabo, R., Rexhepi, V.,
Westberg, et al. Expires April 2003 [Page 72]
Internet Draft Proposal for RSVPv2 October 2002
Karagiannis, G., "Severe Congestion Handling
with Resource Management in Diffserv On Demand",
submitted to Networking 2002, May 19-24 2002,
Pisa - ITALY.
[Hanc02] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J.,
Van den Bosch, S., "Next Steps in Signaling: Framework",
Internet Draft, 2002, Work in progress.
[RFC1633] Braden, R., Clark, D., Shenker, S., "Integrated
Services in the Internet Architecture: an Overview",
IETF RFC 1633, 1994.
[RFC2002] Perkins, C., Editor, "IP Mobility Support", RFC 2002,
October 1996.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, A.,
Jamin, S., "Resource ReSerVation Protocol (RSVP)
-- Version 1 Functional Specification", IETF RFC
2205, 1997.
[RFC2747] F. Baker, B. Lindell, M.Talwar. "RSVP Cryptographic
Authentication", IETF RFC, January 2000.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Zh., Weiss, W., "An Architecture for Differentiated
Services", IETF RFC 2475, 1998.
[RFC3175] Baker, F., Iturralde, C. Le Faucher, F., Davie, B.,
"Aggregation of RSVP for IPv4 and IPv6 Reservations",
IETF RFC 3175, 2001.
[RIMA] Westberg, L., Heijenk, G., Karagiannis, G., Oosthoek, S.,
Partain, D., Rexhepi, V., Szabo, R., Wallentin, P.,
el Allali, H.,"Resource Management in Diffserv
Measurement-based Admission Control PHR", Internet draft
Work in progress, 2002.
[RODA] Westberg, L., Karagiannis, G., Kogel, de M., Partain, D.,
Oosthoek, S., Jacobsson, M., Rexhepi, V., "Resource Management
in Diffserv On DemAnd (RODA) PHR", Internet Draft,
Work in progress.
[RMD-frame] Westberg, L., Jacobsson, M., Karagiannis, G., Rexhepi, V.,
Partain, D., Oosthoek, S., Szabo, R., Wallentin, P.,
Westberg, et al. Expires April 2003 [Page 73]
Internet Draft Proposal for RSVPv2 October 2002
"Resource Management in Diffserv
Framework", Internet draft, Work in progress.
[NSIS-ML1] Braden, B., "Re: What's in the charter of NSIS",
http://www1.ietf.org/mail-archive/working-groups/
nsis/current/msg01368.html
[PAN-SSP] Pan, P., Murphy, J., "A Network Architecture
for Simplified Signaling Protocol", IETF Internet
Draft, draft-pan-signal-req-00.txt, Work in Progress,
May 2002.
[RANISSUE] Partain, D., Karagiannis, G., Wallentin, P.,
Westberg, L., "", Internet Draft (currently expired),
draft-westberg-rmd-cellular-issues-00.txt, Work
in Progress, June 2001. Available at
http://standards.ericsson.net/rmd/drafts/
draft-westberg-rmd-cellular-issues-00.txt
Westberg, et al. Expires April 2003 [Page 74]
Internet Draft Proposal for RSVPv2 October 2002
11. Authors' Addresses
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@era.ericsson.se
Georgios Karagiannis
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645 7500 AP Enschede
The Netherlands
EMail: Georgios.Karagiannis@eln.ericsson.se
David Partain
Ericsson Radio Systems AB
P.O. Box 1248
SE-581 12 Linkoping
Sweden
EMail: David.Partain@ericsson.com
Vlora Rexhepi
Ericsson EuroLab Netherlands B.V.
Institutenweg 25
P.O.Box 645 7500 AP Enschede
The Netherlands
EMail: Vlora.Rexhepi@eln.ericsson.se
Westberg, et al. Expires April 2003 [Page 75]
| PAFTECH AB 2003-2026 | 2026-04-23 09:01:12 |