One document matched: draft-westberg-proposal-for-rsvpv2-nslp-00.txt
Internet Draft Proposal for RSVPv2-NSLP April 2003
Internet Engineering Task Force L. Westberg
INTERNET-DRAFT A. Bader
Expires October 2003 D. Partain
V. Rexhepi
Ericsson
G. Karagiannis
University of Twente
April 2003
A Proposal for RSVPv2-NSLP
draft-westberg-proposal-for-rsvpv2-nslp-00.txt
Document Version: $Revision: 2.1 $
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
Westberg, et al. Expires October 2003 [Page 1]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Copyright (C) The Internet Society (2002). All Rights Reserved.
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 demand for technologies offering services with different
levels of quality of service to their customers. This memo seeks to
initiate a dialog about the design of a new version of RSVPv1, called
RSVPv2, that meet the requirements formulated by IETF NSIS working
group. It also outlines the motivation for using RSVP2 as "next step
in signaling".
The RSVPv2 framework uses the layer-split architecture separating
signaling application and transport functions. This concept was
adopted by NSIS WG and the two layers are called NSLP NSIS Signaling
Layer Protocol (NSLP) and NSIS Transport Layer Protocol (NTLP). This
draft provides design guidelines and specifications for the
development of the RSVPv2 NSLP part.
RSVP2-NSLP offers increased modularity and contains less mandatory
objects compared to RSVPv1, which allow lightweight implementation
and flexible application. The new protocol is extended with PHR and
PDR objects that makes it possible to use the protocol in different
part of multi-domain networks and use the protocol in DiffServ
environment.
Westberg, et al. Expires October 2003 [Page 2]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Table of Contents
1 Introduction ................................................. 5
1.1 Definitions/Terminology .................................... 6
2 Motivation for RSVPv2 ........................................ 10
2.1 Limitation of RSVPv1 design ................................ 11
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 .......... 13
2.2 Different Network Signalling Requirements/Needs and RSVP
........................................................... 13
3 Design Goals and General Features for RSVPv2-NSLP ............ 14
3.1 Increased Layer Modularity and Extendibility ............... 14
3.2 Increased Object Modularity ................................ 15
3.3 Hierarchical Object Structure .............................. 15
3.4 Global and Local Objects ................................... 16
3.5 Local information exchange ................................. 16
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 ....................................... 17
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 .............................................. 18
3.14 End-to-edge ............................................... 19
4 Overview of the RSVPv2-NSLP Framework ........................ 19
4.1 RSVPv2 NSLP protocol features provided by the intra-do-
main level
...................................................... 22
4.1.1 PDR protocol part functions .............................. 23
4.1.2 PHR protocol part functions .............................. 23
4.2 RSVPv2 NSLP protocol features provided by the e2e service
level ..................................................... 25
5 RSVPv2 NSLP specification .................................... 26
5.1 RSVPv2 NSLP Object Classes structure ....................... 26
5.1.1 RSVPv2 NSLP Message Structure ............................ 29
5.2 RSVPv2-NSLP Objects in RSVPv2-NSLP Object_Classes .......... 29
5.2.1 Example of mapping of RSVPv1 [RFC2205] objects in ........ 30
5.2.2 PDR/PHR objects .......................................... 33
5.3 RSVPv2-NSLP functionality on nodes used for inter-domain
signaling ................................................. 33
5.3.1 NI (NSIS Initiator) functionality ........................ 33
5.3.1.1 Unidirectional functionality ........................... 33
5.3.1.2 Bidirectional functionality ............................ 35
Westberg, et al. Expires October 2003 [Page 3]
Internet Draft Proposal for RSVPv2-NSLP April 2003
5.3.2 NF (NSIS Forwarder) functionality ........................ 36
5.3.2.1 Unidirectional functionality ........................... 36
5.3.2.2 Bidirectional functionality ............................ 38
5.3.3 NR (NSIS Responder) functionality ........................ 39
5.3.3.1 Bidirectional functionality ............................ 40
5.4 RSVPv2-NSLP functionality on nodes used for intra-domain
signaling ................................................. 41
5.4.1 NI (NSIS Initiator) functionality ........................ 41
5.4.1.1 Unidirectional functionality ........................... 42
5.4.1.2 Bidirectional functionality ............................ 42
5.4.2 Functionality of NF (NSIS Forwarder) located outside
NSIS intra-domain ......................................... 42
5.4.2.1 Unidirectional functionality ........................... 42
5.4.2.2 Bidirectional functionality ............................ 42
5.4.3 NF (ingress) functionality ............................... 42
5.4.3.1 Unidirectional functionality ........................... 43
5.4.3.2 Bidirectional functionality ............................ 48
5.4.4 NF (interior) functionality .............................. 49
5.4.4.1 Unidirectional functionality ........................... 49
5.4.4.2 Bidirectional functionality ............................ 51
5.4.5 NF (egress) functionality ................................ 51
5.4.5.1 Unidirectional functionality ........................... 52
5.4.5.2 Bidirectional functionality ............................ 55
5.4.6 NR (NSIS Responder) functionality ........................ 56
5.4.6.1 Unidirectional functionality ........................... 56
5.4.6.2 Bidirectional functionality ............................ 56
6 Example of RSVPv2-NSLP Inter-domain signaling procedures ..... 57
6.1 Normal operation for uni-directional reservation ........... 57
6.2 Normal operation for bi-directional reservation ............ 62
7 Example of RSVPv2-NSLP Intra-domain signaling procedures ..... 65
7.1 Normal operation for uni-directional reservation ........... 65
7.2 Example of Fault Handling Operation ........................ 80
7.2.1 Loss of NTLP signalling messages ......................... 81
7.2.2 Severe Congestion Handling operation ..................... 81
7.2.2.1 Proportional marking ................................... 82
7.3 Example of Adaptation to load sharing operation ............ 84
7.4 Normal operation for bi-directional reservation ............ 84
8 Appendix - Examples of PHR and PDR object specifications
........................................................... 90
8.1 PHR objects ................................................ 90
8.2 PDR objects ................................................ 93
9 References ................................................... 98
10 Authors' Addresses .......................................... 101
Westberg, et al. Expires October 2003 [Page 4]
Internet Draft Proposal for RSVPv2-NSLP April 2003
1. Introduction
A number of different QoS solutions have been developed by the IETF,
amongst them IntServ and its signaling protocol, RSVPv1, defined in
[RFC2205]. RSVPv1 [RFC2205] is a resource reservation signaling
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 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 the RSVPv2 framework would
be to rectify the issues that have been identified with RSVPv1 and
provide an evolutionary path forward.
The RSVPv2 framework uses the concept introduced in [BrLi01] that
splits signaling protocol into two layers:
(1) a common lower level protocol that performs transport-layer
and soft-state functions. This common lower level is called
CSTP ("Common Signaling Transport Protocol").
(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
ULSPs ("User Layer Signaling Protocols).
The CSTP together with the set of ULSPs will implement the Internet
Signaling Protocol Suite (ISPS). The NSIS working group adopted this
concept denoting the two protocols as NSIS Transport Layer Protocol
(NTLP) and NSIS Signaling Layer Protocol (NSLP), respectively
[Hanc03].
This memo outlines the motivation for using RSVPv2-NSLP as NSIS
Signaling Layer Protocol. It provides a design guideline and
specification for RSVPv2-NSLP. Note that in order to be able to
communicate with NTLP, RSVPv2-NSLP needs to use an NSLP Identifier
that has to be assigned by the NSIS WG. RSVPv2-NSLP specified in this
draft is able to interwork with NTLP specified in [WeKa03].
Westberg, et al. Expires October 2003 [Page 5]
Internet Draft Proposal for RSVPv2-NSLP April 2003
1.1. Definitions/Terminology
Interdomain traffic:
Traffic that passes from one NSIS domain to
another ([identical to [Hanc03]).
Intra-domain NSIS signaling is where the NSIS signaling messages are
originated, processed and terminated within the same NSIS domain.
NSIS Domain (ND) (identical to [Hanc03]):
Administrative domain where an NSIS protocol
signals for a resource or set of resources.
NSIS Entity (NE) (identical to [Hanc03]):
the function within a node which implements an
NSIS protocol. In the case of path-coupled signaling, the
NE will always be on the data path.
NSIS Forwarder (NF) (identical to [Hanc03]):
NSIS Entity between a NI and NR which may
interact with local resource management function (RMF). It also
propagates NSIS signaling further through the network.
NF Edge nodes:
NF Nodes that are located at the boundary of an administrative
domain, e.g., Diffserv. This node is a NTLP stateful node.
NF Interior node:
All the nodes that are part of an administrative domain, e.g.,
Diffserv, and are not NF edge nodes. An interior node can be
either a NTLP stateful node or a NTLP stateless node.
NF Ingress node:
An NF edge node that handles the traffic as it enters the
domain. This node is a NTLP stateful node.
NF Egress node:
Westberg, et al. Expires October 2003 [Page 6]
Internet Draft Proposal for RSVPv2-NSLP April 2003
An NF edge node that handles the traffic as it leaves the
domain. This node is a NTLP stateful node.
NSIS Initiator (NI) (identical to [Hanc03]):
NSIS Entity that initiates NSIS signaling for a
network resource.
NSIS Responder (NR) (identical to [Hanc03]):
NSIS Entity that terminates NSIS signaling and
can optionally interact with applications as well.
NSIS Signaling Layer Protocol (NSLP) (identical to [Hanc03]):
generic term for an NSIS protocol component that supports a specific
signaling application.
NSIS Transport Layer Protocol (NTLP) (identical to [Hanc03]):
placeholder name for the NSIS protocol component that will support
lower layer (signaling application independent) functions.
NTLP aware node:
a node that implements and supports the NTLP protocol.
NTLP stateful node:
a NTLP aware node that maintains a NTLP transport layer state.
NTLP stateless node:
a NTLP aware node that does not maintain a NTLP transport layer
state.
NE NTLP stateful
NE entity that is NTLP stateful.
NE NTLP stateless
NE entity that is NTLP stateless.
NF NTLP stateful
Westberg, et al. Expires October 2003 [Page 7]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF entity that is NTLP stateful.
NF NTLP stateless
NF entity that is NTLP stateless.
Resource Management Function (RMF) (identical to [Hanc03]):
an abstract concept,
representing the management of resources in a domain or a node.
End Host:
QoS-aware end terminal, either fixed or mobile, i.e. running
QoS-aware applications. This node is a NTLP stateful node and it
can be considered as a NI or a NR.
RSVPv2 NSLP:
an NSLP type that can be a part of the RSVPv2 framework.
NSLP intra-domain:
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.
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
differentiated services documents; usually used in reference
to a node or device.
Interdomain traffic - Traffic that passes from one NSIS domain to
another
Intra-domain NSIS signaling is where the NSIS signaling messages are
originated, processed and terminated within the same NSIS domain.
Westberg, et al. Expires October 2003 [Page 8]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 [Hanc03]). Note that NF can be also
considered as a RSVPv2 forwarder.
NSIS Initiator (NI) - NSIS Entity that initiates NSIS signaling for a
network resource (identical to [Hanc03]). 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 [Hanc03]). Note that NR can be also considered as a
RSVPv2 responder.
Path-coupled signaling - a mode of signaling where the signaling
messages follow a path that is tied to the data messages
(see [Hanc03]).
Path-decoupled signaling - signaling with independent data and
signaling paths (see [Hanc03]).
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
Westberg, et al. Expires October 2003 [Page 9]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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.
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
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 signaling protocol, RSVPv1. As such, there
must be a clear need for the evolution of the QoS signaling part of
RSVPv1. This section tries to provide that motivation.
We believe that this work can be accomplished by examining the design
constraints placed upon the development of RSVPv1 and eliminate these
constraints in RSVPv2 design.
Westberg, et al. Expires October 2003 [Page 10]
Internet Draft Proposal for RSVPv2-NSLP April 2003
2.1. Limitation of RSVPv1 design
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.
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.
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
setup 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.
Westberg, et al. Expires October 2003 [Page 11]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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
specification may have 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 signaling 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.
Westberg, et al. Expires October 2003 [Page 12]
Internet Draft Proposal for RSVPv2-NSLP April 2003
2.1.4. Designed for End-host to End-host Communication
RSVPv1 was primarily designed with signaling 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 signaling conversations that
may be needed in different parts of the network. Each of these kinds
of signaling implies a different -- and potentially conflicting --
set of requirements on the signaling protocol. For example, the
signaling requirements for the conversation between the end-host and
the network may indeed need more complexity than RSVPv1 whereas the
signaling needs in a DiffServ-capable access network would require
significantly less.
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
Westberg, et al. Expires October 2003 [Page 13]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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].
3. Design Goals and General Features for RSVPv2-NSLP
This section briefly outlines some of the guiding principles behind
the design of RSVPv2-NSLP. Moreover, the RSVPv2 NSLP general features
are described. These design goals and features are in line with some
of the NSIS requirements described in [Bru03] and [Hanc03].
3.1. Increased Layer Modularity and Extendibility
The essential design goal for RSVPv2 framework is to preserve the
flexibility of RSVPv1 while at the same time further expanding its
modularity. It can be fulfilled by using the NTLP-NSLP layer-split
architecture.
The RSVPv2-NSLP protocol can be considered as an NSLP that will use a
subset of the transport layer functions provided by the NTLP (see for
example [WeKa03]) such as:
* Support of Path-Coupled (Path-Directed) Signaling;
* Soft state support: This feature ensures that a state
will be removed if it is not periodically refreshed or
explicitly removed.
* Adaptation to load sharing. Load sharing allows NF interior
nodes to take advantage of multiple routes to the same
Westberg, et al. Expires October 2003 [Page 14]
Internet Draft Proposal for RSVPv2-NSLP April 2003
destination by sending via some or all of these available
routes. The NTLP protocol level has to adapt to load sharing
once it is used.
* The NTLP signaling protocol should be able to exchange local
information between 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 the object modularity is to increase processing
efficiency of RSVPv2 NTLP 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-NSLP 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.
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
Westberg, et al. Expires October 2003 [Page 15]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 NSLP objects
within RSVPv2 messages for each networking scenario. Each profile
used for a network scenario will have to specify how the objects are
structured into the RSVPv2 NSLP message 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 of the RSVPv2 NSLP message. Objects that will
be processed only in specific routers can be placed later in the
sequence.
3.4. Global and Local Objects
NSLP 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.
3.5. Local information exchange
The signaling protocol MUST be able to exchange local information
between 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.
Westberg, et al. Expires October 2003 [Page 16]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 NSLP 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.
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).
Westberg, et al. Expires October 2003 [Page 17]
Internet Draft Proposal for RSVPv2-NSLP April 2003
3.10. Highest possible network utilization
There are networking environments that require high network
utilization for various reasons, and the signaling protocol SHOULD do
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.
3.11. Uni / bi-directional reservation
Both unidirectional as well as bi-direction reservations SHOULD be
possible. 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 [Hanc03]), the RSVPv2 NSLP protocol is
initiated by an end host and is terminated by another end host. In
this context, RSVPv2 NSLP can be applied as needed within all of the
RSVPv2 NSLP domains between the end hosts. In the end-to-end path,
RSVPv2 NSLP may be used both for intra-domain RSVPv2 NSLP signaling,
as well as for inter-domain signaling.
3.13. Edge-to-edge
In this scenario (see also [Hanc03]) the RSVPv2 NSLP protocol is
initiated by an edge node of a RSVPv2 NSLP domain and is terminated
by another edge node of the same (or possibly different) RSVPv2 NSIS
domain. RSVPv2 NSLP can be applied either within one single RSVPv2
NSLP domain, which is denoted as edge-to-edge in a single domain, or
within a concatenated number of RSVPv2 NSLP 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 NSLP domains,
these concatenated RSVPv2 NSLP domains are considered, in terms of
RSVPv2 NSLP, to be a single, larger RSVPv2 NSLP domain.
Westberg, et al. Expires October 2003 [Page 18]
Internet Draft Proposal for RSVPv2-NSLP April 2003
3.14. End-to-edge
In this scenario (see also [Hanc03]) the RSVPv2 NSLP 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 NSLP domain.
4. Overview of the RSVPv2-NSLP Framework
The RSVPv2 protocol can be considered as an NSLP that will use a
subset of the transport layer functions provided by the NTLP protocol
level (see for example, [WeKa03]). 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 NSLP can consist of one protocol level or it can be separated
into more than one hierarchical levels.
Figure 1 shows the NSIS protocol that consists of one NTLP level and
one NSLP level.
|-----| |-------| |-------| |-------| |-------| |-----|
|NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP |<->| NSLP|
| |<->| |<->| |<->| |<->| |<->| |
| | | | | | | | | | | |
----- ------- ------- ------- ------- -----
|NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP|
| |<->| |<->| |<->| |<->| |<->| |
|-----| |-------| |-------| |-------| |-------| |-----|
NI NF NF NF NF NR
Figure 1: One level used for RSVPv2 NSLP signaling
The NSLP depicted in Figure 1 includes a set of upper-level signaling
functions that are specific to particular signaling applications.
Westberg, et al. Expires October 2003 [Page 19]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Such functions could, for example, be end to end resource reservation
signaling, security, policy, billing, etc.
In Figure 2 the NSIS protocol is shown, which consists of one NTLP
level and two NSLP hierarchical levels. However, the approach is
quite general to more NSLP hierarchical levels: the important issue
is the use of NSLP at more than one level at all.
This type of hierarchical level separation can for example, be
applied for intra-domain signaling in order to maximize the
scalability in an NSIS intra-domain.
The lowest hierarchical level in Figure 2 represents the NTLP level
protocol. Note that in this the NF nodes are usually considered to be
NTLP stateful nodes. This holds also for the NF nodes used at the
boundary of a domain, i.e., the NF edge nodes. However, as described
in [WeKa03], the NF interior nodes of a domain can be considered to
be NF stateful nodes (see Figure 1) or, when processing optimization
is required, the NF interior nodes can be NF stateless nodes (see
Figure 2). The NF stateful nodes are NF NTLP aware nodes that
maintain a NTLP state by using the NTLP soft state principle and are
able to process and modify the application level information (NSLP)
that is transported by the NTLP protocol. The NF NTLP stateless
nodes are NF NTLP aware nodes that do not maintain a NTLP state, but
they are able to process and modify the application level information
(NSLP) that is transported by the NSLP protocol. The RSVPv2 NSLP
framework depicted in Figure 2 is separated in two levels:
* the intra-domain level (located above the NTLP 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 NSLP and NTLP
has to be moved as much as possible away from the interior nodes.
Therefore, the RSVPv2 NTLP 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 NSLP
intra-doamin.
The first resource reservation protocol part type is denoted as Per
Westberg, et al. Expires October 2003 [Page 20]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 NTLP state
and there is no PDR functionality. Note that these NF interior
nodes are NTLP 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
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 2) to "local"
parameters that are useful to the intra-domain scheme.
Note that in the NF edge nodes (NF ingress and NF egress) a
NTLP 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 NSLP and NTLP can be based on an API
(Application Program Interface) and for the time being, is out of
scope of this memo.
As shown in Figure 2, the two NSLP hierarchical levels might be
applied on different NSIS entities.
This architecture for NSIS (e.g., RSVPv2) signaling can be provided
by using:
Westberg, et al. Expires October 2003 [Page 21]
Internet Draft Proposal for RSVPv2-NSLP April 2003
*) a single end-to-end NSIS (e.g., RSVPv2) protocol that supports both
NLSP 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.
|------| |-------| |-------| |------|
| e2e |<--| e2e |<------------------------->| e2e |<->| e2e |
service|<->|service| |service|<->|service
| | |-------| |-------| |------|
| | | | | | | |
| | |-------| |-------| |-------| |-------| | |
| | |PDR/PHR|<->| PHR |<->| PHR |<->|PDR/PHR| | |NSLP
| | | | | | | | | | | | ^
| | |-------| |-------| |-------| |-------| | | |
---------------------------------------------------------------------
| | | | | | | | |
|------| |-------| |-------| |-------| |-------| |------| V
| level|<->| level |<->| level |<->| level |<->| level |<->|level |NTLP
| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->| NTLP |<->|NTLP |
|st.ful| |st.ful | |st.less| |st.less| |st.full| |st.ful|
|------| |-------| |-------| |-------| |-------| |------|
NI NF NF NF NF NR
(edge) (interior) (interior) (edge)
NTLP st.ful : NTLP stateful
NTLP st.less : NTLP stateless
Figure 2: Two levels used for the RSVPv2 NSLP
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 "NTLP level" objects, then the
"PDR/PHR" objects and finally the "e2e service" objects.
4.1. RSVPv2 NSLP protocol features provided by the intra-domain level
The RSVPv2 NSLP 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]).
Westberg, et al. Expires October 2003 [Page 22]
Internet Draft Proposal for RSVPv2-NSLP April 2003
4.1.1. PDR protocol part functions
The RSVPv2 NSLP PHR and PDR protocol parts that implement the RSVPv2
NSLP intra-domain level are listed below.
A PDR protocol part implements all or a subset of the following
functions:
* Admission control and/or resource reservation signaling within
a domain (i.e., on the edge nodes).
* 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 RSVPv2-NSLP 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
* Notification that lost signalling messages (containing PHR and PDR
information) occurred in the communication path from the ingress
to the egress nodes.
4.1.2. PHR protocol part functions
A RSVPv2-NSLP PHR protocol part implements all or a subset of the
following functions:
Westberg, et al. Expires October 2003 [Page 23]
Internet Draft Proposal for RSVPv2-NSLP April 2003
* 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 NTLP soft state principle.
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 traffic 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
Westberg, et al. Expires October 2003 [Page 24]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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.
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
NSLP 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]. Note that in the RMD NSLP 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.
4.2. RSVPv2 NSLP protocol features provided by the e2e service level
The e2e service level protocol features that are used by this NSLP
should satisfy all or a subset of the application signaling
requirements provided in [Bru03]. The detailed description of these
features will be included in the next updated versions of this draft.
Westberg, et al. Expires October 2003 [Page 25]
Internet Draft Proposal for RSVPv2-NSLP April 2003
5. RSVPv2 NSLP specification
RSVPv2 NSLP is considered in this draft to be primarily optimised for
unicast and sender initiated signaling. This section provides a first
step in the RSVPv2 NSLP specification.
5.1. RSVPv2 NSLP Object Classes structure
As described in [WeKa03] the NTLP message format consists of a common
header, followed by a body consisting of a number of variable-length,
typed transport layer "objects". The application layer (NSLP)
"objects" are placed always after the transport layer "objects". Note
that the application layer (NSLP) "objects" are opaque and
transparent to NTLP. The NTLP message format is depicted in Figure 3.
0 1 2 3
+-------------+-------------+-------------+-------------+
| |
+ Common Header +
| |
+-------------+-------------+-------------+-------------+
| |
// (Transport layer objects content) //
| |
+-------------+-------------+-------------+-------------+
| |
// Application layer (RSVPv2 NSLP) objects content) //
| |
+-------------+-------------+-------------+-------------+
Figure 3: NTLP message format
The Application layer (RSVPv2 NSLP) depicted in Figure 3 contains
RSVPv2 NSLP messages. The RSVPv2 NSLP messages and their meaning is
introduced in Table 1. Furthermore, the same table identifies the
NTLP message that will transport a NSLP message.
Westberg, et al. Expires October 2003 [Page 26]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Table 1: NSLP messages
Meaning of the NSLP message NSLP Message Type NTLP Message Type
__________________________ _____________ _________________
Initiation NslpPathInit PATH
Initiation NslpResvInit RESV
Modification NslpPathMod PATH
Modification NslpResvMod RESV
Refresh NslpPathRef PATH
Refresh NslpResvRef RESV
Path Tear down NslpPathTear PATHTEAR
Resv Tear down NslpResvTear RESVTEAR
Path Error report NslpPathErr PATHERROR
Resv Error report NslpResvErr RESVERROR
Resv Confirm NslpResvConfirm RESVCONFIRM
In order to have a flexible and modular RSVPv2 NSLP object class
structure, we propose a grouping of signalling information into
RSVPv2 NSLP object classes, called RSVPv2 NSLP 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 NSLP structure the following RSVPv2 NSLP 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.
Westberg, et al. Expires October 2003 [Page 27]
Internet Draft Proposal for RSVPv2-NSLP April 2003
* Session_ID_Class
This object class is common for the NTLP and NSLP. In [Weka03]
this object class is denoted as Session object.
This class includes information related to the
identification of NTLP states. This object will contain
a session identifier.
The session identifier has to identify a NTLP state
and has to remain unchanged for the complete duration of a
data flow. Moreover, the Session_ID_Class 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 session 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 session
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. This class should also contain
an NSLP identifier, which identifies the NSLP type.
* 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
Westberg, et al. Expires October 2003 [Page 28]
Internet Draft Proposal for RSVPv2-NSLP April 2003
occur during reservation state processing. This object class
can be considered as common for the NTLP and NSLP. In [Weka03]
this object class is denoted as Error_Spec object.
5.1.1. RSVPv2 NSLP Message Structure
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.
Based on the above defined RSVPv2 object-class structure the format
of the RSVPv2 NSLP messages may be as follows:
<NslpPathInit> | <NslpPathMod> | <NslpResvInit> | <NslpResvMod> |
<NslpPathTear> | <NslpResvTear> | <NslpResvConfirm> ::=
<Service_Class>
<Session_ID_Class>
<Flow_Specification_Class>
[<Security_class>]
<NslpPathErr> | <NslpResvErr> ::=
<Service_Class>
<Session_ID_Class>
<Flow_Specification_Class>
[<Security_class>]
<Error_message_class>
5.2. RSVPv2-NSLP Objects in RSVPv2-NSLP Object_Classes
This section presents a generic method of mapping globally and
locally defined RSVPv2 NSLP objects into RSVPv2 NSLP classes. Based
on the definitions of the RSVPv2 NSLP object classes, an RSVPv2 NSLP
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 NSLP Object_Classes. The locally defined
Westberg, et al. Expires October 2003 [Page 29]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 the Appendix.
Service_Class:
[<PHR>]
[<PDR>]
<any globally defined e2e service objects>
Flow_Specification_Class:
<any globally defined e2e service Flow_Specification objects>
Session_ID_Class:
<any globally defined e2e service session ID 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 [RFC2205] 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
have to be provided. Based on the RSVPv2 object-class structure an
example of a possible mapping of current RSVPv1 objects in RSVPv2
NSLP object structure is given.
The mandatory objects that will be needed in an sender-initiated NSLP
RSVPv2 optimized for unicast are:
Westberg, et al. Expires October 2003 [Page 30]
Internet Draft Proposal for RSVPv2-NSLP April 2003
* 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.
* 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].
Westberg, et al. Expires October 2003 [Page 31]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Based on the definitions of the RSVPv2 object classes, some of the
RSVPv1 objects (see [RFC2205]) can be re-used in a RSVPv2 NSLP
object-class structure. During the RSVPv2 NSLP 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
NSLP object classes and the current RSVPv1 objects the mapping of
RSVPv1 objects into the RSVPv2 NSLP object-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>
<TIME_VALUES>
<NSLP_ID>
{<FILTER_SPEC>}
{<STYLE>}
{<SCOPE>}
Session_ID_Class:
<SESSION>
<NSLP_ID>
Security_Class:
[<INTEGRITY>]
Error_Message_Class:
<ERROR_SPEC>
where:
{} is mandatory only for multicast support and
receiver-initiated approach
Westberg, et al. Expires October 2003 [Page 32]
Internet Draft Proposal for RSVPv2-NSLP April 2003
[] is optional for unicast and multicast support and
sender-initiated and receiver-initiated approach
<NSLP_ID> is a new object that identifies the ID of the NSLP
protocol level.
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
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 NSLP
RSVPv2 object. The Appendix provides an example of PHR and PDR object
specifications
5.3. RSVPv2-NSLP functionality on nodes used for inter-domain
signaling
This section describes the RSVPV2-NSLP 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 used in the examples provided in Section 6.
5.3.1. NI (NSIS Initiator) functionality
The NI (NSIS Initiator) functionality can be characterized as
unidirectional and bi-directional reservation functionality.
5.3.1.1. Unidirectional functionality
The "e2e service" functionality of the NI(sender), after creating an
NSLP reservation state, it generates an NslpPathInit message (see
Section 5.1.1). The flow ID, the ID of the NSLP protocol and the
time values can be included in the Flow_Specificaton_Class (e.g.,
<Session>, <Sender_template>, <Time_Values>, <NSLP_ID> objects). The
session ID and the ID of the NSLP protocol can be included in the
Session_ID_Class (e.g.,<Session> and <NSLP_ID> objects). The
information that is related tothe service desired from the network,
i.e., requested QoS, can be included into the Service_Class object
class (e.g., <Sender_Tspec> and <Flowspec> objects). Moreover, the
Westberg, et al. Expires October 2003 [Page 33]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Service_Class object specifies the directionality of the reservation,
i.e., in this case uni-directional. The NslpPathInit is encapsulated
into a NTLP PATH message (see [RFC2205]) and sent towards the
NR(receiver).
The NI(sender) can receive a NslpResvInit message that is
encapsulated into a RESV message. This message is associated with a
NslpPathInit message that is sent earlier and that is used for a uni-
directional reservation. The "e2e service" functionality of the
NslpResvInit message specifies that the reservation initiated by the
NslpPathInit message was successful. In this case the NI(sender),
after processing the NslpResvInit message, it can start transmitting
traffic user data. The "e2e service" functionality of the NI(sender)
can receive a NslpPathErr message that is encapsulated into a
PATHERROR message, that is associated with a NslpPathInit message
sent earlier, and which is used for a uni-directional reservation.
The NslpPathErr message can specify that the reservation initiated by
the NslpPathInit message was unsuccessful. In this case the
NI(sender), after processing the NslpPathError message, it has to
delete the reservation state.
The RSVPv2-NSLP refresh procedure is a pure NTLP refresh procedure,
meaning that a refresh NTLP PATH message that is periodically sent
through all the NTLP stateful nodes located between NI (sender) and
NR (receiver). If a NTLP state in a NTLP stateful is not refreshed
on time then the NTLP functionality at this node informs the
RSVPv2-NSLP state that the refresh procedure is unsuccessful. Note
that the refresh NTLP PATH message may optionally carry a NslpPathRef
message. In this case the information carried by the NslpPathRef
message is similar to the information carried by the NslpPathInit
message, (see Section 5.1.1).
The NI(sender) can receive a NslpResvRef message that is encapsulated
into a RESV message. This message is associated with a NslpPathRef
message that is sent earlier and that is used for a uni-directional
reservation. The "e2e service" functionality of the NslpResvRef
message specifies that the reservation initiated by the NslpPathRef
message was successful.
The RSVPv2-NSLP "e2e service" functionality of the NI(sender) can
inform the NTLP functionality of the same node to start a tear down
procedure for the specific flow. A NTLP PATHTEAR message is created
that is sent towards the NR (receiver). This message will tear down
all the NTLP and RSVPv2-NSLP states that are associated with the
Westberg, et al. Expires October 2003 [Page 34]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Session_ID_Class of all NTLP stateful nodes that process the NTLP
PATHTEAR message. Note that the NTLP PATHTEAR message may optionally
carry a NSLPPathTear message. In this case the information carried by
the NslpPathTear message is similar to the information carried by the
NslpPathInit message, (see Section 5.1.1).
The RSVPv2-NSLp protocol supports the modification of a reservation
procedure. The "e2e service" functionality includes the request for
modification of the reservation into a NslpPathMod message. This NSLP
message is encapsulated into a NTLP PATH message and it is sent hop-
by-hop towards the NR(receiver). The flow ID of the flow that has to
be modified is included in the Flow_Specificaton_Class. The
information that has to be modified is included into the
Service_Class object class. (e.g., <Sender_Tspec> and <Flowspec>
objects).
The NI(sender) receives a NslpResvMod message that is encapsulated
into a NTLP RESV message (see Section 5.1.1). This message is
associated with a NslpPathMod message that is sent earlier and that
is used for a uni-directional reservation. The "e2e service"
functionality of the NslpResvMod message specifies that the
modification of the reservation requested by the NslpPathMod message
was successful. In this case the NI(sender), after processing the
NslpResvMod message, it can adjust the transmitted traffic user data
to the modified reservation.
The "e2e service" functionality of the NI(sender) can receive a
NslpPathErr message that is associated with a NslpPathMod message
sent earlier. The NslpPathErr message can specify that the
modification procedure initiated by the NslpPathMod message was not
successful. In this case the "e2e functionality" of the NI (sender)
will identify the modification type of the NslpPathErr message. If
the modification procedure required a higher amount of reservation,
then the reservation asociated to the modified flow will have to be
reset to the reservation or to the amount (or type) of reservation
that was stored before the modification procedure started.
5.3.1.2. Bidirectional functionality
The bi-directional reservation functionality supported by the
NI(sender) is similar to a combination of two unidirectional
reservation functionalities that are accomplished in opposite
directions. Such a unidirectional reservation functionality is
Westberg, et al. Expires October 2003 [Page 35]
Internet Draft Proposal for RSVPv2-NSLP April 2003
described in Section 5.3.1.1. The main differences of the bi-
directional reservation functionality with the combination of two
unidirectional reservation functionalities accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NI(sender) does not receive the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the success of the reservation procedure is reported to the NI(sender)
using the NslpPathInit that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathRef that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathMod that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
5.3.2. NF (NSIS Forwarder) functionality
The NF (NSIS Forwarder) functionality can be characterized as
unidirectional and bi-directional reservation functionality.
5.3.2.1. Unidirectional functionality
The NslpPathInit is encapsulated into a NTLP PATH message (see
[RFC2205]). The NTLP PATH message is processed by all NTLP stateful
NF nodes that is passing through, up to the NR (receiver). Each node
that processes the NTLP PATH message will create a NTLP state and
will activate the RSVPv2-NSLP "e2e service" functionality by using
the transported NslpPathInit information and it will create an
RSVPv2-NSLP reservation state. This RSVPv2-NSLP reservation state
will be associated to a flow ID. Note that the NTLP states have to
store back-ward routing information, which are used by NTLP messages
that are transported hop-by-hop in the backward direction towards the
NI(sender). The NslpResvInit which is encapsulated into a RESV
message will only be processed by the RSVPv2-NSLP "e2e service"
functionality at each NF hop that is passing by and that is
supporting the "e2e service" functionality.
The used RSVPv2-NSLP refresh procedure is a pure NTLP refresh
Westberg, et al. Expires October 2003 [Page 36]
Internet Draft Proposal for RSVPv2-NSLP April 2003
procedure, meaning that a refresh NTLP PATH message is periodically
sent through all the NTLP stateful nodes located between NI (sender)
and NR (receiver). If a NTLP state in a NTLP stateful is not
refreshed on time then the NTLP functionality at this node informs
the RSVPv2-NSLP state that the refresh procedure is unsuccessful.
Note that the refresh NTLP PATH message may optionally carry a
NSLPPathRef message.
The NTLP RESV message used during the refresh procedure is processed
at each NF hop towards the NI (sender). This message will be used to
report information related to how the NTLP PATH message has been
processed along the path. Note that the refresh NTLP RESV message
may optionally carry a NSLPResvRef message. The NslpPathRef and
NslpResvRef messages are processed by the RSVPv2-NSLP "e2e service"
functionality at each NF hop that are passing by and that is
supporting the "e2e service" functionality.
The NF node processes a NTLP PATHTEAR message that is tearing down
all the NTLP and RSVPv2-NSLP states that are associated with the
Session_ID_Class of all NTLP stateful nodes that process the NTLP
PATHTEAR message. Note that the NTLP PATHTEAR message may optionally
carry a NslpPathTear message. The NslpPathTear message will be
processed by the "e2e service" functionality.
When one of the NF nodes is not able to satisfy a NslpPathInit
request the RSVPv2-NSLP "e2e service" functionality of this
particular NF(router) will generate an NslpPathErr to report to
NI(sender) that the NslpPathInit request could not be satisfied.
This NslpPathErr message will be encapsulated into a NTLP PATHERROR
message and it will be sent hop-by-hop towards the NI(sender). This
message will be processed hop-by-hop by the RSVPv2-NSLP "e2e
service" functionality. Each NF (router) that processes this
NslpPathError message will have to to delete its associated
reservation state. Note that similar to [RFC2205] the NslpPathErr
could be created due to other errors in the router. The type of this
error must be included into the Error_Message_Class (see Section
5.1.1). Note that the reservation state is only deleted when the
NSlpPathErr message is associated to a NslpPathInit message.
When one of the NF nodes is not able to satisfy a NslpPathMod request
the RSVPv2-NSLP "e2e service" functionality of this particular
NF(router) will generate an NslpPathErr to report to NI(sender) that
the NslpPathMod request could not be satisfied. This message will be
encapsulated into a NTLP PATHERROR message and it will be sent
Westberg, et al. Expires October 2003 [Page 37]
Internet Draft Proposal for RSVPv2-NSLP April 2003
towards the NI(sender). The NslpPathMod message will not be forwarded
further. The "e2e functionality" of the NF intermediate nodes will
identify the modification type of the NslpPathErr message. If the
modification procedure required a higher amount of reservation, then
the nodes that modified the reservation will have to reset the
reservation to the amount (or type) of reservation that was stored
before the modification procedure started.
Each NTLP stateful node can process a NslpPathMod message that is
carried by a modification NTLP PATH message. The RSVPv2-NSLP
functionality identifies the flow that has to be modified by using
its flow ID information carried by the NslpPathMod message. By using
the information contained in the Service_Class, the RSVPv2-NSLP
functionality is modifying the service information stored into the
RSVPv2-NSLP state. The "e2e service" functionality of each NF node
has to process a NslpResvMod message which is used to report
information related to how the NslpPathMod message has been processed
along the path. This NslpResvMod message is encapsulated into a NTLP
RESV message and sent towards the NI(sender).
5.3.2.2. Bidirectional functionality
The bi-directional reservation functionality supported by the
NF(router) is similar to a combination of two unidirectional
reservation functionalities that are accomplished in opposite
directions. Such a unidirectional reservation functionality is
described in Section 5.3.2.1. The main differences of the bi-
directional reservation functionality with the combination of two
unidirectional reservation functionalities accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NF(router) does not process the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the success of the reservation procedure is reported to the NI(sender)
using the NslpPathInit that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathRef that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathMod that is sent hop-by-hop from NR(receiver)
Westberg, et al. Expires October 2003 [Page 38]
Internet Draft Proposal for RSVPv2-NSLP April 2003
towards the NI(sender)
5.3.3. NR (NSIS Responder) functionality
The NR (NSIS Responder) functionality can be characterized as
unidirectional and bi-directional reservation functionality.
The NR(receiver) can receive a NslpPathInit message that is
encapsulated into a NTLP PATH message. The NR (receiver) processes
the NTLP PATH message, creates a NTLP state and activates the
RSVPv2-NSLP "e2e service" functionality by using the transported
NslpPathInit information and it will create an RSVPv2-NSLP
reservation state. This RSVPv2-NSLP reservation state will be
associated to a flow ID. Note that the NTLP states have to store
back-ward routing information. The "e2e service" functionality
creates a NslpResvInit message that is used to report information
related to how the NslpPathInit has been processed along the path.
This NslpResvInit will be encapsulated into a RESV message and it
will be sent on a hop-by-hop basis in the backward direction towards
the NI(sender).
The RSVPv2-NSLP refresh procedure supported by the NR(receiver) is a
pure NTLP refresh procedure, meaning that a refresh NTLP PATH message
is periodically sent through all the NTLP stateful nodes located
between NI (sender) and NR (receiver). If a NTLP state in a NTLP
stateful is not refreshed on time then the NTLP functionality at this
node informs the RSVPv2-NSLP state that the refresh procedure is
unsuccesful. Note that the refresh NTLP PATH message may optionally
carry a NSLPPathRef message. The NR (receiver) that receives a
refresh NTLP PATH message will create a refresh NTLP RESV message
that will be sent towards the NI (sender). This message will be used
to report information related to how the NTLP PATH message has been
processed along the path. Note that the refresh NTLP RESV message
may optionally carry a NSLPResvRef message.
A NTLP PATHTEAR message can be received by the NR (receiver). This
message will tear down all the NTLP and RSVPv2-NSLP states that are
associated with the Session_ID_Class of the NR (receiver) that
process the NTLP PATHTEAR message. Note that the NTLP PATHTEAR
message may optionally carry a NSLPPathTear message.
When the NR(receiver) is not able to satisfy a NslpPathInit request
the RSVPv2-NSLP "e2e service" functionality of the NR(receiver) will
generate an NslpPathErr to report to NI(sender) that the NslpPathInit
Westberg, et al. Expires October 2003 [Page 39]
Internet Draft Proposal for RSVPv2-NSLP April 2003
request could not be satisfied. This NslpPathErr message will be
encapsulated into a NTLP PATHERROR message and it will be sent hop-
by-hop towards the NI(sender). Note that similar to [RFC2205] the
NslpPathErr could be created due to other errors in the router. The
type of this error must be included into the Error_Message_Class (see
Section 5.1.1). When the NSlpPathErr message is associated to a
NslpPathInit message then its associated reservation state will be
deleted.
The NR (receiver) can receive the NslpPathMod message which is
carried by the modification NTLP PATH message. The RSVPv2-NSLP
functionality identifies the flow that has to be modified by using
its flow ID information carried by the NslpPathMod message. By using
the information contained in the Service_Class, the RSVPv2-NSLP
functionality is modifying the service information stored into the
RSVPv2-NSLP state. Subsequently the RSVPv2-NSLP "e2e service"
functionality at the NR(receiver) creates a NslpResvMod message that
will be used to report information related to how the NslpPathMod
message has been processed along the path. This NslpResvMod message
will be encapsulated into a NTLP RESV message and sent hop-by-hop
towards the NI(sender).
When the NR(receiver) is not able to satisfy a NslpPathMod request
the RSVPv2-NSLP "e2e service" functionality of this node will
generate an NslpPathErr to report to NI(sender) that the NslpPathMod
request could not be satisfied. This message will be encapsulated
into a NTLP PATHERROR message and it will be sent towards the
NI(sender). In this case the "e2e functionality" of the NR
(receiver) will identify the modification type of the NslpPathErr
message. If the modification procedure required a higher amount of
reservation, then the reservation asociated to the modified flow will
have to be reseted to the reservation or to the amount (or type) of
reservation that was stored before the modification procedure
started.
5.3.3.1. Bidirectional functionality
The bi-directional reservation functionality supported by the
NR(receiver) is similar to a combination of two unidirectional
reservation functionalities that are accomplished in opposite
directions. Such a unidirectional reservation functionality is
described in Section 5.3.3.1. The main differences of the bi-
directional reservation functionality with the combination of two
unidirectional reservation functionalities accomplished in opposite
Westberg, et al. Expires October 2003 [Page 40]
Internet Draft Proposal for RSVPv2-NSLP April 2003
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NR(receiver) does not process the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the success of the reservation procedure is reported to the NI(sender)
using the NslpPathInit that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathRef that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathMod that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
5.4. RSVPv2-NSLP 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). These intra-domain signaling
procedures are using the NSIS protocol which consists of one NTLP
level and two NSLP hierarchical levels (see Figure 2).
Intra-domain signaling is where the RSVPv2-NSLP signaling messages
are originated, processed and terminated within the same domain.
RSVPv2-NSLP is considered in this section to be optimized for unicast
and sender-initiated protocol.
The Intra-domain signaling procedures are mainly using RSVPv2-NSLP
PHR/PDR objects, (see Section 5.2.2) that are originated, processed
and terminated within the same domain. Note that this functionality
is used in the examples provided in Section 7.
5.4.1. NI (NSIS Initiator) functionality
The NI (NSIS Initiator) functionality can be characterized as
unidirectional and bi-directional reservation functionality.
Westberg, et al. Expires October 2003 [Page 41]
Internet Draft Proposal for RSVPv2-NSLP April 2003
5.4.1.1. Unidirectional functionality
The unidirectional functionality supported by the NI(sender) used in
this type of scenarios is identical to the functionality supported by
the NI(sender) used in the inter-domain signaling scenario (see
Section 5.3.1.1).
5.4.1.2. Bidirectional functionality
The bi-directional functionality supported by the NI(sender) used in
this type of scenarios is identical to the functionality supported by
the NI(sender) used in the inter-domain signaling scenario (see
Section 5.3.1.2).
5.4.2. Functionality of NF (NSIS Forwarder) located outside NSIS
intra-domain
The functionality of the NF (NSIS Forwarder) located outside the NSIS
intra-domain can be characterized as unidirectional and as bi-
directional reservation functionality.
5.4.2.1. Unidirectional functionality
The unidirectional functionality supported by the NF located outside
the NSIS intra-domain and used in this type of scenarios is identical
to the functionality supported by the NF(router) used in the inter-
domain signaling scenario (see Section 5.3.2.1).
5.4.2.2. Bidirectional functionality
The bi-directional functionality supported by the NF located outside
the NSIS intra-domain and used in this type of scenarios is identical
to the functionality supported by the NF(router) used in the inter-
domain signaling scenario (see Section 5.3.2.2).
5.4.3. NF (ingress) functionality
The NF (ingress) functionality can be characterized as unidirectional
and bi-directional reservation functionality.
Westberg, et al. Expires October 2003 [Page 42]
Internet Draft Proposal for RSVPv2-NSLP April 2003
5.4.3.1. Unidirectional functionality
When an NslpPathInit arrives at the ingress node of a domain, i.e.,
NF(ingress), the RSVPv2-NSLP "e2e service" functionality creates a
RSVPv2-NSLP Path reservation state. Subsequently, the RSVPv2-NSLP
"PDR" protocol functionality is activated (see Figure 2) classifying
the flow (i.e., Flow_Specification_Class) that is associated with the
NslpPathInit message into an appropriate traffic class, e.g.,
Diffserv class. The RSVPv2-NSLP PDR functionality uses the
RSVPv2-NSLP path state created by the NslpPathInit message and it
introduces additional information that can be used to associate the
PHR and PDR objects with the flow that created the RSVPv2-NSLP Path
reservation state in the NF(ingress) node. The RSVPv2-NSLP PDR
functionality is subsequently using the Service_Class (e.g.,
<SENDER_Tspec> object) and translates the requested bandwidth
parameter into a number of resource units. 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 are locally defined objects which are
included into the Service_Class object class carried by the
NslpPathInit message. The NslpPathInit message is encapsulated into
a NTLP PATH message and is sent towards the NR(receiver). Note that
the "PDR/PHR" functionality of the NF(ingress) node should
temporarily store the TTL value, included in the IP header of any
message, in the PDR state associated to the NTLP PATH message. The
variable that temporarily stores the TTL value is denoted in this
text as PDR_TTL_I.
The NF(ingress) can receive a NslpResvInit message that is
encapsulated into a RESV message. This message is associated with a
NslpPathInit message that is sent earlier and that is used for a uni-
directional reservation. The "e2e service" functionality by
extracting the Service_Class object from the NslpResvInit message, it
can deduce that the reservation was successful. Moreover, the
RSVPv2-NSLP "PDR" functionality of the NF(ingress) node is extracting
the "PDR_Reservation_Report" PDR object from the Service_Class object
class of the NslpResvInit message. If the initial reservation
request was successful the RSVP-NSLP functionality encapsulates the
NslpResvInit message into the NTLP RESV message and it is sent
towards the NI(sender).
The intra-domain RSVPv2-NSLP refresh procedure is a combination of a
Westberg, et al. Expires October 2003 [Page 43]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NTLP and a RSVPv2-NSLP "PHR/PDR" procedure. When a refresh NTLP PATH
message is received by a NF(ingress) node the NTLP functionality will
activate the RSVPv2-NSLP "PHR/PDR" functionality that is carried by
the NslpPathRef message. By using the Flow_Specification_Class
object class the "PDR" functionality can identify the RSVPv2-NSLP
path state. The RSVPv2-NSLP "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 are
locally defined objects which are included into the Service_Class
object class carried by the NslpPathRef message.
The NF(ingress) can receive a NslpResvRef message that is
encapsulated into a RESV message. This message is associated with a
NslpPathRef message that is sent earlier and that is used for a uni-
directional reservation. The "e2e service" functionality by
extracting the Service_Class object from the NslpResvRef message, it
can deduce that the refresh procedure was successful. Moreover, the
RSVPv2-NSLP "PDR" functionality of the NF(ingress) node is extracting
the "PDR_Refresh_Report" PDR object from the Service_Class object
class of the NslpResvRef message. If the refresh procedure was
successful the RSVP-NSLP functionality encapsulates the NslpResvRef
message into the NTLP RESV message and it is sent towards the
NI(sender).
The NTLP functionality of the NF(ingress) can receive a NTLP PATHTEAR
message sent by the NI(sender). The NTLP PATHTEAR message may
optionally carry a NslpPathTear message. The NTLP functionality
activates the RSVPv2-NSLP "PDR/PHR" functionality, that is related to
the Session_ID_Class class object, and that is using the "PDR"
object. The RSVPv2-NSLP "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 are
locally defined objects which are included into the Service_Class
object class carried by a NslpPathTear message. All the RSVPv2-NSLP
and NTLP reservations, in the NF(ingress) node that are associated to
the Session_ID_Class object class will be released.
During an unsuccessful procedure, the NTLP functionality of the
NF(ingress) node can receive the a PATHERROR message that will
Westberg, et al. Expires October 2003 [Page 44]
Internet Draft Proposal for RSVPv2-NSLP April 2003
activate the RSVPv2-NSLP "PDR" functionality. Due to the "M" marked
"PDR_Reservation_Report" object the "PDR" functionality will activate
the RSVPv2-NSLP "e2e service". The RSVPv2-NSLP "e2e service"
functionality of the NF(ingress) node will generate a NslpPathErr
message that will be sent hop-by-hop to the NI(sender) and will be
encapsulated into a NTLP PATHERROR message. This message will inform
the NI(sender) that the reservation request was not successful.
Simultaneously, the NF(ingress) node will start a partial explicit
release procedure, for releasing the unnecessarily reserved RSVP-NSLP
resources in some NF(interior) nodes for the rejected flow. In this
case, the RSVP-NSLP "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 RSVPv2-NSLP "PDR" functionality will create the
"PDR_Reservation_Request" PDR object. The RSVPv2-NSLP "PDR"
functionality of the NF(ingress) node can calculate the number of
NF(interior) nodes that processed and reserved RSVPv2-NSLP resources.
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 RSVPv2-NSLP state
when the initial NslpPathInit message has been sent towards the
NF(egress) node. This calculated value will be included in the TTL -
IP header field of the NTLP PATHTEAR message which is generated by
the NF(ingress) node and which transports the "PHR_Resource_Release"
object. The "PHR_Release_Request" and "PDR_Release_Request" objects
are included into a NslpPathTear message. The NslpPathTear message is
transported by a NTLP PATHTEAR message.
A NTLP PATH message that encapsulates the NslpPathMod message can be
received by the NTLP functionality of the NF(ingress) node. The NTLP
functionality activates the RSVP-NSLP "PDR/PHR" functionality, which
is associated with the Session_ID_Class object class.
When the modification request requires an increase on the number of
reserved resources stored in the RSVPv2-NSLP state, then the
RSVPv2-NSLP "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 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 in the RSVPv2-NSLP state should also be replaced with the number
of resources included in the modification request.
The RSVPv2-NSLP "PDR" functionality will create a
Westberg, et al. Expires October 2003 [Page 45]
Internet Draft Proposal for RSVPv2-NSLP April 2003
"PDR_Modification_Request" PDR object. These two objects will be
included into the Service_Class of the NslpPathMod message. The
NslpPathMod message is encapsulated into a modification NTLP PATH
message and is sent towards the NF(egress) node.
When the modification request requires a decrease on the number of
reserved resources stored in the RSVPv2-NSLP path state, then the
RSVPv2-NSLP "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 RSVPv2-NSLP
"PHR_Release_Request" PHR object. Furthermore, the number of
resources that were reserved in the RSVPv2-NSLP path state for a
certain flow should also be replaced with the number of resources
included in the modification request. The RSVPv2-NSLP "PDR"
functionality will create a "PDR_Modification_Request" PDR object.
These two objects will be encapsulated into a modification NTLP PATH
message. This message will be sent towards the NF(egress) node.
The NF(ingress) can receive a NslpResvMod message that is
encapsulated into a RESV message. This message is associated with a
NslpPathMod message that is sent earlier and that is used for a uni-
directional reservation. The "e2e service" functionality by
extracting the Service_Class object from the NslpResvMod message, it
can deduce that the modification procedure was successful. Moreover,
the RSVPv2-NSLP "PDR" functionality of the NF(ingress) node is
extracting the "PDR_Refresh_Report" PDR object from the Service_Class
object class of the NslpResvRef message. If the modification
procedure was successful the RSVP-NSLP functionality encapsulates the
NslpResvMod message into the NTLP RESV message and it is sent towards
the NI(sender).
If the modification procedure is not successful, the NTLP
functionality of the NF(ingress) node can receive a PATHERROR
message. This message carries a NslpPathErr message. The "e2e
functionality" of the NF (ingress) will identify the modification
type of the NslpPathErr message. The NslpPathErr message could
either carry a "PDR_Modification_Report" or not. When the
NslpPathErr message carries a "PDR_Modification_Report", the RSVP-
NSLP "PDR" functionality will detect the "M" marked
"PDR_Modification_Report" object and it will activate the RSVPv2-NSLP
"e2e service". When the NslpPathErr message does not carry a
"PDR_Modification_Report" message, the RSVPv2-NSLP "e2e service" is
directly activated. The RSVPv2-NSLP "e2e service" functionality of
the NF(ingress) node will generate a NslpPathErr message that will be
Westberg, et al. Expires October 2003 [Page 46]
Internet Draft Proposal for RSVPv2-NSLP April 2003
sent hop-by-hop to the NI(sender) and will be encapsulated into a
NTLP PATHERROR message. This message will inform the NI(sender) that
the modification request was not successful. If the modification
procedure required a higher amount of reservation, then the
NF(ingress) node has to start a partial explicit release, for
releasing the unnecessarily reserved RSVP-NSLP resources in some
NF(interior) nodes for the modified flow. The number of
unnecessarily reserved resources is found by the RSVPv2-NSLP "PHR"
functionality that subtracts the old and already reserved number of
resources from the number of resources included in the new
modification request. The partial explicit release procedure is
further accomplished in the same as the partial explicit release
procedure used during the unsuccessful reservation procedure.
The NTLP signaling messages and subsequently the "PHR" and "PDR"
objects might be dropped, for example due to route or link failure.
The "PHR" objects that need to be sent reliable are:
PHR_Resource_Request
PHR_Refresh_Update
The reliable delivery of the "PHR_Resource_Request" object is
provided by using the functionality provided by the RSVPv2-NSLP "PDR"
functionality located in the NF(ingress) node. The RSVPv2-NSLP "PDR"
functionality of the NF(ingress) node sends the
"PHR_Resource_Request" object towards the NF(egress) node and 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. The reliable deliver of the
"PHR_Refresh_Update" object is provided in a similar way. A timer at
the NF(ingress) node is started when the "PHR_Refresh_Update" is sent
towards the NF(egress) node. If the reply, e.g., "PDR_Refresh_Report"
object, does not arrive in a predefined time it assumes that the
"PHR_Refresh_Update" object is lost.
During a severe congestion situation, the NF(ingress) node can
receive the PDR_Congestion_Report object. This object is included
into a NslpPathErr message that is carried by a NTLP PATHERROR. The
RSVPv2-NSLP PDR functionality of the NF(ingress) node is extracting
the Pdrop blocking probability from the PDR_Congestion_Report
message. Depending on the used policy the NF(ingress) node 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 NF(ingress) node will generate a
"PHR_Release_Request" object that will be included into the
Service_Class of the NslpPathTear message. This message will be
Westberg, et al. Expires October 2003 [Page 47]
Internet Draft Proposal for RSVPv2-NSLP April 2003
transported by a NTLP PATHTEAR message towards the NF(egress).
Furthermore, the RSVPv2-NSLP "e2e service" functionality in the
NF(ingress) node will create a NslpPathErr that will be encapsulated
into a NTLP PATHERROR that will be sent towards the NI(sender) to
notify that an error occurred.
5.4.3.2. Bidirectional functionality
The bi-directional reservation functionality supported by the
NF(ingress) is similar to a combination of two unidirectional
reservation functionalities that are accomplished in opposite
directions. Such a unidirectional reservation functionality is
described in Section 5.4.3.1. The main differences of the bi-
directional reservation functionality with the combination of two
unidirectional reservation functionalities accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NF(ingress) does not receive the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the success of the reservation procedure is reported to the NI(sender)
using the NslpPathInit that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathRef that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathMod that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the PDR_Reservation_Report object used to report a successful
reservation procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the PDR_Refresh_Report object used to report a successful refresh
procedure is carried by the NslpPathInit that is sent hop-by-hop
from NF(egress) towards the NF(ingress)
* the PDR_Modification_Report object used to report a successful
modification procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the NF(egress) node can initiate an explicit partial release
procedure towards the NF(ingress) node.
Westberg, et al. Expires October 2003 [Page 48]
Internet Draft Proposal for RSVPv2-NSLP April 2003
5.4.4. NF (interior) functionality
The NF (interior) functionality can be characterized as
unidirectional and bi-directional reservation functionality.
5.4.4.1. Unidirectional functionality
The initiation NTLP PATH message is processed by all NTLP stateless
NF(interior) nodes that is passing through, up to the NF (egress).
Each stateless NF(interior) node that processes the NTLP PATH message
it will not create a NTLP state but it will activate the RSVPv2-NSLP
functionality by using the transported NslpPathInit message. The
RSVPv2-NSLP "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.
It is possible that one of the NTLP stateless NF(interior) is not
able to satisfy the request carried by the "PHR_Resource_Request" PHR
object. The RSVPv2-NSLP "PHR" functionality of this NF(interior) node
will mark the "M" field of the "PHR_Resource_Request" object. The
RSVPv2-NSLP "PHR" functionality will also include the number of
previous NF(interior) nodes that successfully processed the
RSVPv2-NSLP "PHR_Resource_Request" PHR object (see Appendix). This
number can, for example, be identified by the TTL (Time-To-Live)
value included in the IP header of the received NTLP PATH message.
Note that each time that an IP packet passes a node, its TTL value is
decreased by one. 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 NTLP PATH 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) is set to "1". These "PHR" and "PDR"
objects are included in the NslpPathInit message. The NslpPathInit
message is encapsulated into a NTLP PATH message. This NslpPathInit
message is sent towards the NF(egress) node, which will be
transported by a NTLP PATH message. Any NF(interior) node receiving a
PATH message will activate the RSVPv2-NSLP "PHR" functionality. If
the "PHR_Resource_Request" PHR object is "M" marked, then the
RSVPv2-NSLP "PHR" functionality will not further process the "PHR"
Westberg, et al. Expires October 2003 [Page 49]
Internet Draft Proposal for RSVPv2-NSLP April 2003
object.
The refresh NTLP PATH message is processed by all NTLP stateless
NF(interior) nodes that is passing through, up to the NF (egress).
Each node that processes the refresh NTLP PATH message it will
refresh the NTLP state associated with the session ID, i.e.,
information included into the Session_ID_Class object class. The
NTLP level functionality of the NTLP stateless NF(interior) nodes
receiving the refresh NTLP PATH message will activate the RSVPv2-NSLP
"PHR" functionality. The RSVPv2-NSLP "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 NTLP PATHTEAR message is processed by all NTLP stateless
NF(interior) nodes that is passing through, up to the NF (egress).
Each node that processes the PATHTEAR message will activate the
RSVPv2-NSLP "PHR" functionality by using the transported RSVPv2-NSLP
"PHR" object. The NTLP functionality in the NTLP stateless
NF(interior) node that receives the PATHTEAR message will pass the
NslpPathTear message to the RSVPv2-NSLP functionality. The
NslpPathTear message contains the "PHR_Release_Request" and
"PDR_Release_Request" PHR and PDR objects, respectively. The
RSVPv2-NSLP "PHR" functionality of this NF(interior) node 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, its TTL value
of the NTLP PATHTEAR message is decremented by one. If this value
becomes zero, the "PHR_Resource_Release" object reached an
NF(interior) node that marked the "PHR_Resource_Request" object
during an unsuccessful procedure and the NTLP PATHTEAR message will
be dropped. Otherwise, the NTLP PATHTEAR message propagates towards
the NR(receiver).
Each stateless NF(interior) node that receives the modification NTLP
PATH message will activate the RSVPv2-NSLP "PHR" functionality. The
RSVPv2-NSLP "PHR" functionality of each stateless NF(interior)node
processes the "PHR_Resource_Request" and "PHR_Release_Request"
objects included in the modification NTLP PATH message as typical
"PHR_Resource_Request" and "PHR_Release_Request" objects,
respectively.
Westberg, et al. Expires October 2003 [Page 50]
Internet Draft Proposal for RSVPv2-NSLP April 2003
After detecting the severe congestion situation, the RSVPv2-NSLP
"PHR" functionality of the NF(interior) node will notify the
NF(egress) node by using remarking of user data bytes that pass
through the node. Proportionally to the detected overload the
NF(interior) node will remark a number of user data bytes 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.
5.4.4.2. Bidirectional functionality
The bi-directional reservation functionality supported by the
NF(interior) is similar to a combination of two unidirectional
reservation functionalities that are accomplished in opposite
directions. Such a unidirectional reservation functionality is
described in Section 5.4.4.1. The main differences of the bi-
directional reservation functionality with the combination of two
unidirectional reservation functionalities accomplished in opposite
directions are as follows:
* the PDR_Reservation_Report object used to report a successful
reservation procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the PDR_Refresh_Report object used to report a successful refresh
procedure is carried by the NslpPathInit that is sent hop-by-hop
from NF(egress) towards the NF(ingress)
* the PDR_Modification_Report object used to report a successful
modification procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the NF(egress) node can initiate an explicit partial release
procedure towards the NF(ingress) node.
5.4.5. NF (egress) functionality
The NF (egress) functionality can be characterized as unidirectional
and bi-directional reservation functionality.
Westberg, et al. Expires October 2003 [Page 51]
Internet Draft Proposal for RSVPv2-NSLP April 2003
5.4.5.1. Unidirectional functionality
The behavior of the NF(egress) node on admission or rejection of the
NslpPathInit message that contains the "PHR_Resource_Request" object
is the same as in the NF(interior) nodes. After processing the
"PHR_Resource_Request" object, the RSVPv2-NSLP 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 RSVPv2-NSLP "e2e service" functionality
is activated and by using the information contained in the
Flow_Specification_Class it will create an RSVPv2-NSLP Path
reservation. If the request is admitted, the RSVPv2-NSLP "PDR"
functionality of the NF(egress) node will report the successful
reservation to the RSVPv2-NSLP "PDR" functionality of the NF(ingress)
node by using a "PDR_Reservation_Report" PDR object. This object is
temporarilty stored until a NslpresvInit message arrives that is
carried by a NTLP RESV message, that was sent by the NR(receiver) and
that is associated with an earlier processed NslpPathInit message.
This "PDR_Reservation_Report" PDR object will be included into the
Service_Class object class of the NslpResvInit message. The NTLP
PATH message is forwarded towards the NR (receiver). Note that this
NTLP PATH message will not include the "PDR/PHR" object information.
If the "PHR_Resource_Request" PHR object is "M" marked, then the
RSVPv2-NSLP "PHR" functionality will activate the RSVPv2-NSLP "PDR"
functionality which 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 NslpPathErr message. The NslpPathErr message will be
encapsulated into a NTLP PATHERROR message. The NslpPathError message
will only be processed by the NF(ingress) node.
When the NF(egress) node receives a NslpPathError message which is
carried by a PATHERROR message will have to identify the error type.
If the NSlpPathErr message is associated to a NslpPathInit message
then the NslpPathErr will have to be encapsulated into a NTLP
PATHERROR message and sent towards the NI(sender). Moreover, its
associated RSVPv2-NSLP state has to be deleted. The NTLP PATHERROR
message will be processed within the NSIS intra-domain only by the
NF(ingress) node. If the NslpPathErr message is associated to a
NslpPathMod request, then then the NslpPathErr will have to be
encapsulated into a NTLP PATHERROR message and sent towards the
NI(sender). Moreover, if the modification procedure required a higher
Westberg, et al. Expires October 2003 [Page 52]
Internet Draft Proposal for RSVPv2-NSLP April 2003
amount of reservation, then the nodes that modified the reservation
will have to reset the reservation to the amount (or type) of
reservation that was stored before the modification procedure
started.
The NF(egress) node can receive a NslpResvInit message, carried by a
NTLP RESV message which was sent by the NR(receiver) and is
associated with an earlier processed NslpPathInit message. The
RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
the successful reservation to the RSVPv2-NSLP "PDR" functionality of
the NF(ingress) node by using a "PDR_Reservation_Report" PDR object.
This object will be included into the Service_Class object class of
the NslpResvInit message. Note that this message is processed in a
NSIS intra-domain only by the NF(egress) and NF(ingress) nodes. The
NF(interior)nodes are not processing this message.
The NF(egress) node can receive a refresh NTLP PATH message. The
NF(egress) node that processes the refresh NTLP PATH message it will
refresh the NTLP state associated with the session ID included into
the Session_ID_Class object class. Furthermore, it will activate the
RSVPv2-NSLP "PHR" functionality by using the transported RSVPv2-NSLP
"PHR" object. The behavior of the RSVPv2-NSLP "PHR" functionality in
the NF(egress) node is similar to the RSVPv2-NSLP "PHR" functionality
provided in the NF(interior) nodes. If the refresh is admitted, the
RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
the successful refresh procedure to the RSVPv2-NSLP "PDR"
functionality of the NF(ingress) node by using a "PDR_Refresh_Report"
PDR object. This object is temporarilty stored until a NslpResvRef
message arrives that is carried by a NTLP RESV message, that was sent
by the NR(receiver) and that is associated with an earlier processed
NslpPathRef message. This "PDR_Refresh_Report" PDR object will be
included into the Service_Class object class of the NslpResvRef
message. The NTLP PATH message is forwarded towards the NR
(receiver). Note that this NTLP PATH message will not include the
"PDR/PHR" object information.
The NF(egress) node can receive a NslpResvRef message, carried by a
NTLP RESV message which was sent by the NR(receiver) and is
associated with an earlier processed NslpPathRef message. The
RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
the successful refresh PDR/PHR procedure to the RSVPv2-NSLP "PDR"
functionality of the NF(ingress) node by using a "PDR_Refresh_Report"
PDR object. This object will be included into the Service_Class
object class of the NslpResvRef message. Note that this message is
processed in a NSIS intra-domain only by the NF(egress) and
Westberg, et al. Expires October 2003 [Page 53]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF(ingress) nodes. The NF(interior) nodes are not processing this
message.
The NF(egress) node that processes the PATHTEAR message it will
activate the RSVPv2-NSLP "PHR" functionality by using the transported
"PHR" object. The behavior of the RSVPv2-NSLP "PHR" functionality in
the NF(egress) node is similar to the RSVPv2-NSLP "PHR" functionality
provided in the NF(interior) nodes. Furthermore, the NTLP state is
released and the PATHTEAR message is forwarded towards the NR
(receiver). Note that this PATHTEAR message will not include the
"PDR/PHR" objects.
The behavior of the NF(egress) node related to the modification
procedure is the same as in the NF(interior) nodes. After receiving
the modification NTLP PATH message the RSVPv2-NSLP is processing
either the "PHR_Resource_Request" or "PHR_Release_Request" object.
After that the RSVPv2-NSLP functionality of the NF(egress) node uses
the "PDR_Modification_Request" object and identifies the flow
specification ID and the RSVPv2-NSLP state associated with it.
Subsequently, the RSVPv2-NSLP "e2e service" functionality is
activated and by using the information contained in the
Flow_Specification_Class it will modify the reservation stored into
the RSVPv2-NSLP path state. If the modification is admitted, the
RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
the successful modification procedure to the RSVPv2-NSLP "PDR"
functionality of the NF(ingress) node by using a
"PDR_Modification_Report" PDR object. This object is temporarily
stored until a NslpResvMod message arrives that is carried by a NTLP
RESV message, which was sent by the NR(receiver) and that is
associated with an earlier processed NslpPathMod message. This
"PDR_Modification_Report" PDR object will be included into the
Service_Class object class of arriving NslpResvMod message. The
modification NTLP PATH message is forwarded towards the NR
(receiver). Note that this NTLP PATH message will not include the
"PDR/PHR" object information.
The NF(egress) node can receive a NslpResvMod message, carried by a
NTLP RESV message which was sent by the NR(receiver) and is
associated with an earlier processed NslpPathMod message. The
RSVPv2-NSLP "PDR" functionality of the NF(egress) node will report
the successful modification procedure PDR/PHR procedure to the
RSVPv2-NSLP "PDR" functionality of the NF(ingress) node by using a
"PDR_Modification_Report" PDR object. This object will be included
into the Service_Class object class of the NslpResvMod message. Note
that this message is processed in a NSIS intra-domain only by the
Westberg, et al. Expires October 2003 [Page 54]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF(egress) and NF(ingress) nodes. The NF(interior) nodes are not
processing this message.
During a severe congestion situation marked data packets arrive at
the NF(egress) node. 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
included into a NslpPathErr and transported by a NTLP PATHERROR
message. For each flow ID, the RSVPv2-NSLP 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 RSVPv2-NSLP 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).
5.4.5.2. Bidirectional functionality
The bi-directional reservation functionality supported by the
NF(egress) is similar to a combination of two unidirectional
reservation functionalities that are accomplished in opposite
directions. Such a unidirectional reservation functionality is
described in Section 5.4.5.1. The main differences of the bi-
directional reservation functionality with the combination of two
unidirectional reservation functionalities accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NF(egress) does not process the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the success of the reservation procedure is reported to the NI(sender)
Westberg, et al. Expires October 2003 [Page 55]
Internet Draft Proposal for RSVPv2-NSLP April 2003
using the NslpPathInit that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathRef that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathMod that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the PDR_Reservation_Report object used to report a successful
reservation procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the PDR_Refresh_Report object used to report a successful refresh
procedure is carried by the NslpPathInit that is sent hop-by-hop
from NF(egress) towards the NF(ingress)
* the PDR_Modification_Report object used to report a successful
modification procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the NF(egress) node can initiate an explicit partial release
procedure towards the NF(ingress) node.
5.4.6. NR (NSIS Responder) functionality
The NR (NSIS Responder) functionality can be characterized as
unidirectional and bi-directional reservation functionality.
5.4.6.1. Unidirectional functionality
The unidirectional functionality supported by the NR(receiver) used
in this type of scenarios is identical to the functionality supported
by the NR(receiver) used in the inter-domain signaling scenario (see
Section 5.3.3.1).
5.4.6.2. Bidirectional functionality
The bi-directional functionality supported by the NR(receiver) used
in this type of scenarios is identical to the functionality supported
by the NR(receiver) used in the inter-domain signaling scenario (see
Section 5.3.3.2).
Westberg, et al. Expires October 2003 [Page 56]
Internet Draft Proposal for RSVPv2-NSLP April 2003
6. Example of RSVPv2-NSLP Inter-domain signaling procedures
This section gives a brief description of the main flow diagram used
by the RSVPv2-NSLP protocol for inter-domain signaling procedures.
RSVPv2-NSLP is considered in this section to be optimized for unicast
and sender-initiated protocol. This means that the NslpPathInit
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-NSLP inter-domain signaling
procedures for RSVPv2-NSLP normal operation, i.e., successful
reservation and operation without failures. In this example only the
uni-directional feature is considered and it is assummed that no
intra-domain signaling procedures are used.
Figure 4 shows the main flow diagram used by the RSVPv2-NSLP
protocol. The NI(sender), after creating an NSLP reservation state,
generates an NslpPathInit. The flow ID, the ID of the NSLP protocol
and the time values can be included in the Flow_Specificaton_Class
(e.g., <Session>, <Sender_template>, <Time_Values>, <NSLP_ID>
objects). The session ID and the ID of the NSLP protocol can be
included in the Session_ID_Class (e.g., <Session> and <NSLP_ID>
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 (e.g., <Sender_Tspec> and <Flowspec>
objects).
The NslpPathInit is encapsulated into a NTLP PATH message (see
[RFC2205]). The NTLP PATH message is processed by all NTLP stateful
nodes that is passing through, up to the NR (receiver). Each node
that processes the NTLP PATH message will create a NTLP state and
will activate the RSVPv2-NSLP "e2e service" functionality by using
the transported NslpPathInit information and it will create an
RSVPv2-NSLP reservation state. This RSVPv2-NSLP reservation state
will be associated to a flow ID. Note that the NTLP states have to
store back-ward routing information, which are used by NTLP messages
that are transported hop-by-hop in the backward direction towards the
NI(sender).
When the NR(receiver) receives NslpPathInit the RSVPv2-NSLP "e2e
service" functionality creates an NslpResvInit message that is used
Westberg, et al. Expires October 2003 [Page 57]
Internet Draft Proposal for RSVPv2-NSLP April 2003
to report information related to how the NslpPathInit has been
processed along the path. This NslpResvInit will be encapsulated
into a RESV message and it will only be processed by the RSVPv2-NSLP
"e2e service" functionality at each hop that is passing by and that
is supporting the "e2e service" functionality.
After the successful reception of the NslpResvInit message the
NI(sender) can start transmitting traffic user data.
Figure 4 also shows how the refresh procedure is performed. The
RSVPv2-NSLP refresh procedure is a pure NTLP refresh procedure,
meaning that a refresh NTLP PATH message that is periodically sent
through all the NTLP stateful nodes located between NI (sender) and
NR (receiver). If a NTLP state in a NTLP stateful is not refreshed
on time then the NTLP functionality at this node informs the
RSVPv2-NSLP state that the refresh procedure is unsuccesful. Note
that the refresh NTLP PATH message may optionally carry a NSLPPathRef
message. NR (receiver) will create a refresh NTLP RESV message that
will be sent towards the NI (sender). This message will be used to
report information related to how the NTLP PATH message has been
processed along the path. Note that the refresh NTLP RESV message
may optionally carry a NSLPResvRef message.
Westberg, et al. Expires October 2003 [Page 58]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NI (sender) NF (router) NF (router) NR (receiver)
NTLP stateful NTLP stateful NTLP stateful NTLP stateful
PATH(NslpPathInit) | | |
|------------------->| | |
| | | |
| |PATH(NslpPathInit) | |
| |------------------->| PATH(NslpPathInit) |
| | |------------------->|
| | | RESV(NslpResvInit) |
| | RESV(NslpResvInit) |<-------------------|
| |<-------------------| |
|RESV(NslpResvInit) | | |
|<-------------------| | |
| | Traffic(user) Data | |
|------------------->|------------------->|------------------->|
| | | |
|PATH([NslpPathRef]) | | |
|------------------->| | |
| | | |
| |PATH([NslpPathRef]) | |
| |------------------->|PATH([NslpPathRef]) |
| | |------------------->|
| | | RESV([NslpResvRef])|
| | RESV([NslpResvRef])|<-------------------|
| |<-------------------| |
|RESV([NslpResvRef])| | |
|<-------------------| | |
Figure 4: Inter-domain signaling normal operation for successful
reservation
Figure 5 depicts the RSVPv2-NSLP tearing down procedure. In Figure 5
The RSVPv2-NSLP "e2e service" functionality of the NI(sender) informs
the NTLP functionality of the same node to start a tear down procedure
for the specific flow. A NTLP PATHTEAR message is created that is sent
towards the NR (receiver). This message will tear down all the NTLP and
RSVPv2-NSLP states that are associated with the Session_ID_Class of all
NTLP stateful nodes that process the NTLP PATHTEAR message. Note that
the NTLP PATHTEAR message may optionally carry a NSLPPathTear message.
Westberg, et al. Expires October 2003 [Page 59]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NI (sender) NF (router) NF (router) NR (receiver)
NTLP stateful NTLP stateful NTLP stateful NTLP stateful
|PATHTEAR([NslpPathTear]) | |
|------------------->| | |
| |PATHTEAR([NslpPathTear]) |
| |------------------->|PATHTEAR([NslpPathTear])
| | |------------------->|
Figure 5: Inter-domain signaling normal operation for tearing down a
reservation initiated by NI (sender)
Figure 6 shows the main flow diagram used by the RSVPv2-NSLP protocol in
case of an unsuccessful reservation assuming that no intra-domain
signaling procedures are used. In this situation only the uni-
directional feature is considered. In this situation the NslpPathInit
and NTLP PATH messages are created and transmitted in the same way as
during the successful reservation. The main difference is related to
the fact that one of the NF(routers) is not able to satisfy the
NslpPathInit request. In this situation this RSVPv2-NSLP "e2e service"
functionality of this particular NF(router) will generate an NslpPathErr
to report to NI(sender) that the NslpPath request could not be
satisfied. This NslpPathErr message will be encapsulated into a NTLP
PATHERROR message and it will be sent hop-by-hop towards the NI(sender).
This message will be processed hop-by-hop by the RSVPv2-NSLP "e2e
service" functionality.
NI (sender) NF (router) NF (router) NR (receiver)
NTLP stateful NTLP stateful NTLP stateful NTLP stateful
PATH(NslpPathInit) | | |
|------------------->| | |
| | | |
| | PATH(NslpPathInit) | |
| |------------------->| |
| | | |
| PATHERROR(NslpPathErr) | |
| |<-------------------| |
|PATHERROR(NslpPathErr) | |
|<-------------------| | |
Figure 6: Inter-domain signaling normal operation for unsuccessful
reservation
Westberg, et al. Expires October 2003 [Page 60]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Figure 7 shows the main flow diagram used by the RSVPv2-NSLP 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 NslpPathMod message. This NSLP message
is encapsulated into a NTLP PATH message and it is sent hop-by-hop
towards the NR(receiver). The flow ID of the flow that has to be
modified is included in the Flow_Specificaton_Class. The information
that has to be modified that is included into the Service_Class object
class. (e.g., <Sender_Tspec> and <Flowspec> objects).
The NslpPathMod information is read by each NTLP stateful node that
processes the NTLP PATH message. The RSVPv2-NSLP functionality
identifies the flow that has to be modified by using its flow ID
information carried by the NslpPathMod message. By using the
information contained in the Service_Class, the RSVPv2-NSLP
functionality is modifying the service information stored into the
RSVPv2-NSLP state.
Subsequently the RSVPv2-NSLP "e2e service" functionality at the
NR(receiver) will create an NslpResvMod that will be used to report
information related to how the NslpPathMod message has been processed
along the path. This NslpResvMod message will be encapsulated into a
NTLP RESV message and sent hop-by-hop towards the NI(sender).
When a NSIS node is not able to satisfy a NslpPathMod request the
RSVPv2-NSLP "e2e service" functionality of this node will generate an
NslpPathErr to report to NI(sender) that the NslpPathMod request could
not be satisfied. This message will be encapsulated into a NTLP
PATHERROR message and it will be sent towards the NI(sender). In this
case the "e2e functionality" of any NSIS node will identify the
modification type of the NslpPathErr message. If the modification
procedure required a higher amount of reservation, then the reservation
asociated to the modified flow will have to be reseted to the
reservation or to the amount (or type) of reservation that was stored
before the modification procedure started.
Westberg, et al. Expires October 2003 [Page 61]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NI (sender) NF (router) NF (router) NR (receiver)
NTLP stateful NTLP stateful NTLP stateful NTLP stateful
PATH(NslpPathMod) | | |
|------------------->| | |
| | PATH(NslpPathMod) | |
| |------------------->|PATH(NslpPathMod) |
| | |------------------->|
| | | RESV(NslpResvMod) |
| | RESV(NslpResvMod) |<-------------------|
| |<-------------------| |
| RESV(NslpResvMod) | | |
|<-------------------| | |
Figure 7: Inter-domain signaling normal operation for modification of
reservation
6.2. Normal operation for bi-directional reservation
This section gives one example of inter-domain signaling for a
successful and one example of inter-domain signaling for an
unsuccessful bi-directional reservation. Figure 8 shows the flow
diagram of inter-domain signaling used by the RSVPv2-NSLP protocol in
case of a successful bi-directional reservation.
The bi-directional successful reservation is similar to a combination
of two unidirectional successful reservations that are accomplished
in opposite directions. The main differences of the bi-directional
successful reservation procedure with the combination of two
unidirectional successful reservations accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NSIS aware nodes do not receive the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the success of the reservation procedure is reported to the NI(sender)
using the NslpPathInit that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathRef that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
Westberg, et al. Expires October 2003 [Page 62]
Internet Draft Proposal for RSVPv2-NSLP April 2003
using the NslpPathMod that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
Figure 9 shows the flow diagrams of inter-domain signaling used by
the RSVPv2-NSLP protocol in case of a unsuccessful bi-directional
reservation. The bi-directional unsuccessful reservation is similar
to a combination of two unidirectional unsuccessful reservations that
are accomplished in opposite directions. The main differences of the
bi-directional unsuccessful procedure with the combination of two
unidirectional successful reservations accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NSIS aware nodes do not process the NslpResvInit, NslpResvRef and
NslpResvMod messages
Westberg, et al. Expires October 2003 [Page 63]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NI (sender) NF (router) NF (router) NR (receiver)
NTLP stateful NTLP stateful NTLP stateful NTLP stateful
PATH(NslpPathInit) | | |
|------------------->| | |
| | PATH(NslpPathInit) |
| |---------------------------------------->|
| | | |
| | | PATH(NslpPathInit)|
| | |<-------------------|
| PATH(NslpPathInit) | |
|<----------------------------------------| |
| | | |
| | | |
| | Traffic(user) Data | |
|------------------->|---------------------------------------->|
| | | |
| | Traffic(user) Data | |
|<----------------------------------------|<-------------------|
| | | |
| | | |
|PATH([NslpPathRef]) | | |
|------------------->| | |
| |PATH([NslpPathRef]) | |
| |---------------------------------------->|
| | | |
| | | PATH([NslpPathRef])|
| PATH([NslpPathRef]) |<-------------------|
|<----------------------------------------| |
| | | |
Figure 8: Inter-domain signaling for bi-directional
reservation in case of a successful reservation
Westberg, et al. Expires October 2003 [Page 64]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NI (sender) NF (router) NF (router) NR (receiver)
NTLP stateful NTLP stateful NTLP stateful NTLP stateful
PATH(NslpPathInit) | | |
|------------------->| | |
| | PATH(NslpPathInit) |
| |---------------------------------------->|
| | | |
| | | PATH(NslpPathInit)|
| | |<-------------------|
| | | |
| | PATHERROR(NslpPathErr)|
| | |------------------->|
| | PATHERROR(NslpPathErr) |
| |<----------------------------------------|
| PATHERROR(NslpPathErr) | |
|<-------------------| | |
Figure 9: Inter-domain signaling for bi-directional reservation in case of
an unsuccessful reservation
7. Example of RSVPv2-NSLP Intra-domain signaling procedures
This section gives a brief description of the main flow diagram used
by the RSVPv2-NSLP protocol for intra-domain signaling procedures.
These intra-domain signaling procedures are using the NSIS protocol
which consists of one NTLP level and two NSLP hierarchical levels
(see Figure 2).
Intra-domain signaling is where the RSVPv2-NSLP signaling messages
are originated, processed and terminated within the same domain.
RSVPv2-NSLP is considered in this section to be optimized for unicast
and sender-initiated protocol.
The Intra-domain signaling procedures are mainly using RSVPv2-NSLP
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-NSLP normal operation, i.e., operation without failures.
Westberg, et al. Expires October 2003 [Page 65]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Figure 10 shows the main flow diagram intra-domain signaling used by
the RSVPv2-NSLP protocol in case of a successful reservation. In
this situation only the uni-directional feature is considered. Note
that the same figure shows how the RSVPv2-NSLP inter-domain and
intra-domain signaling can inter-operate. When an NslpPathInit
arrives at the ingress node of a domain, i.e., NF(ingress) (see
Figure 10), the RSVPv2-NSLP "e2e service" functionality creates a
RSVPv2-NSLP Path reservation state. Subsequently, the RSVPv2-NSLP
"PDR" protocol functionality is activated (see Figure 2) classifying
the flow (i.e., Flow_Specification_Class) that is associated with the
NslpPathInit message into an appropriate traffic class, e.g.,
Diffserv class. The RSVPv2-NSLP PDR functionality uses the
RSVPv2-NSLP path state created by the NslpPathInit message and it
introduces additional information that can be used to associate the
PHR and PDR objects with the flow that created the RSVPv2-NSLP Path
reservation state in the NF(ingress) node. The RSVPv2-NSLP PDR
functionality is subsequently using the Service_Class (e.g.,
<SENDER_Tspec> object) and translates the requested bandwidth
parameter into a number of resource units. 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 are locally defined objects which are
included into the Service_Class object class carried by the
NslpPathInit message. The NslpPathInit message is encapsulated into
a NTLP PATH message. The NTLP PATH message is processed by all NTLP
stateless NF(interior) nodes that is passing through, up to the NF
(egress). Each stateless NF(interior) node that processes the NTLP
PATH message it will not create a state but it will activate the
RSVPv2-NSLP functionality by using the transported NslpPathInit
message. The RSVPv2-NSLP "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
NslpPathInit message that contains the "PHR_Resource_Request" object
is the same as in the NF(interior) nodes. After processing the
"PHR_Resource_Request" object, the RSVPv2-NSLP functionality of the
Westberg, et al. Expires October 2003 [Page 66]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF(egress) node uses the "PDR_Reservation_Request" object and
creates/identifies the flow specification ID and the state associated
with it. Subsequently, the RSVPv2-NSLP "e2e service" functionality
is activated and by using the information contained in the
Flow_Specification_Class it will create an RSVPv2-NSLP Path
reservation. The NTLP PATH message is forwarded towards the NR
(receiver), and it will be processed by all NTLP stateful nodes that
is passing through as an inter-domain signaling procedure, see
Section 6. Note that this NTLP PATH message will not include the
"PDR/PHR" object information.
When the NR(receiver) receives the NTLP PATH message, similar to the
procedure used in Section 6, it will create a NTLP state and it will
activate the RSVPv2-NSLP "e2e service" functionality by using the
NslpPathInit message. It will create a RSVPv2-NSLP path reservation
state which will be identified by using the information contained in
the Flow_Specification_Class object class.
Subsequently the RSVPv2-NSLP "e2e service" functionality will create
an NslpResvInit message that will be used to report information
related to how the NslpPathInit has been processed along the path.
This NslpResvInit will be encapsulated into a RESV message and it
will only be processed by the RSVPv2-NSLP "e2e service" functionality
at each hop that is passing by and that is supporting the "e2e
service" functionality. Note that this message is processed in a
domain only by the NF(egress) and NF(ingress) nodes. The NF(interior)
nodes are not processing this message. Moreover, the RSVPv2-NSLP
"PDR" functionality of the NF(egress) node will report the successful
reservation to the RSVPv2-NSLP "PDR" functionality of the NF(ingress)
node by using a "PDR_Reservation_Report" PDR object. This object
will be included into the Service_Class object class of the
NslpResvInit message.
After the successful reception of the NslpResvInit message, the
NI(sender) can start transmitting traffic user data. Figure 10 also
shows how the refresh procedure is performed.
The inter-domain RSVPv2-NSLP refresh procedure is a pure NTLP refresh
procedure, see Section 6. However, the intra-domain RSVPv2-NSLP
refresh procedure is a combination of a NTLP and a RSVPv2-NSLP
"PHR/PDR" procedure. When a refresh NTLP PATH message is received by
a NF(ingress) node the NTLP functionality will activate the
RSVPv2-NSLP "PHR/PDR" functionality that is carried by the
NslpPathRef message. By using the Flow_Specification_Class object
class the "PDR" functionality can identify the RSVPv2-NSLP path
Westberg, et al. Expires October 2003 [Page 67]
Internet Draft Proposal for RSVPv2-NSLP April 2003
state. The RSVPv2-NSLP "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 are
locally defined objects which are included into the Service_Class
object class carried by the NslpPathRef message.
The refresh NTLP PATH message is processed by all NTLP stateless
NF(interior) nodes that is passing through, up to the NF (egress).
Each node that processes the refresh NTLP PATH message it will
refresh the NTLP state associated with the session ID, i.e.,
information included into the Session_ID_Class object class. The
NTLP level functionality of the NTLP stateless NF(interior) nodes
receiving the refresh NTLP PATH message will activate the RSVPv2-NSLP
"PHR" functionality.
The RSVPv2-NSLP "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 refresh NTLP PATH message it
will refresh the NTLP state associated with the session ID included
into the Session_ID_Class object class. Furthermore, it will activate
the RSVPv2-NSLP "PHR" functionality by using the transported
RSVPv2-NSLP "PHR" object.
The behavior of the RSVPv2-NSLP "PHR" functionality in the NF(egress)
node is similar to the RSVPv2-NSLP "PHR" functionality provided in
the NF(interior) nodes.
Subsequently, the refresh NTLP PATH message is forwarded towards the
NR (receiver), and it will be processed by all NTLP stateful nodes
that is passing through as an inter-domain signaling procedure, see
Section 6. Note that this refresh NTLP PATH message will not include
the "PDR/PHR" objects.
When the NF(responder) receives the refresh NTLP PATH message, it
will refresh the NTLP state and it will invoke the RSVPv2-NSLP "e2e
service" functionality.
If a NTLP state in a NTLP stateful is not refreshed on time then the
Westberg, et al. Expires October 2003 [Page 68]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NTLP functionality at this node informs the RSVPv2-NSLP state that
the refresh procedure is unsuccessful.
Note that the refresh NTLP PATH message may optionally carry a
NSLPPathRef message. NR (receiver) will create a NTLP RESV message
that will be sent towards the NI (sender). This message will be used
to report information related to how the NTLP PATH message has been
processed along the path. Note that the refresh NTLP RESV message
may optionally carry a NSLPResvRef message. Note that this message is
processed in a domain only by the NF(egress) and NF(ingress) nodes.
The NF(interior) nodes are not processing this message. Moreover,
the RSVPv2-NSLP "PDR" functionality of the NF(egress) node will
report the successful refresh PDR/PHR procedure to the RSVPv2-NSLP
"PDR" functionality of the NF(ingress) node by using a
"PDR_Refresh_Report" PDR object. This object will be included into
the Service_Class object class of the NslpResvRef message.
Westberg, et al. Expires October 2003 [Page 69]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
PATH(NslpPathInit) | | |
--->|PATH(NslpPathInit): | | |
|PHR_Resource_Request| | |
|PDR_ResReq |PATH(NslpPathInit): | |
|------------------->|PHR_Resource_Request| |
| |PDR_ResReq |PATH(NslpPathInit): |
| |------------------->|PHR_Resource_Request|
| | |PDR_ResReq |
| | |------------------->|
| | | PATH(NslpPathInit)
| | | |----->
| | | RESV(NslpResvInit)
| | | |<------
| |RESV (NslpResvInit) | |
| |PDR_Reservation_Report |
|<-------------------------------------------------------------|
RESV(NslpResvInit) | | |
<---| | | |
| | Traffic(user) Data | |
--->|------------------->|------------------->|------------------->|--->
| | | |
PATH([NslpPathRef]) | | |
--->| | | |
PATH(NslpPathRef): | | |
|PHR_Refresh_Update | | |
|PDR_RefReq |PATH(NslpPathRef): | |
|------------------->|PHR_Refresh_Update | |
| |PDR_RefReq |PATH(NslpPathRef):
| |------------------->|PHR_Refresh_Update |
| | |PDR_RefReq |
| | |------------------->|
| | | PATH([NslpPathRef])
| | | |----->
| | | RESV([NslpResvRef])
| | | |<------
| |RESV(NslpResvRef): | |
| |PDR_Refresh_Report | |
|<-------------------------------------------------------------|
RESV ([NslpResvRef]) | | |
<---| | | |
(PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
This PDR object is processed only by the
Westberg, et al. Expires October 2003 [Page 70]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF(ingress) and NF(egress) nodes.
(PDR_RefReq) - represents the PDR_Refresh_Request PDR object
This PDR object is processed only by the NF(ingress) and
NF(egress) nodes.
Figure 10: Intra-domain signaling normal operation for successful
reservation
Figure 11 depicts the intra-domain RSVPv2-NSLP tearing down
procedure. A NTLP PATHTEAR message, is received by the NTLP
functionality in the NF(ingress) node. Note that the NTLP PATHTEAR
message may optionally carry a NSLPPathTear message. The NTLP
functionality activates the RSVPv2-NSLP "PDR/PHR" functionality, that
is related to the Session_ID_Class class object, and that is using
the "PDR" object. The RSVPv2-NSLP "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 are locally defined objects which are
included into the Service_Class object class carried by a
NslpPathTear message. All the RSVPv2-NSLP and NTLP reservations, in
the NF(ingress) node that are associated to the Session_ID_Class
object class will be released. The NTLP PATHTEAR message is
processed by all NTLP stateless NF(interior) nodes that is passing
through, up to the NF (egress). Each node that processes the PATHTEAR
message will activate the RSVPv2-NSLP "PHR" functionality by using
the transported RSVPv2-NSLP "PHR" object. The NTLP functionality in
the NTLP stateless NF(interior) node that receives the PATHTEAR
message will pass the NslpPathTear message to the RSVPv2-NSLP
functionality. The NslpPathTear message contains the
"PHR_Release_Request" and "PDR_Release_Request" PHR and PDR objects,
respectively.
The RSVPv2-NSLP "PHR" functionality of this NF(interior) node 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 PATHTEAR message it will it
Westberg, et al. Expires October 2003 [Page 71]
Internet Draft Proposal for RSVPv2-NSLP April 2003
will activate the RSVPv2-NSLP "PHR" functionality by using the
transported "PHR" object.
The behavior of the RSVPv2-NSLP "PHR" functionality in the NF(egress)
node is similar to the RSVPv2-NSLP "PHR" functionality provided in
the NF(interior) nodes. Furthermore, the NTLP state is released and
the PATHTEAR message is forwarded towards the NR (receiver), and it
will be processed by all NTLP stateful nodes that is passing through
as an inter-domain signaling procedure, see Section 6. Note that
this PATHTEAR message will not include the "PDR/PHR" objects.
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
| | Traffic(user) Data | |
-->|------------------->|------------------->|------------------->|--->
| | | |
PATHTEAR([NslpPathTear])| | |
-->| | | |
PATHTEAR(NslpPathTear): | |
|PHR_Release_Request | | |
|PDR_RelReq |PATHTEAR(NslpPathTear): |
|------------------->|PHR_Release_Request |
| |PDR_RelReq PATHTEAR(NslpPathTear):
| |------------------->|PHR_Release_Request |
| | |PDR_RelReq |
| | |------------------->|
| | | PATHTEAR([NslpPathTear])
| | | |----->
(PDR_RelReq) - represents the PDR_Release_Request object. This object is
processed only by the NF(ingress) and NF(egress) nodes.
Figure 11: Intra-domain signaling normal operation for explicit release
Figure 12 shows the main intra-domain flow diagram used by the
RSVPv2-NSLP protocol in case of an unsuccessful reservation. In this
situation only the uni-directional feature is considered. In this
situation the RSVPv2-NSLP and NTLP messages are created and
transmitted in the same way as during the successful reservation.
The main difference is related to the fact that one of the NTLP
stateless NF(interior) is not able to satisfy the request carried by
the "PHR_Resource_Request" PHR object. The RSVPv2-NSLP "PHR"
functionality of this NF(interior) node will mark the "M" field of
Westberg, et al. Expires October 2003 [Page 72]
Internet Draft Proposal for RSVPv2-NSLP April 2003
the "PHR_Resource_Request" object. The RSVPv2-NSLP "PHR"
functionality will also include the number of previous NF(interior)
nodes that successfully processed the RSVPv2-NSLP
"PHR_Resource_Request" PHR object (see Appendix). This number can,
for example, be identified by the TTL (Time-To-Live) value included
in the IP header of the received NTLP PATH message. Note that each
time that an IP packet passes a 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 message in the
PDR state associated to the NTLP PATH message. In case of an
unsuccessful 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) of a receiving "PDR" reporting object.
The PDR_TTL field is generated and sent by a NF(interior) node that
could not successfully 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, rejected the "PHR_Resource_Request" 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 NTLP PATH 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) is
set to "1". These "PHR" and "PDR" objects are included in the
NslpPathInit message. The NslpPathInit message is encapsulated into
a NTLP PATH message.
This NslpPathInit message is sent towards the NF(egress) node, which
will be transported by a NTLP PATH message. Any NF(interior) node
receiving a PATH message will activate the RSVPv2-NSLP "PHR"
functionality. If the "PHR_Resource_Request" PHR object is "M"
marked, then the RSVPv2-NSLP "PHR" functionality will not further
process the "PHR" object. The NF(egress) node receiving a NTLP PATH
message will activate the RSVPv2-NSLP "PHR" functionality. If the
"PHR_Resource_Request" PHR object is "M" marked, then the RSVPv2-NSLP
"PHR" functionality will activate the RSVPv2-NSLP "PDR" functionality
which 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 NslpPathErr message. The NslpPathErr
message will be encapsulated into a NTLP PATHERROR message. The
Westberg, et al. Expires October 2003 [Page 73]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NslpPathError message will only be processed by the NF(ingress) node.
The NTLP functionality of the NF(ingress) node that receives the
PATHERROR message will activate the RSVPv2-NSLP "PDR" functionality.
Due to the "M" marked "PDR_Reservation_Report" object the "PDR"
functionality will activate the RSVPv2-NSLP "e2e service". The
RSVPv2-NSLP "e2e service" functionality of the NF(ingress) node will
generate a NslpPathErr message that will be sent hop-by-hop to the
NI(sender) and will be encapsulated into a NTLP PATHERROR message.
This message will inform the NI(sender) that the reservation request
was not successful.
Simultaneously, the NF(ingress) node will start a partial explicit
release procedure, for releasing the unnecessarily reserved RSVP-NSLP
resources in some interior nodes for the rejected flow. In this
case, the RSVP-NSLP "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 RSVPv2-NSLP "PDR" functionality will create the
"PDR_Reservation_Request" PDR object.
The RSVPv2-NSLP "PDR" functionality of the NF(ingress) node can
calculate the number of NF(interior) nodes that processed and
reserved RSVPv2-NSLP resources.
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 RSVPv2-NSLP state.
This calculated value will be included in the TTL - IP header field
of the NTLP PATHTEAR message which is generated by the NF(ingress)
node and which transports the "PHR_Resource_Release" object. The
"PHR_Release_Request" and "PDR_Release_Request" objects are included
into a NslpPathTear message. The NslpPathTear message is transported
by a NTLP PATHTEAR message.
The RSVPv2-NSLP "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 NTLP PATHTEAR message is decremented
by one. When this value becomes zero, the "PHR_Resource_Release"
object reached the interior node that marked the
"PHR_Resource_Request" object and it will be dropped. This means that
Westberg, et al. Expires October 2003 [Page 74]
Internet Draft Proposal for RSVPv2-NSLP April 2003
this PHR object will not release any resources in this node.
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
PATH(NslpPathInit) | | |
--->|PATH(NslpPathInit): | | |
|PHR_Resource_Request| | |
|PDR_ResReq |PATH(NslpPathInit): | |
|------------------->|PHR_Resource_Request| |
| |PDR_ResReq |PATH(NslpPathInit): |
| |------------------->M PHR_Resource_Request (M
| | M marked)
| | M PDR_ResReq |
| | M------------------->|
| |PATHERROR(NslpPathErr): |
| |PDR_Reservation_Report |
|<-------------------------------------------------------------|
PATHERROR(NslpPathErr) | | |
<---| | | |
|PATHTEAR(NslpPathTear): | |
|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 12: Intra-domain signaling normal operation for unsuccessful
reservation
Figure 11 and Figure 12 show the intra-domain main flow diagram used
by the RSVPv2-NSLP protocol for a modification of a reservation
procedure. In this situation only the uni-directional feature is
considered.
The request for modification of the reservation is included into the
NslpPathMod message. A NTLP PATH message that encapsulates the
NslpPathMod message is received by the NTLP functionality of the
NF(ingress) node. The NTLP functionality activates the RSVP-NSLP
"PDR/PHR" functionality, which is associated with the
Westberg, et al. Expires October 2003 [Page 75]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Session_ID_Class object class. When the modification request
requires an increase on the number of reserved resources stored in
the RSVPv2-NSLP state (see Figure 13), then the RSVPv2-NSLP "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 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 in the RSVPv2-NSLP
state should also be replaced with the number of resources included
in the modification request.
The RSVPv2-NSLP "PDR" functionality will create a
"PDR_Modification_Request" PDR object. These two objects will be
included into the Service_Class of the NslpPathMod message.
The RSVPv2-NSLP "PHR" functionality of each stateless NF(interior)
node processes the PHR object as a "PHR_Resource_Request" object.
Each stateless NF(interior) node that receives the modification NTLP
PATH message will activate the RSVPv2-NSLP "PHR" functionality. If a
RSVPv2-NSLP "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 RSVPv2-NSLP PHR and
PDR protocol functionality associated with an unsuccessful
reservation procedure will be applied for this case (see Figure 12).
The behavior of the NF(egress) node related to the modification
procedure is the same as in the NF(interior) nodes. After processing
the "PHR_Resource_Request" object, the RSVPv2-NSLP functionality of
the NF(egress) node uses the "PDR_Modification_Request" object and
identifies the flow specification ID and the RSVPv2-NSLP state
associated with it. Subsequently, the RSVPv2-NSLP "e2e service"
functionality is activated and by using the information contained in
the Flow_Specification_Class it will modify the reservation stored
into the RSVPv2-NSLP path state.
The NTLP PATH message is forwarded towards the NR (receiver), and it
will be processed by all NTLP stateful nodes that is passing through
as an inter-domain signaling procedure, see Section 6. Note that
this NTLP PATH message will not include the "PDR/PHR" object
information.
When the NR(receiver) receives the NTLP PATH message, similar to the
procedure used in Section 6, it will create a it will activate the
Westberg, et al. Expires October 2003 [Page 76]
Internet Draft Proposal for RSVPv2-NSLP April 2003
RSVPv2-NSLP "e2e service" functionality by using the NslpPathMod
message. By using the information contained in the
Flow_Specification_Class it will modify the reservation stored into
the RSVPv2-NSLP path state.
Subsequently the RSVPv2-NSLP "e2e service" functionality will create
an NslpResvMod message that will be used to report information
related to how the NslpPathMod has been processed along the path.
This NslpResvMod will be encapsulated into a RESV message and it will
only be processed by the RSVPv2-NSLP "e2e service" functionality at
each hop that is passing by and that is supporting the "e2e service"
functionality. Note that this message is processed in a domain only
by the NF(egress) and NF(ingress) nodes. The NF(interior) nodes are
not processing this message. Moreover, the RSVPv2-NSLP "PDR"
functionality of the NF(egress) node will report the successful
reservation to the RSVPv2-NSLP "PDR" functionality of the NF(ingress)
node by using a "PDR_Modification_Report" PDR object. This object
will be included into the Service_Class object class of the
NslpResvMod message.
Westberg, et al. Expires October 2003 [Page 77]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
PATH(NslpPathMod) | | |
--->|PATH(NslpPathMod): | | |
|PHR_Resource_Request| | |
|PDR_ModReq |PATH(NslpPathMod): | |
|------------------->|PHR_Resource_Request| |
| |PDR_ModReq |PATH(NslpPathMod): |
| |------------------->|PHR_Resource_Request|
| | |PDR_ModReq |
| | |------------------->|
| | | PATH(NslpPathMod)
| | | |----->
| | | RESV(NslpResvMod)
| | | |<------
| |RESV (NslpResvMod) | |
| |PDR_Modification_Report |
|<-------------------------------------------------------------|
RESV(NslpResvMod) | | |
<---| | | |
(PDR_ModReq*) - represents the "PDR_Modification_Request" PDR object.
This PDR object is processed only by the
NF(ingress) and NF(egress) nodes.
Figure 13: 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 RSVPv2-NSLP path state (see Figure
14), then the RSVPv2-NSLP "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
RSVPv2-NSLP "PHR_Release_Request" PHR object. Furthermore, the
number of resources that were reserved in the RSVPv2-NSLP path state
for a certain flow should also be replaced with the number of
resources included in the modification request. The RSVPv2-NSLP
"PDR" functionality will create a "PDR_Modification_Request" PDR
object. These two objects will be encapsulated into a modification
Westberg, et al. Expires October 2003 [Page 78]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NTLP PATH message. This message will be sent towards the NF(egress)
node. The RSVPv2-NSLP "PHR" functionality of each NF node processes
the PHR object as a "PHR_Resource_Release" object. Each NF(interior)
node that receives the modification NTLP PATH message will activate
the RSVPv2-NSLP "PHR" functionality. The RSVPv2-NSLP "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 behavior of the NF(egress) node related to the modification
procedure is the same as in the NF(interior) nodes. After processing
the "PHR_Resource_Request" object, the RSVPv2-NSLP functionality of
the NF(egress) node uses the "PDR_Modification_Request" object and
identifies the flow specification ID and the RSVPv2-NSLP state
associated with it. Subsequently, the RSVPv2-NSLP "e2e service"
functionality is activated and by using the information contained in
the Flow_Specification_Class, it will modify the reservation stored
into the RSVPv2-NSLP path state.
The rest part of the modification procedure depicted in Figure 14 is
identical to the one described earlier and depicted in Figure 13.
Westberg, et al. Expires October 2003 [Page 79]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
PATH(NslpPathMod) | | |
--->|PATH(NslpPathMod): | | |
|PHR_Resource_Release| | |
|PDR_ModReq |PATH(NslpPathMod): | |
|------------------->|PHR_Resource_Release| |
| |PDR_ModReq |PATH(NslpPathMod): |
| |------------------->|PHR_Resource_Release|
| | |PDR_ModReq |
| | |------------------->|
| | | PATH(NslpPathMod)
| | | |----->
| | | RESV(NslpResvMod)
| | | |<------
| |RESV (NslpResvMod) | |
| |PDR_Modification_Report |
|<-------------------------------------------------------------|
RESV(NslpResvMod) | | |
<---| | | |
(PDR_ModReq*) - represents the PDR_Modification_Request object. This
object is processed only by the NF(ingress) and NF(egress)
nodes.
Figure 14: 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
errors in the network, such as loss of NTLP 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 October 2003 [Page 80]
Internet Draft Proposal for RSVPv2-NSLP April 2003
7.2.1. Loss of NTLP signalling messages
The NTLP 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_Resource_Request" object is
provided by using the functionality provided by the RSVPv2-NSLP "PDR"
functionality located in the NF(ingress) node. The RSVPv2-NSLP "PDR"
functionality of the NF(ingress) node sends the
"PHR_Resource_Request" object towards the NF(egress) node and 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. The reliable deliver of the
"PHR_Refresh_Update" object is provided in a similar way. A timer at
the NF(ingress) node is started when the "PHR_Refresh_Update" is sent
towards the NF(egress) node. If the reply, e.g., "PDR_Refresh_Report"
object, does not arrive in a predefined time it assumes that the
"PHR_Refresh_Update" 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 October 2003 [Page 81]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 15). 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 included into a
NslpPathErr and transported by a NTLP PATHERROR message. For each
flow ID, the RSVPv2-NSLP 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 RSVPv2-NSLP 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 RSVPv2-NSLP 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
included into the Service_Class of the NslpPathTear message. This
Westberg, et al. Expires October 2003 [Page 82]
Internet Draft Proposal for RSVPv2-NSLP April 2003
message will be transported by a NTLP PATHTEAR message towards the
NF(egress). Furthermore, the RSVPv2-NSLP "e2e service" functionality
in the NF(ingress) node will create a NslpPathErr that will be
encapsulated into a PathError that will be sent towards the
NI(sender) to notify that an error occured.
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
(sent)
user|(sent) user data | | |
data| | | |
---->|------------------>| (sent) user data | user data |
| |------------------->S(# marked bytes) |
| | S------------------->|
| | S(# unmarked bytes) |
| | S------------------->|
| |PATHERROR(NslpPathErr): |
| PDR_Congestion_Report ("S" marked + Pdrop) |
|<------------------|--------------------|--------------------|
Terminate | | |
flow?| | | |
Yes PATHTEAR(NslpPathTear): | |
|PHR_Release_Request| | |
|PDR_RelReq |PATHTEAR(NslpPathTear): |
|------------------>|PHR_Release_Request |
| |PDR_RelReq | PATHTEAR(NslpPathTear):
| |------------------->|PHR_Release_Request |
| | |PDR_RelReq |
| | |------------------->|
| | | |
| | | |
PathErr(NslpPathErr) | | |
<----| | | |
Figure 15: 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.
Westberg, et al. Expires October 2003 [Page 83]
Internet Draft Proposal for RSVPv2-NSLP April 2003
7.3. Example of Adaptation to load sharing operation
This procedure has to be based on the solutions provided by the NTLP
protocol level on this issue. These NTLP protocol level solutions are
not yet defined. Therefore, this procedure will be specified in a
future version of this draft.
7.4. Normal operation for bi-directional reservation
There are situations where, for example, the inter-domain signaling
has to support in addition to the unidirectional reservations also
bi-directional reservations. This section gives one example of inter-
domain signaling for a successful and one example of inter-domain
signaling for an unsuccessful bi-directional reservation.
Figure 16 shows the flow diagram of intra-domain signaling used by
the RSVPv2-NSLP protocol and the way how the RSVPv2-NSLP inter-domain
and intra-domain signaling inter-operates in case of a successful bi-
directional reservation.
The bi-directional successful reservation is similar to a combination
of two unidirectional successful reservations that are accomplished
in opposite directions. The main differences of the bi-directional
successful reservation procedure with the combination of two
unidirectional successful reservations accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NSIS aware nodes do not process the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the success of the reservation procedure is reported to the NI(sender)
using the NslpPathInit that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathRef that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the success of the refresh procedure is reported to the NI(sender)
using the NslpPathMod that is sent hop-by-hop from NR(receiver)
towards the NI(sender)
* the PDR_Reservation_Report object used to report a successful
reservation procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
Westberg, et al. Expires October 2003 [Page 84]
Internet Draft Proposal for RSVPv2-NSLP April 2003
* the PDR_Refresh_Report object used to report a successful refresh
procedure is carried by the NslpPathInit that is sent hop-by-hop
from NF(egress) towards the NF(ingress)
* the PDR_Modification_Report object used to report a successful
modification procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the NF(egress) node can initiate an explicit partial release
procedure towards the NF(ingress) node.
Figure 17 and Figure 18 show the flow diagrams of intra-domain
signaling used by the RSVPv2-NSLP protocol and the way how the
RSVPv2-NSLP inter-domain and intra-domain signaling inter-operates in
case of a unsuccessful bi-directional reservation.
The bi-directional unsuccessful reservation is similar to a
combination of two unidirectional unsuccessful reservations that are
accomplished in opposite directions. The main differences of the bi-
directional unsuccessful procedure with the combination of two
unidirectional successful reservations accomplished in opposite
directions are as follows:
* the reservation state specifies a bi-directional reservation
* the Service_Class object specifies that the reservation is
bi-directional
* the NSIS aware nodes do not process the NslpResvInit, NslpResvRef and
NslpResvMod messages
* the PDR_Reservation_Report object used to report a successful
reservation procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the PDR_Refresh_Report object used to report a successful refresh
procedure is carried by the NslpPathInit that is sent hop-by-hop
from NF(egress) towards the NF(ingress)
* the PDR_Modification_Report object used to report a successful
modification procedure is carried by the NslpPathInit that is sent
hop-by-hop from NF(egress) towards the NF(ingress)
* the NF(egress) node can initiate an explicit partial release
procedure towards the NF(ingress) node.
Westberg, et al. Expires October 2003 [Page 85]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
PATH(NslpPathInit) | | |
--->| | | |
|PATH(NslpPathInit): | | |
|PHR_Resource_Request| | |
|PDR_ResReq | PATH(NslpPathInit): |
|------------------->| PHR_Resource_Request |
| | PDR_ResReq | |
| |---------------------------------------->|
| | | PATH(NslpPathInit)
| | | |-->
| | PATH(NslpPathInit): |
| | PDR_Reservation_Report |
| | PHR_Resource_Request PATH(NslpPathInit)
| PATH(NslpPathInit): PDR_ResReq |<---
| PDR_Reservation_Report | |
| PHR_Resource_Request |<-------------------|
| PDR_ResReq | | |
|<----------------------------------------| |
| | | |
| | | |
| | Traffic(user) Data | |
---|------------------->|---------------------------------------->|--->
| | Traffic(user) Data | |
<--|<----------------------------------------|<-------------------|----
| | | |
PATH(NslpPathRef) | | |
--->| | | |
|PATH([NslpPathRef]):| | |
|PHR_Refresh_Update | | |
|PDR_Refreq | PATH([NslpPathRef]): |
|------------------->| PHR_Refresh_Update |
| | PDR_Refreq |
| |---------------------------------------->|
| | | PATH([NslpPathRef])
| | PATH([NslpPathRef]): |--->
| | PDR_Refresh_Report |
| | PHR_Refresh_Update PATH([NslpPathRef])
| | PDR_Refreq |<---
| PATH([NslpPathRef]): |<-------------------|
| PHR_Refresh_Report | |
| PHR_Resource_Request | |
| PDR_ResReq | |
Westberg, et al. Expires October 2003 [Page 86]
Internet Draft Proposal for RSVPv2-NSLP April 2003
|<----------------------------------------| |
PATH([NslpPathRef]) | | |
<--| | | |
(PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
This PDR object is processed only by the
NF(ingress) and NF(egress) nodes.
(PDR_RefReq) - represents the PDR_Refresh_Request PDR object
This PDR object is processed only by the NF(ingress) and
NF(egress) nodes.
Figure 16: Intra-domain signaling normal operation for successful
bi-directional reservation
Westberg, et al. Expires October 2003 [Page 87]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
PATH(NslpPathInit) | | |
--->| | | |
|PATH(NslpPathInit): | | |
|PHR_Resource_Request| | |
|PDR_ResReq | PATH(NslpPathInit): |
|------------------->M PHR_Resource_Request |
| M PDR_ResReq | |
| M---------------------------------------->|
| PATHERROR(NslpPathErr): | |
| PDR_Reservation_Report | |
|<-------------------------------------------------------------|
PATHERROR(NslpPathErr) M | |
<--| M | |
|PATHTEAR(NslpPathTear): | |
|PHR_Release_Request M | |
|PDR_RelReq M | |
|------------------->M | |
(PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
This PDR object is processed only by the
NF(ingress) and NF(egress) nodes.
(PDR_RefReq) - represents the PDR_Refresh_Request PDR object
This PDR object is processed only by the NF(ingress) and
NF(egress) nodes.
(PDR_RelReq) - represents the PDR_Release_Request PDR object
This PDR object is processed only by the NF(ingress) and
NF(egress) nodes.
Figure 17: Intra-domain signaling normal operation for unsuccessful
bi-directional reservation (rejection on path NF(ingress)
towards NF(egress))
Westberg, et al. Expires October 2003 [Page 88]
Internet Draft Proposal for RSVPv2-NSLP April 2003
NF (ingress) NF (interior) NF (interior) NF (egress)
NTLP stateful NTLP stateless NTLP stateless NTLP stateful
| | | |
PATH(NslpPathInit) | | |
--->| | | |
|PATH(NslpPathInit): | | |
|PHR_Resource_Request| | |
|PDR_ResReq | PATH(NslpPathInit): |
|------------------->| PHR_Resource_Request |
| | PDR_ResReq | |
| |---------------------------------------->|
| | | PATH(NslpPathInit)
| | | |-->
| | PATH(NslpPathInit): |
| | PHR_Reservation_Report |
| PATH(NslpPathInit): PHR_Resource_Request PATH(NslpPathInit)
| PDR_Reservation_Report PDR_ResReq |<---
| PHR_Resource_Request M<-------------------|
| PDR_ResReq | M |
|<----------------------------------------M |
| PATHERROR(NslpPathErr): M |
| PDR_Reservation_Report M |
|------------------------------------------------------------->|
| | M PATHERROR(NslpPathErr)
| | M |-->
| | M PATHTEAR(NslpPathTear):
| | M PHR_Release_Request
| | M PDR_Relreq
| | M<-------------------|
| PATHERROR(NslpPathErr): M |
| PDR_Reservation_Report M |
|<-------------------------------------------------------------|
PATHERROR(NslpPathErr) | M |
<--| | M |
|PATHTEAR(NslpPathTear): M |
|PHR_Release_Request | M |
|PDR_RelReq | PATHTEAR(NslpPathTear): |
|------------------->| PHR_Release_Request |
| | PDR_RelReq M |
| |---------------------------------------->|
(PDR_ResReq) - represents the "PDR_Reservation_Request" PDR object.
This PDR object is processed only by the
NF(ingress) and NF(egress) nodes.
(PDR_RefReq) - represents the PDR_Refresh_Request PDR object
Westberg, et al. Expires October 2003 [Page 89]
Internet Draft Proposal for RSVPv2-NSLP April 2003
This PDR object is processed only by the NF(ingress) and
NF(egress) nodes.
(PDR_RelReq) - represents the PDR_Release_Request PDR object
This PDR object is processed only by the NF(ingress) and
NF(egress) nodes.
Figure 18: Intra-domain signaling normal operation for unsuccessful
bi-directional reservation (rejection on path NF(egress)
towards NF(ingress))
8. Appendix - Examples of PHR and PDR object specifications
This appendix provides examples of how PHR and PDR objects could be
specified.
8.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 19. 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.
0 31
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Length(bytes) | Class-Num | C-Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| Unused |P-LEN| P-ID |S|M| C |T|Unused|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Requested Resources | Delta T | Shared % |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Figure 19: 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.
Westberg, et al. Expires October 2003 [Page 90]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 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.
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"
Westberg, et al. Expires October 2003 [Page 91]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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
RSVPv2-NSLP 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.
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
Westberg, et al. Expires October 2003 [Page 92]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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.
8.2. PDR objects
The format of the PDR object that is based on the IPv4 version is
depicted in Figure 20. 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 October 2003 [Page 93]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 20: 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 October 2003 [Page 94]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 RSVPv2-NSLP 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 RSVPv2-NSLP 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 October 2003 [Page 95]
Internet Draft Proposal for RSVPv2-NSLP April 2003
"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. specifies 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 October 2003 [Page 96]
Internet Draft Proposal for RSVPv2-NSLP April 2003
EP-Type: 4-bit field. Identifies the used external protocol.
(External Only useful 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 specifies the flow ID used
by the PDR state.
Variable : variable length field. It can be used either for
Westberg, et al. Expires October 2003 [Page 97]
Internet Draft Proposal for RSVPv2-NSLP April 2003
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 21. 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 21: PDR object format based on IPv6
9. References
[BrLi01] Braden, R., Lindell, B., "A Two-Level Architecture for
Internet Signaling", Internet Draft (work in progress),
2001.
[Bru03] Brunner, M., "Requirements for QoS Signaling Protocols",
draft-ietf-nsis-req-06.txt (work in progress), 2003
[CsTa02] Csaszar, A., Takacs, A., Szabo, R., Rexhepi, V.,
Westberg, et al. Expires October 2003 [Page 98]
Internet Draft Proposal for RSVPv2-NSLP April 2003
Karagiannis, G., "Severe Congestion Handling
with Resource Management in Diffserv On Demand",
submitted to Networking 2002, May 19-24 2002,
Pisa - ITALY.
[Hanc03] Hancock, R., Freytsis, I., Karagiannis, G., Loughney, J.,
Van den Bosch, S., "Next Steps in Signaling: Framework",
Internet Draft, 2003, 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 October 2003 [Page 99]
Internet Draft Proposal for RSVPv2-NSLP April 2003
"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.,"ResourceReservation Issues in
Cellular Radio Access Networks", Internet Draft,
draft-westberg-rmd-cellular-issues-01.txt, Work
in Progress, June 2002.
[WeKa03] Westberg, L., Karagiannis, G., Rexhepi, V.,
"Using RSVPv1 as NTLP (NSIS Transport layer Protocol):
suggestions for modifications on RFC2205", Internet
Draft, Work in Progress,
draft-westberg-nsis-rsvp-as-ntlp-01.txt, February 2003.
Westberg, et al. Expires October 2003 [Page 100]
Internet Draft Proposal for RSVPv2-NSLP April 2003
10. Authors' Addresses
Lars Westberg
Ericsson Research
Torshamnsgatan 23
SE-164 80 Stockholm
Sweden
EMail: Lars.Westberg@era.ericsson.se
Attila Bader
Traffic Lab
Ericsson Hungary Ltd.
Laborc u. 1
H-1037 Budapest
Hungary
EMail: Attila.Bader@eth.ericsson.se
Georgios Karagiannis
University of Twente
P.O. BOX 217
7500 AE Enschede
The Netherlands
EMail: karagian@cs.utwente.nl
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 October 2003 [Page 101]
| PAFTECH AB 2003-2026 | 2026-04-24 04:49:06 |