Internet DRAFT - draft-durham-perstatus
draft-durham-perstatus
Internet Draft David Durham
Expiration: December 1999 Intel
File: draft-durham-pe-rstatus-00.txt Shai Herzog
IPHighway
RSVP Reservation Status Policy Element for End-to-End Accounting
June 25, 1999
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 document details an RSVP Policy Element that provides a
mechanism by which RSVP reservation establishment can be reliably
confirmed, end-to-end. This Policy Element provides a status update
with each PATH message refresh, useful for determining the lifetime
of a reservation end-to-end. Such a policy element will be useful
for accounting and billing applications that are interested in
reliably knowing when a reservation has been successfully
established end-to-end and when a reservation is finally removed.
Internet Draft Expires December 1999 [Page 1]
Internet Draft Reservation Status Policy Element 25-Jun-99
Table of Contents
Abstract..............................................................1
Table of Contents.....................................................2
1 Introduction.......................................................3
2 Format of the Reservation Status Policy Element (RSPE).............4
2.1 Format of the RESV message's Request RSPE........................4
2.2 Format of the PATH message's RSPE................................4
3 A Simple Scenario..................................................7
4 PDP Usage Model....................................................8
5 Authoritative CPs..................................................9
6 Security Considerations............................................9
7 References........................................................10
8 Author Information................................................10
David Durham Expires December 1999 [Page 2]
Internet Draft Reservation Status Policy Element 25-Jun-99
1 Introduction
In RSVP, the Reservation Confirmation (RESV Confirm) message is used
to provide a one-time indication that a reservation has been
successfully established between a destination and the source or
merge point. The problem with the RESV Confirm is that this message
is not reliable. It is sent once in reply to the original
Reservation (RESV) message sent by the destination. The network may
loose the RESV Confirm, and due to the fact it is not sent with
every refresh, the destination may never receive the indication.
Furthermore, the RESV Confirm only provides an indication that a
reservation was successfully received by the source or first merge
point. It does not provide an indication of reservation state
timeout or state preemption along the end-to-end reserved data path
(the equivalent of a Unconfirm Message). Finally, the RESV Confirm
message is sent by unicast directly from the source or merge point
to the destination that issued the CONF message. Thus, intermediate
hops, including their Policy Decision Points (PDP) or Bandwidth
Brokers (BB), will never receive the RESV Confirm indication.
For purposes of accounting and billing for end-to-end reservation
establishment, there needs to be a reliable mechanism to determine
when a reservation has been successfully installed along the data
path, and when such a reservation is lost to determine its duration.
To facilitate such a capability, this specification introduces new
Policy Data Element carried by PATH and RESV messages that can
provide end-to-end status information on the state of upstream
reservations. This policy element is the Reservation Status Policy
Element (RSPE). For better scalability, the RSPE exchange is
triggered on-demand by downstream entities, by placing an RSPE in
RESV messages. The reservation status is sent back with PATH
messages.
The RSPE assumes a network infrastructure whereby neighboring hops
or bordering networks have bilateral relationships (and can
authenticate each other). This creates a hop-by-hop or network-by-
network chain of security whereby a bordering network can present
its status information as well as the culmination of all status
information from all upstream networks along the data path.
The RSPE is generated by Confirmation Points (CP) for a network
along the data path. Every hop along the data path can be a CP, but
a CP will typically be a PDP that knows the status of its network as
well as any relevant upstream networks with which it has a bilateral
relationship. An authoritative CP sends the first PATH with RSPE in
it. This status is then passed onto downstream networks for which
the CP also has a bilateral relationship. Each CP updates the RSPE
according to its own status, and eventually the status of a
reservation end-to-end may be ascertained by the receiver of the
RSPE.
David Durham Expires December 1999 [Page 3]
Internet Draft Reservation Status Policy Element 25-Jun-99
2 Format of the Reservation Status Policy Element (RSPE)
The Reservation Status Policy Element is carried in either PATH or
RESV messages depending on its subtype. It is used in RESV messages
to request reservation status information from upstream hops. It is
then used in PATH messages to provide the upstream status
information back to the downstream hops.
Policy Element Type Number = 10
2.1 Format of the RESV message's Request RSPE
The this PE is used to request the generation of Reservation Status
from upstream CPs. It is carried in RESV messages in the Policy Data
Object. As long as a destination (or intermediate hop) is interested
in a reservation's status, it should continue to provide the RSPE in
its RESV refreshes.
0 1 2 3
+--------------+--------------+--------------+--------------+
| PE Length | PE-Type = RSPE |
+--------------+--------------+-----------------------------+
| Sub-Type = 1 | Request Flags| //////////////////////// |
+--------------+--------------+-----------------------------+
Note: //// implies field is all zeros.
Request Flags:
0x01 = Non-immediate Response
When the Non-Immediate Response is set, the Authoritative CP may
delay the response until a refresh PATH message is sent. This may
reduce the overhead of sending an immediate PATH update.
2.2 Format of the PATH message's RSPE
The RSPE is carried in the Policy Data object of a PATH message. It
is created by the source itself, or a PDP close to the data source
acting as a confirmation point. The RSPE is updated by each
downstream CP with which it comes into contact.
David Durham Expires December 1999 [Page 4]
Internet Draft Reservation Status Policy Element 25-Jun-99
0 1 2 3
+--------------+--------------+--------------+--------------+
| PE Length | PE-Type = RSPE |
+--------------+--------------+-----------------------------+
| Sub-Type = 2 | Status Flags | //////////////////////// |
+--------------+--------------+-----------------------------+
| End-to-End Resv Duration |
+--------------+--------------+-----------------------------+
| CP Timestamp |
+-----------------------------+-----------------------------+
| CP Addr Type | CP Addr Length |
+-----------------------------+-----------------------------+
| CP Address |
+-----------------------------+-----------------------------+
Status Flags:
The RSPE status flags describe the reservation status.
0x01 = Reservation Installed.
0x02 = Unconfirmed Segments.
If no reservation was yet received, the Reservation Installed
flag will NOT be set. If a reservation was received and was
successfully installed by the current CP and all upstream CPs
(if any) since the last refresh period, the Reservation
Installed flag will be set. If the reservation state was
removed at the CP, the Reservation Installed flag will NOT be
set.
The Unconfirmed Segments flag indicates that the status of
some parts of the data path cannot be ascertained. This may
be because an intermediate network does not participate in
the RSPE exchange, or that the RSPE was not included in PATH
messages from some upstream segments.
As RSPE's are passed via PATH messages CP-to-CP down the data
path, a downstream CP is also responsible for relaying the
cumulative RSPE status of its upstream CPs. The Reservation
Installed status flag may be updated by the downstream CP to
reflect its local reservation state. It can only be set by
the downstream CP, however, if the upstream CP had it set
already and the downstream CP has successfully installed a
corresponding reservation. If the Unconfirmed Segments status
flag was set in an upstream RSPE, all downstream nodes must
leave the flag set in their forwarded RSPEs. A CP will set
the Unconfirmed Segments flag if no RSPE was provided by any
upstream CP (and the current CP is not the source), or if the
RSPE was generated by an unknown upstream CP (based on the
RSPE's CP Address field). An upstream CP is unknown if it
David Durham Expires December 1999 [Page 5]
Internet Draft Reservation Status Policy Element 25-Jun-99
does not match any administratively configured upstream CPs
in the current CP's database, or the received RSPE's CP
Address field doesn't match the PHOP's address.
End-to-End Reservation Duration.
This value is determined by taking the MINIMUM of the current
CP's reservation duration, and the upstream CP's End-to-End
Uninterrupted reservation duration (if the upstream hop
provided the RSPE in its PATH).
The current CP's reservation duration is the duration that
the reservation state has been installed at the current CP.
This period is specified in seconds, initially set to zero.
When a reservation state is in any way removed at the CP,
this period counter will stop (and maintain the last known
duration). If the reservation state is reinstalled, this
field will be reset to zero and begin counting seconds again.
CP Timestamp.
This field is zero until a reservation is successfully
installed end-to-end. This is the current time in seconds
that the CP last set its RSPE's status to Reservation
Installed. When a reservation is removed, the CP Timestamp
remains set to the last time a reservation was successfully
installed end-to-end. The time is defined in seconds since
midnight GMT 1/1/1970 (system clock time).
Confirmation Point (CP) Address Type.
Determines the type of the address used to identify the
confirmation point. The currently defined values are:
0x00 = No Address
0x01 = IPv4 Address
0x02 = IPv6 Address
0x03 = DNS Address
CP Address Length.
Length in bytes of the CP's address. For IPv4 addresses the
length must be 4 bytes. For IPv6 addresses the length must be
16 bytes. For DNS Addresses, the length must not exceed 255
bytes of ASCII characters including a NULL terminator. A DNS
address must be aligned to a 4 byte boundary using NULL
characters.
CP Address.
David Durham Expires December 1999 [Page 6]
Internet Draft Reservation Status Policy Element 25-Jun-99
This is the IP address of the upstream confirmation point
that last updated the RSPE.
3 A Simple Scenario
This simple scenario assumes that all RSVP aware hops are CP's and
can interpret the RSPE object. The data source is assumed as an
Authoritative CP (since it can confirm that the RESV reached the
source and was installed).
First, a requester generates a RSPE Type-1, and places it in its
Outgoing RESV message. Intermediate CPs are expected to forward the
PE Type-1 upstream as-is. When the Authoritative CP (source)
receives a RESV message containing an RSPE Type-1, requesting
status, it is expected to respond by inserting an RSPE Type-2 with
the appropriate status information in an updated PATH message and
all its subsequent PATH refreshes. The Installed Reservation flag
should be set in the RSPE if the reservation was installed,
specifying that the path is reserved.
The timestamp provides the time the reservation was installed. Once
installed, the duration timer should be used to record the duration
that the reservation remains. This is the duration (in seconds) that
the reservation has been installed, uninterrupted. Uninterrupted
implies that the reservation was never removed in any way,
preempted, or timed-out.
It is not particularly valuable to simply know that the source has
installed a reservation. This is because intermediate nodes may have
since lost or preempted their reservation state. Also, there may be
no trust relationship between the administrative domain of the
source and that of the destination (multilateral relationships are
hard to maintain). Furthermore, for a multicast session, a
reservation state close to the source could be associated with any
number of possible destinations. While some destinations may have
successfully issued a reservation that was installed end-to-end,
reservations from other destinations for the same session may have
failed. Ideally, all the hops for a RESV message should be able to
participate in the reservation status exchanges. Each hop's RSPE
status will depend on the status contained in the PATH messages from
the previous upstream PHOP as well as the current hop's status.
Effectively, the RSPE can be manipulated hop-by-hop.
Subsequent hops will examine and modify the RSPE in PATH messages
from the previous hops before forwarding the RSPE on downstream.
Specifically, the upstream reservation status flags field is updated
with the status of the reservation state at the current hop. If the
CP Address specified in the RSPE of the PHOP is different from the
address of the PHOP specified in the PATH message, then the
David Durham Expires December 1999 [Page 7]
Internet Draft Reservation Status Policy Element 25-Jun-99
Unconfirmed Segments flag should be set in the forwarded RSPE (as
one or more intermediate nodes did not participate in the RSPE
exchange). For the updated RSPE, the timestamp will describe the
time that Reservation Installed status flag was first set by the
current hop (and, thus, was set by the upstream hops as well).
Additionally, the current hop keeps a local duration counter for the
lifetime of the local reservation state. The current hop will
compare its local duration counter with the value of the End-to-End
Duration specified in the PHOP's RSPE. The minimum of these two
values is then passed in the forwarded PATH's RSPE. Finally, the
current hop will insert the HOP address corresponding to the
interface out which the PATH carrying the RSPE is forwarded. This is
then used by the subsequent NHOP to verify there are no unconfirmed
segments.
If a reservation state is lost anywhere along the data path, the
nodes where the reservation state is lost should stop their duration
counters and unset the Reservation Installed flag in the forwarded
RSPE. This frozen duration will continue to be supplied in future
PATH refreshes by the now unreserved node including the timestamp of
the last time the reservation was successfully installed end-to-end.
If a reservation state is reinstalled the Reservation Installed flag
can be set again, the timestamp updated to the current time, and the
local duration counter reset to zero and begin counting the duration
of this reservation state. Updates to RSPEs can wait for the next
scheduled PATH refresh so as not to generate a new PATH message with
each local state change.
4 PDP Usage Model
It is likely that the above procedure will be too expensive or
technically hard to achieve in all RSVP nodes. It would be more
realistic to assume that RSPE processing would be limited to PDP's
operating at the edges of networks. In this case, PDPs represent a
set of RSVP nodes in their controlled network. Although not
foolproof, PDP's can be used to verify the previous (upstream) CP's
status, and integrate this status with its own. As such, a chain of
trust can be setup whereby scalable verification of the end-to-end
establishment of reservations is possible on a domain-by-domain
basis.
In order to allow this model PDPs within a network must be
configured to be confirmation points for their domain. They will
have to know which nodes are within their domain. Furthermore, the
PDP will have to be configured with the addresses of all CPs in
other domains with which it has bilateral relationships.
If the source of the corresponding PATH message is within the PDP's
domain, it is considered an Authoritative CP. An Authoritative CP is
the only CP that may respond to an incoming RESV with RSPE Type-1,
David Durham Expires December 1999 [Page 8]
Internet Draft Reservation Status Policy Element 25-Jun-99
with an outgoing PATH with RSPE Type-2. An authoritative CP provides
the status on behalf of the source.
The upstream and downstream procedure is the same as in the hop-by-
hop approach, but between PDPs rather than hop-by-hop. The only
difference is that the RSPE CP Address field is verified against the
configured addresses of neighboring PDP CPs (as opposed to just the
RSVP PHOP address). If a PATH contains a RSPE from an unknown PDP
(based on the CP Address), then the Unsupported Segments flag must
be set before the RSPE is forwarded downstream. The forwarded RSPE's
CP Address field must contain the IP Address of the PDP that
created/modified the RSPE.
5 Authoritative CPs
If the source is a CP, it is always an authoritative CP. However, if
the Source does not respond to RSPE, the PDP controlling the domain
in which the source is located should be configured as the
authoritative CP. If both the source and the PDP are authoritative
(or in any other case where multiple CPs are authoritative) the most
upstream one wins. When an Authoritative CP sees a RSPE Type-2 in
the Incoming PATH, it looses its authority and acts as a regular CP.
It may regain this authority when the RSPE Type-2 expires and a new
one wasn't received.
There may be cases, where there is no authoritative CP to respond,
for example, if the source doesn't recognize RSPEs, and no PDP was
configured as the source's authoritative CP. In this case, the
absence of an RSPE in subsequent PATH messages implies there are
unconfirmed segments. After one full timeout period has expired
someone needs to reply with an RSPE specifying the Unconfirmed
Segments status. This someone would be any CP that has seen one
timeout period since it first encountered an RSPE Type-1 object,
without seeing an RSPE Type-2 response in return.
RSPEs, and any other Policy Data object expire at the same time as
other RSVP state [RSVP] and, therefore, must be continuously
refreshed.
6 Security Considerations
The RSPE is protected by RSVP integrity and Policy Data Integrity
mechanisms [RSVP, RSVP-EXT]. There is an underlying assumption that
none of the intermediate CPs are malicious. CPs are either trusted
(intra-net) or bound by a set of bilateral agreements between
neighboring CPs such that sanctions may take place by one neighbor
is the other is falsifying RSPE contents.
David Durham Expires December 1999 [Page 9]
Internet Draft Reservation Status Policy Element 25-Jun-99
7 References
[RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission
Control",IETF <draft-ietf-rap-framework-02.txt>, Jan., 1999.
[RSVP-EXT] Shai Herzog "RSVP Extensions for Policy Control" <draft-
ietf-rap-rsvp-ext-06.txt>, April, 1999.
[COPS] Boyle, J., et al. "Common Open Policy Service (COPS)" <draft-
ietf-rap-cops-06.txt>, Feb., 1999.
[RSVP]Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP)
Version 1 - Functional Specification", RFC 2205, September
1997.
8 Author Information
David Durham
Intel
2111 NE 25th Avenue
Hillsboro, OR 97124
503.264.6232
David_Durham@mail.intel.com
Shai Herzog
IPHighway Inc.
Parker Plaza, 16th Floor
400 Kelby St.
Fort-Lee, NJ 07024
201.585.0800
Herzog@iphighway.com
David Durham Expires December 1999 [Page 10]
