Internet DRAFT - draft-fujikawa-ric-srsvp
draft-fujikawa-ric-srsvp
INTERNET DRAFT FUJIKAWA Kenji
draft-fujikawa-ric-srsvp-00.txt SHENG I
Kyoto University
GOTO Yukinori
Kyushu University
Real Internet Consortium
1 February 1999
Simple Resource ReSerVation Protocol (SRSVP)
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.
Abstract
This draft describes Simple Resource ReSerVation Protocol (SRSVP),
which implements multicasting, resource reservation and charging in
the Internet.
1. Introduction
Simple Resource ReSerVation Protocol (SRSVP) is an extension of
Resource ReSerVation Protocol (RSVP) [RSVP], and the purposes of it is
as follows:
* Multicasting
* Resource reservation
FUJIKAWA Kenji Expires on 1 June [Page 1]
INTERNET DRAFT SRSVP February 2000
* Charging
SRSVP creates multicast flows and resource-reserved flows (QoS flows).
The state of a QoS flow is hard-state.
SRSVP implements both of unicast and multicast resource reservations
by a method of receiver-initiated resource reservation.
1.1 Specification of QoS
Quality of Services (QoSes) specified by hosts are defined in [SS].
1.2 Terminology
Session
A Session is identified by a protocol number, a destination
address and a destination port.
Sender Template
A sender template is identified by a source address and a
source port.
Flow
A flow is a unit of resource reservation. There are two type of
flows, a uni-source flow and a multi-source flow.
Uni-source flow
A flow is identified by a session and a sender template.
Currently, a flow is regarded as a uni-source one when the
destination address of its session is unicast.
Multi-source flow
A flow is identified by a session. Currently, a flow is
regarded as a multi-source one when the destination address of
its session is multicast.
Rendezvous Point (RVP)
A sender which forwards data in the case of a multi-source
flow. It is generally an application gateway, and does not have
to be a router.
State of a flow
State of a flow that a router manages. This includes incoming
interfaces of Resv/Path and outgoing interfaces of Resv/Path.
Routing Entry
The information for forwarding a packet which incomes from a
certain interface to a defined interface. An entry of a routing
FUJIKAWA Kenji Expires on 1 June [Page 2]
INTERNET DRAFT SRSVP February 2000
table.
Area Information
A router advertises information of addresses and charging as
area information. Area information is global. See [HQLIP] for
details.
Link Information
A link links an area to another area. A router advertises a
metric and QoS parameters of bandwidth and delay as link
information. Link information is global. There are two types of
link information, external link information and internal link
information. See [HQLIP] for details.
Sender Tspec (Tspec)
Specification of traffic that a sender specifies.
Flowspec
Specification of traffic that a receiver requests for. A
resource reservation is not established unless Flowspec and
Tspec are the same.
Path QoS (PQ)
A PQ shows link information at a link from the viewpoint of a
reservation when the reservation is established. Assuming that
a link of 10Kpps/50msec exists, a reservation is 3Kpps/50msec,
and the link advertises 8Kpps/100msec as a result. In this
case, the PQ shows 10Kpps/50msec is available. A PQ is local
for each reservation.
First Aggregated QoS (FAQ)
Receivers and en-route routers may not get information around a
sender or an RVP. A FAQ is a set of calculated QoSes from a
sender or an RVP to centers of the areas containing it, and is
sent to the receivers and en-route routers. A FAQ is local for
each reservation.
Policy
A policy defined in SRSVP is for charging, and specifies for
which areas a sender should pay according to a certain
reservation.
1.3 Main Differences from RSVP
The main differences between SRSVP and RSVP are:
* hard-state,
* including a multicast mechanism based on rendezvous points,
* including a charging function,
FUJIKAWA Kenji Expires on 1 June [Page 3]
INTERNET DRAFT SRSVP February 2000
* and having a QoS routing mechanism.
SRSVP does not need FilterSpecs in RSVP, since filtering senders can
be executed at RVPs.
2. Multicast Model
The multicast model of SRSVP is based on RVP like PIM-SM. However, an
RVP is generally an application gateway, and does not have to be a
router. Distinguishable reservations (flows) are established, between
a sender and an RVP, and between an RVP and receivers. A sender can be
an RVP. Each sender sends multicast data to an RVP by unicasting. Each
receiver joins a multicast group, and a tree rooted from an RVP is
created as a result. A receiver is a leaf in the tree. Multicast data
received at an RVP is forwarded along the created tree.
RVP is described as ``sender'' in the case of a reservation between
sender(s) and an RVP, and is described as ``receiver'' in the case of
a reservation between an RVP and receiver(s), in this paper.
3. Messages
The following six messages are used in SRSVP:
* Path Message
* Resv Message
* PathTear Message
* ResvTear Message
* PathChg Message
* ResvChg Message
3.1 Path Message
A Path message MUST include a session, a sender template, Tspec and
MAY include FAQ, PQ and policy if needed. A Path is sent from a sender
in response to a Resv message. A request from a receiver, i.e. a Resv
message, is restricted by a Path message.
3.2 Resv Message
There are two types of Resv messages. One is for obtaining Tspec, FAQ,
PQ and policy, and the other is for actually requesting for a resource
reservation. The former is called as Resv0 and the latter is called as
Resv1. Resv0 MUST include session and sender template(s). Resv1 MUST
include session, sender template(s) and Flowspec, and MAY include FAQ
and PQ. A Resv message is sent from a receiver.
FUJIKAWA Kenji Expires on 1 June [Page 4]
INTERNET DRAFT SRSVP February 2000
3.3 PathTear/ResvTear Message
A PathTear message, which a sender or an RVP sends, and a ResvTear
message, which a receiver sends, tear down a resource reservation and
notify an error. A sender, an RVP or a receiver explicitly tear down a
reservation by a PathTear/ResvTear message, while a sender, an RVP, a
receiver or an en-route router tear down a reservation by a
PathTear/ResvTear message with an error code. A PathTear/ResvTear MUST
include session and sender template(s), and MAY include an object that
indicates an error when the error occurs.
Types of error objects are as follows:
Unreachable Host (UH)
Cannot reach a host
Unavailable Bandwidth (UB)
The bandwidth is unavailable
Unsatisfying Delay (UD)
The delay does not satisfy a request
Unsatisfying Charge (UC)
The charge does not satisfy a request
Illegal Flowspec (IF)
The Flowspec is illegal.
Invalid Policy (IP)
The policy is invalid.
3.4 PathChg/ResvChg
A PathChg and a ResvChg conveys charging information for a flow, and
are transfered from a side of a sender to receivers, and from sides of
receivers to a sender, respectively.
4. Basic Procedure of Making a Resource Reservation
The following shows an abstract of a procedure of making a resource
reservation.
4.1 Abstract of Resource Reservation Procedure
1. A receiver sends a Resv message without a Flowspec, i.e. Resv0.
En-route routers forwards it along the way to a sender, and
memorize a state of the flow.
FUJIKAWA Kenji Expires on 1 June [Page 5]
INTERNET DRAFT SRSVP February 2000
2. A sender that received a Resv0 sends a Path message. It is
forwarded along the reverse path of Resv0, with being added FAQ
and PQs. Each router releases the state of the flow after
forwarding the Path.
3. The receiver that received the Path sends a Resv message (Resv1)
with a Flowspec corresponding to the Tspec and received FAQ/PQs.
Each of the receiver and en-route routers calculates a QoS path
from a sender to itself, and forwards Resv1 along the reverse path
of that path, with memorizing a state of the flow.
4. The sender that received the Resv1 sends a Path message. It is
forwarded along the reverse path of Resv1, with being added FAQ
and PQs. Each of the sender and en-route routers adds an entry of
the flow, while sending/forwarding the Path.
4.2 Differences between Uni-source Flow and Multi-source Flow
* Source address and port are considered for identifying a
uni-source flow, while they are not for a multi-source flow.
* Source address and port are included in an entry for uni-source
flow, while they are not for a multi-source flow.
* A node looks up a correct sender template, i.e. an RVP, when it
receives multiple Resv messages each of which indicates different
sender template(s) in the case of a reservation for a multi-source
flow.
4.3 Valid Period of Resv
Though a router memorizes a state of the flow when it receives the
flow, it deletes the state unless it receives a corresponding Path
within 30 seconds from the reception of the Resv.
4.4 Merging Resv Messages
A router postpones the process of a Resv until it receives a Path,
when it has already received a Resv for the same flow.
It forwards a Path message to each direction it has received one of
the Resv message, or sends a PathTear message when the Flowspec of the
Resv does not correspond to the Tspec of the Path, when it received
the Path.
These procedures mean merging reservations.
4.5 Restriction of Reservation by Sender
A Resv from a receiver is restricted by a Path of a sender. That is, a
sender adds restriction to a reservation. Receivers obeys the
restriction.
FUJIKAWA Kenji Expires on 1 June [Page 6]
INTERNET DRAFT SRSVP February 2000
4.5.1 Resv1 Received before Setting Up Reservation
A router absolutely trusts Flowspec/FAQ/PQ in a Resv and proceeds the
reservation, when it receives the Resv before setting up the
reservation.
4.5.2 Resv1 Received after Setting Up Reservation
Assuming that a reservation for the flow is already established when a
router receives Resv1.
* In the case that the Flowspec of the Resv is the same as the Tspec
of the Path, the FAQ of the Resv includes that of the Path, and
the PQ of the Resv includes that of the Path:
The router forwards the Resv1 to the upstream node, which has
already established the reservation, as long as the router has not
sent a Resv to the upstream node.
* In the case that the Flowspec of the Resv is different from the
Tspec of the Path:
The router forwards the Resv0 to the upstream node, which has
already established the reservation, as long as the router has not
sent a Resv to the upstream node. The router re-receives a Path
and compares the Flowspec to the Tspec of the Path. The resulting
difference means an error.
* In the case that the FAQ of the Resv does not include that of the
Path, or the PQ of the Resv does not include that of the Path:
The router forwards the Resv0 to the upstream node, which has
already established the reservation, as long as the router has not
sent a Resv to the upstream node. The router re-receives a Path
and proceeds the Resv1 with FAQ/PQ in the Path.
5. Examples of Reservations
The following shows an example of creating a multicast tree. See
appendix C for more complicated examples.
5.1 Notation
Notation is as follows:
L(bw=<bandwidth>,dly=<delay>):
Link information.
A(chg=<charge>):
Area information.
FUJIKAWA Kenji Expires on 1 June [Page 7]
INTERNET DRAFT SRSVP February 2000
P(req=<request type>,bw=<bandwidth>,PQ(...),...):
Path message.
R(req=<request type>,bw=<bandwidth>,PQ(...),...):
Resv message.
PQ(<link>,bw=<bandwidth>):
PQ.
PT(err=<error type>):
PathTear message.
RT(err=<error type>):
ResvTear message.
where:
bw=<bandwidth>:
Bandwidth available at a link or requested by a Resv.
dly=<delay>:
Transmission delay at each link.
chg=<charge>:
Charge when a reservation is established.
req=<request type>:
This specifies a condition for calculating the shortest path
tree. This is included in a Flowspec or a Tspec. See [SS] for
details.
<link>:
A link, which is written as A1->A2.
err=<error type>
A type of errors. Illegal Flowspec (IF) and Unreachable Host
(UH) are used here.
Note that a ``+'' in a message means succeeds contents of the previous
message.
5.2 Initial State
Consider a network in Figure C.2.1.
Assuming that bandwidth or delay at each link is the same as that of
the opposite direction for simplicity, though each of them is
different from the opposite directions originally. Charging for
FUJIKAWA Kenji Expires on 1 June [Page 8]
INTERNET DRAFT SRSVP February 2000
passing an area is just defined for simplicity, though charging is
based on both of incoming direction and outgoing direction originally.
S1-----------A1-----------A2-----------A5-----------R1
| | |
| | |
| | |
| | |
+-----------A3-----------A6-----------R2
L(bw=0) |A(chg=2) |
| |
| |
| |
P1-----------A4-----------A7
L(bw=0)
S: Sender bw=1 at every link except A1-A3 and A4-A7
R: Receiver dly=1 at every link
A: Area chg=1 at every area except A3
P: rendezvous Point
Figure C.2.1: Initial State
5.3 Reservation of Uni-source Flow
5.3.1 Reservation of S1->P1
Consider that RVP P1 makes a reservation of S1->P1. This reservation
is one for a uni-source flow.
First, P1 sends Resv0, and each router forwards it along the unicast
path towards a sender S1. Each node memorizes the state of the flow at
this time.
<----------
S1-----------A1-----------A2
^ | |
| | |
| | |
| | |
| +-----------A3
+------------- | ^
| |
| |
| |
P1-----------A4
---------->
R()
FUJIKAWA Kenji Expires on 1 June [Page 9]
INTERNET DRAFT SRSVP February 2000
Figure C.3.1: P1->S1 Resv0
S1 sends a Path towards the direction from which it has received a
Resv, and each router forwards the Path along the reverse path of
Resv0. (Figure C.3.2) The state of the flow is deleted after the Path
was sent/forwarded.
A FAQ is actually included, but is omitted here.
P(req=dly,bw=1)
---------->
S1-----------A1-----------A2
| | |
| | |
| | |
| | |
| +-----------A3
+------------> | |
| |
| |
| V
P1-----------A4
<----------
Figure C.3.2: S1->P1 Path
P1 sends a Resv1 with a Tspec same as the Flowspec included in the
Path. Each router calculates a QoS path from S1 to itself, and
forwards the Resv1 along the path reversely. (Figure C.3.3) Each
router memorizes a state of the flow.
<---------- <----------
S1-----------A1-----------A2
| | ^
| | |
| | |
| | |
+-----------A3
| ^
| |
| |
| |
P1-----------A4
---------->
R(req=dly,bw=1)
Figure C.3.3: P1->S1 Resv1
FUJIKAWA Kenji Expires on 1 June [Page 10]
INTERNET DRAFT SRSVP February 2000
A Path is forwarded along the reverse path of Resv1. As each router
adds an entry, the revervation is established. The Path includes PQs.
(Figure C.3.4)
FAQs are also included actually, but are omitted here.
P(req=dly,bw=1,
PQ(S1->A1,bw=1)) P(+,PQ(A1->A2,bw=1))
----------> ---------->
S1===========A1===========A2
| || |
| || |P(+,PQ(A2->A3,bw=1))
| || |
| || V
+-----------A3
|| |
|| |P(+,PQ(A3->A4,bw=1))
|| |
|| V
P1<==========A4
<----------
P(+,PQ(A4->P1,bw=1))
Figure C.3.4: S1->P1 Path with PQ
A state of the network is shown in Figure C.3.5, after the reservation
is established.
L(bw=0) L(bw=0)
S1-----------A1-----------A2
| |
L(bw=0)| L(bw=0)|
| |
| |
+-----------A3
|
L(bw=0)|
|
|
P1-----------A4
L(bw=0)
Figure C.3.5: A state after establishment of the reservation
5.4 Resource Reservation of Multi-Source Flow
5.4.1 Resource Reservation P1->R1
FUJIKAWA Kenji Expires on 1 June [Page 11]
INTERNET DRAFT SRSVP February 2000
Assuming that receiver R1 will make a reservation of a multi-source
flow towards RVP P1. First, a reservation is established shown as
Figure C.4.1 - C.4.4, same as a unicast resource reservation
Note that bandwidth of links P1->A4, A4->A3 and A3->A2 remain as shown
in Figure C.2.1, since they are reverse directions of the previously
described flow of a unicast resource reservation.
R()
<---------
A2-----------A5-----------R1
| | |
| | |
| | |
| | V
A3-----------A6-----------R2
| | |
| | |
| | |
| | V
P1-----------A4-----------A7
<---------- <----------
Figure C.4.1: R1->P1 Resv0
--------->
A2-----------A5-----------R1
| | ^
| | |
| | |
| | |
A3-----------A6-----------R2
| | ^
| | |
| | |
| | |
P1-----------A4-----------A7
----------> ---------->
P(req=chg,bw=1)
Figure C.4.2: P1->R1 Path
FUJIKAWA Kenji Expires on 1 June [Page 12]
INTERNET DRAFT SRSVP February 2000
R(req=chg, bw=1)
<--------- <----------
A2-----------A5-----------R1
| | |
| | |
| | |
V | |
A3-----------A6-----------R2
| | |
| | |
| | |
V | |
P1-----------A4-----------A7
<----------
Figure C.4.3: R1->P1 Resv1
P(+,PQ(A2->A5,bw=1)) P(+,PQ(A5->R1,bw=1))
---------> --------->
A2===========A5==========>R1
^ || |
P(+,PQ(A3->A2,bw=1))| || |
| || |
| || |
A3-----------A6-----------R2
^ || |
P(+,PQ(A4->A3,bw=1))| || |
| || |
| || |
P1===========A4-----------A7
---------->
P(req=chg,bw=1,
PQ(P1->A4,bw=1))
Figure C.4.4: R1->P1 Path with PQ
FUJIKAWA Kenji Expires on 1 June [Page 13]
INTERNET DRAFT SRSVP February 2000
5.5 P1->R2 Resource Reservation
Next, the procedure for R2 to make a resource reservation is shown in
Figure C.4.5-C.4.8.
A2===========A5==========>R1
|| |
|| |
|| | R()
||<---------- |<----------
A3-----------A6-----------R2
| || |
| || |
| || |
V || |
P1===========A4-----------A7
<----------
Figure C.4.5: R2->P1 Resv0
A2===========A5==========>R1
|| |
|| |
|| |
||----------> |---------->
A3-----------A6-----------R2
^ || |
P(+,PQ(A4->A3,bw=1))| || |
| || |
| || |
P1===========A4-----------A7
---------->
P(req=chg,bw=1,
PQ(P1->A4,bw=1))
Figure C.4.6: P1->R2 Path
A2===========A5==========>R1
|| |
|| |
|| |
|| |
A3-----------A6-----------R2
| ||<--------- |<----------
R(req=chg,bw=1, | || | R(req=chg,bw=1,
PQ(P1->A4,bw=1))| || | PQ(P1->A4,bw=1),
V || | PQ(A4->A3,bw=1))
P1===========A4-----------A7
FUJIKAWA Kenji Expires on 1 June [Page 14]
INTERNET DRAFT SRSVP February 2000
<----------
R(req=chg,bw=1)
Figure C.4.7: R2->P1 Resv1
A2===========A5==========>R1
|| |
|| |
|| |
|| |
A3===========A6==========>R2
^ || ---------> | --------->
P(+,PQ(A4->A3,bw=1))| ||P(+, | P(+,PQ(A6->R2,bw=1))
| || PQ(A3->A6,|
| || bw=1)) |
P1===========A4-----------A7
---------->
P(req=chg,bw=1,
PQ(P1->A4,bw=1))
Figure C.4.8: P1->R2 Path
6. TCP Connections for Exchanging Messages
The way to establish TCP connections for exchanging SRSVP messages.
The port number of XXXX is used for TCP connections. Each node
searches adjacent nodes from link information of HQLIP, and establish
a TCP connection to each of them. The direction of a TCP connection is
decided by the way described in [HQLIP].
A node tear down reservations related to the connection, when the
connection is cut off.
7. Structure of Messages
7.1 Objects of Messages
Each message in SRSVP is defined by the following objects, with BNF.
* Common Header:
The header attached to every SRSVP message.
* SESSION:
A session, which is constructed by a source address, a protocol ID
and a destination port.
* RSVP_HOP:
This describes an identifier of the output interface, which
FUJIKAWA Kenji Expires on 1 June [Page 15]
INTERNET DRAFT SRSVP February 2000
consists of an IP address of the interface and Logical Interface
Handler (LIH).
* SENDER_TEMPLATE:
An IP address of a sender or an RVP.
* SENDER_TSPEC:
A QoS specified by a sender, which is described by REQ_QOS in
[SS].
* FLOWSPEC:
A QoS requested for by a receiver.
* ERROR_SPEC:
This shows a type of errors.
* POLICY_DATA:
Range where a sender is charged
* PQ_INFO:
PQs, each of which consists of identifier of a link and available
QoS.
* FAQ_INFO:
FAQs, each of which consists of identifier of a link and available
QoS.
* CHARGE_INFO:
Information for charging.
7.2 Construction of Messages
<Path message> ::= <Common Header> <SESSION> <RSVP_HOP>
<SENDER_TEMPLATE>
[<SENDER_TSPEC>] [<POLICY_DATA>]*
[<FAQ_INFO>] [<PQ_INFO>]
<Resv message> ::= <Common Header> <SESSION> <RSVP_HOP>
[<SENDER_TEMPLATE>]+
[<FLOWSPEC>] [<FAQ_INFO>] [<PQ_INFO>]
<PathTear message> ::= <Common Header> <SESSION> <RSVP_HOP>
<SENDER_TEMPLATE>
[<ERROR_SPEC>]
<ResvTear message> ::= <Common Header> <SESSION> <RSVP_HOP>
[<SENDER_TEMPLATE>]+
[<ERROR_SPEC>]
<PathChg message> ::= <Common Header> <SESSION> <RSVP_HOP>
<SENDER_TEMPLATE>
<CHARGE_INFO>
<ResvChg message> ::= <Common Header> <SESSION> <RSVP_HOP>
[<SENDER_TEMPLATE>]+
<CHARGE_INFO>
FUJIKAWA Kenji Expires on 1 June [Page 16]
INTERNET DRAFT SRSVP February 2000
References
[RSVP]
Braden, R., Zhang, L., Berson, S., Herzog, S. and Jamin, S.,
``Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification,'' RFC2205, September 1997.
[SS]
Fujikawa, K., ``Service Specification,''
http://www.real-internet.org/draft/draft-ric-ss-00.txt, 1999.
[HQLIP]
Ohta, M. and Fujikawa, K., ``HQLIP,''
http://www.real-internet.org/draft/draft-ric-hqlip-00.txt,
1999.
Authors' Address
FUJIKAWA Kenji
Graduate School of Informatics
Kyoto University
Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN
Phone: +81-75-753-5387
Fax: +81-75-751-0482
EMail: fujikawa@real-internet.org
SHENG I
Graduate School of Informatics
Kyoto University
Yoshidahonmachi, Sakyo-Ku, Kyoto City, 606-8501, JAPAN
Phone: +81-75-753-5387
Fax: +81-75-751-0482
EMail: sheng@kuis.kyoto-u.ac.jp
FUJIKAWA Kenji Expires on 1 June [Page 17]
INTERNET DRAFT SRSVP February 2000
Appendix
A. Message Formats
A.1 Common Header Format
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------+-------+---------------+---------------+---------------+
| Ver | Flags | Type | 0 |
+-------+-------+---------------+---------------+---------------+
| (reserved) | (reserved) | Length (bytes) |
+---------------+---------------+---------------+---------------+
* Ver: 4 bits
Protocol version number. This is version 2.
* Flags: 4 bits
0x1 = Uncharged
This is valid when the message type is Resv. A flow is not charged
when this flag is set. Besides, coefficients and restrictions
included in Tspec/Flowspec are ignored, and only bandwidth and
delay are considered to calculate the shortest path.
* Type: 8 bits
1 = Path
2 = Resv
5 = PathTear
6 = ResvTear
7 = PathChg
8 = ResvChg
* Length: 16bits
The length of a message in bytes, including a common header.
A.2 Object Formats
Every object consists of one or more 32-bit words with a one- word
header, with the following format:
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Length (bytes) | Class-Num | C-Type |
+---------------+---------------+---------------+---------------+
| |
// (Object Contents) //
| |
+---------------+---------------+---------------+---------------+
* Length: 16bits
The length of an object in bytes, including an object header.
FUJIKAWA Kenji Expires on 1 June [Page 18]
INTERNET DRAFT SRSVP February 2000
* Class-Num: 8bits
The class number of an object. The following objects are defined:
+ SESSION
+ RSVP_HOP
+ SENDER_TEMPLATE
+ ERROR_SPEC
+ SENDER_TSPEC
+ FLOWSPEC
+ PQ_INFO
+ FAQ_INFO
+ POLICY_DATA
+ CHARGE_INFO
* C-Type: 8bits
Object type, unique within Class-Num.
A.3 Definition of Objects
A.3.1 SESSION Class
IPv4/UDP SESSION object: Class = 1, C-Type = 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| IPv4 DstAddress |
+---------------+---------------+---------------+---------------+
| Protocol Id | Flags | DstPort |
+---------------+---------------+---------------+---------------+
IPv6/UDP SESSION object: Class = 1, C-Type = 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPv6 DstAddress +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
| Protocol Id | Flags | DstPort |
+---------------+---------------+---------------+---------------+
* DstAddress: 32bits or 128bits
The IP unicast or multicast destination address of the session.
* Protocol ID: 8bits
The IP Protocol Identifier for the data flow.
* Flags: 8bits
Not defined.
* DstPort: 8bits
FUJIKAWA Kenji Expires on 1 June [Page 19]
INTERNET DRAFT SRSVP February 2000
The UDP/TCP destination port for the session.
A.3.2 RSVP_HOP Class
IPv4 RSVP_HOP object: Class = 3, C-Type = 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| IPv4 Next/Previous Hop Address |
+---------------+---------------+---------------+---------------+
| Logical Interface Handle |
+---------------+---------------+---------------+---------------+
IPv6 RSVP_HOP object: Class = 3, C-Type = 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPv6 Next/Previous Hop Address +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
| Logical Interface Handle |
+---------------+---------------+---------------+---------------+
A.3.3 SENDER_TEMPLATE Class
IPv4 SENDER_TEMPLATE object: Class = 11, C-type = 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| IPv4 SrcAddress |
+---------------+---------------+---------------+---------------+
| ////// | Flags | SrcPort |
+---------------+---------------+---------------+---------------+
FUJIKAWA Kenji Expires on 1 June [Page 20]
INTERNET DRAFT SRSVP February 2000
IPv6 SENDER_TEMPLATE object: Class = 11, C-type = 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| |
+ +
| |
+ IPv6 SrcAddress +
| |
+ +
| |
+---------------+---------------+---------------+---------------+
| ////// | Flags | SrcPort |
+---------------+---------------+---------------+---------------+
* SrcAddress: 32bits or 128bits
The IP address for a sender. This may indicate an RVP.
* Flags: 8bits
0x01 = Failure
indicates the sender is not available.
* SrcPort: 8bits
The UDP/TCP source port for a sender.
A.3.4 ERROR_SPEC Class
RIC ERROR_SPEC object: Class = 6, C-type = 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
| Flags | //// |
+---------------+---------------+---------------+---------------+
* Flags: 8bits
0x01 = Unreachable Host (UH)
0x02 = Unavailable Bandwidth (UB)
0x04 = Unsatisfying Delay (UD)
0x08 = Unsatisfying Charge (UC)
0x10 = Invalid Flowspec (IF)
0x20 = Invalid PQ (IP)
A.3.5 SENDER_TSPEC Class
RIC SENDER_TSPEC object: Class = 12, C-type = 3
Refer to REQ_QOS in [SS] for the format.
A.3.6 FLOWSPEC Class
RIC FLOWSPEC object: Class = 9, C-type = 3
FUJIKAWA Kenji Expires on 1 June [Page 21]
INTERNET DRAFT SRSVP February 2000
Refer to REQ_QOS in [SS] for the format.
A.3.7 PQ_INFO Class
PQ_INFO object: Class = 16, C-type = 1(IPv4), 2(IPv6)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
// SrcArea (see Area in [HQLIP]) //
+---------------+---------------+---------------+---------------+
// DstArea (see Area in [HQLIP]) //
+---------------+---------------+---------------+---------------+
// PATH_QOS (See [SS]) //
+---------------+---------------+---------------+---------------+
// (the above tuple repeats) //
.........................
A.3.8 FAQ_INFO Class
FAQ_INFO object: Class = 17, C-type = 1(IPv4), 2(IPv6)
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
// SrcArea (see Area in [HQLIP]) //
+---------------+---------------+---------------+---------------+
// DstArea (see Area in [HQLIP]) //
+---------------+---------------+---------------+---------------+
// PATH_QOS (See [SS]) //
+---------------+---------------+---------------+---------------+
// (the above tuple repeats) //
.........................
A.3.9 POLICY_DATA Class
Charging Range POLICY_DATA object: Class = 14, C-Type = 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+---------------+---------------+
// Area (See [HQLIP]) //
+---------------+---------------+---------------+---------------+
// (repeats) //
.........
A.3.10 CHARGE_INFO Class
CHARGE_INFO object: Class = 18, C-type = 1
Refer to CHARGE in [SS] for the format.
FUJIKAWA Kenji Expires on 31 May [Page 22]
