One document matched: draft-berson-rsvp-aggregation-00.txt
Internet Draft S. Berson
Expiration: February 1999 USC/ISI
File: draft-berson-rsvp-aggregation-00.txt S. Vincent
USC/ISI
Aggregation of Internet Integrated Services State
August 7, 1998
Status of Memo
This document is an Internet-Draft. 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."
To learn the current status of any Internet-Draft, please check the
linebreak "1id-abstracts.txt" listing contained in the Internet-
Drafts Shadow Directories on ftp.ietf.org (US East Coast),
nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au
(Pacific Rim).
Abstract
The Internet Integrated Services (IIS) architecture[2] has a
fundamental scaling problem in that per flow state is maintained at
all routers and end-systems supporting a flow. This draft examines
the use of aggregation as a technique to reduce the amount of state
needed to provide IIS, and describes the modifications to RSVP to
support aggregation. In our approach, routers at the edge of a
region doing aggregation keep detailed IIS state, while in the
interior of this region, routers keep a greatly reduced amount of
state. Packets will be tagged at the edge with scheduling
information that will be used in place of the detailed IIS state.
The aggregation scheme described will allow large scale deployment of
IIS without overloading routers with state and associated processing.
Berson, Vincent Expiration: February 1998 [Page 1]
Internet Draft RSVP Aggregation August 1998
1. Introduction
In order to deploy Internet Integrated Services (IIS), additional
resources are needed in the routers to store state and to process
packets. As currently defined [3,2], this state is on a per session
basis, where a session is a unicast or multicast destination and
optionally a port. IIS state is stored at all routers between the
source(s) and destination(s) of a session. Thus, widespread use of
IIS would mean a large amount of state at routers in the core of the
Internet. This large amount of state and related processing could
overwhelm routers, so IIS state models that do not require per-
session state at all routers need to be explored.
Several types of per-session state are used with integrated services.
First, there is scheduling state that consists of the different
traffic service queues for packet forwarding. Second, there is
packet classifier state. Classifier state is used to assign each
arriving packet to a packet scheduling queue for forwarding. Third,
there is the state for the setup protocol, e.g. state carried in RSVP
PATH and RESV messages. Finally, current multicast routing
algorithms also store state, either per source and session (e.g.
DVMRP[9], PIM-DM[5]) or per session shared-tree (e.g. CBT[1], PIM-
SM[5]). While approaches to aggregation of routing state are similar
to aggregation of IIS state, they are beyond the scope of this draft.
Per session state in a router has two detrimental effects. First,
additional state consumes memory, and second, additional state
requires additional CPU cycles to process the state. Depending on
the speed with which the memory needs to be accessed, different types
of memory can be used. State that is required in order to process
each packet (e.g. classifier state, scheduling state, and multicast
routing state) needs to be stored in fast (i.e. cache) memory, while
other state (e.g. setup protocol state) can be stored in slower
memory. Since fast memory is substantially more expensive than slow
memory, and since accesses to fast memory are on the router fast
path, our primary goal is to reduce the classifier and scheduler
state. Reducing the amount of setup protocol state is an important,
but secondary goal.
Any aggregation scheme entails some tradeoffs. Keeping full
integrated services state at all routers allows the resources
dedicated to the flow of packets from each admitted session to be
isolated from the resources for packets from all other sessions.
This isolation means that resources reserved and needed for one
session will be used only on the reserving session. The disadvantage
of doing aggregation is the loss of some portion of this flow
isolation, since with aggregation many flows would share the same
traffic service class.
Berson, Vincent Expiration: February 1998 [Page 2]
Internet Draft RSVP Aggregation August 1998
This draft describes how to provide Internet Integrated Services for
both unicast and multicast traffic with greatly reduced state
requirements. We concentrate primarily on Controlled Load type
service[10], which reserves bandwidth but not delay or jitter, though
our approach should be more generally applicable (see [7] for a
related approach). With our approach, the amount of scheduler state
is bounded at all nodes for both unicast and multicast traffic. For
unicast traffic, full classifier state and setup protocol state are
stored only at the edges of the network. In the interior of the
network, no unicast setup protocol state is stored, and only a
bounded amount of classifier state is used. For multicast traffic, a
minimal amount of additional classifier state and additional setup
protocol state is used in the network interior.
We make several assumptions:
1. We assume that an explicitly definable region (e.g. one or more
contiguous autonomous systems), called an "aggregating region",
will aggregate and will implement supporting mechanisms at its
boundary points. We define an "ingress" of an aggregating
region as a router where a packet for a specific unicast or
multicast session enters the region, and an "egress" as a router
where a packet for a specific session leaves the region. Also,
we define an "interior router" for a session as any router in
the aggregating region that is on the data path for the session
and is not the ingress or egress.
2. We assume that the choice to aggregate and the mechanism used to
do so is an intra-domain issue, not an inter-domain issue and
therefore there can be variability across regions so long as at
the boundaries routers continue to pass along adequate messages
to support the setup protocol upstream and downstream.
3. We assume current multicast and unicast routing within the
aggregating region; but with no other enhancements.
2. Framework
Since each network service provider will want to make decisions on
how to provide integrated services based on their provisioning and
traffic patterns, a brief review is presented of how IIS state is
used.
2.1 Integrated services state
Scheduler classes are the unit of assignment of network resources.
Scheduler state typically takes the form of different traffic
Berson, Vincent Expiration: February 1998 [Page 3]
Internet Draft RSVP Aggregation August 1998
classes. These traffic classes are assigned different priorities,
link shares[6], and policing policies to provide a certain level
of service. In the basic IIS model, each traffic flow gets its
own traffic class, meaning that each flow has certain resources
dedicated to it. By reducing the number of traffic classes, a
coarser granularity of resource assignment is done in that several
flows will be assigned to the same scheduler queue. A consequence
of the coarser granularity is that the aggregated traffic gets a
certain level of resource usage, but it is impossible inside an
aggregating region to isolate flows in the same traffic class from
each other. This lack of isolation can be mitigated by adequate
provisioning of network resources and by policing at aggregating
region borders.
Classifier state is used to assign packets to traffic classes.
Each arriving packet is classified into a traffic class at each
node according to state established by the setup protocol. In the
complete absense of classifier state, no service differentiation
is possible. However a packet can be classified at the ingress,
and the results of that classification can be encoded in each
packet. This reduced classifier state encoded in a packet can be
as simple as one or more bits segregating different classes of
traffic, or alternatively, an encapsulation header. By encoding a
small amount of classifier state in the packet, only a very simple
classification is needed at interior routers.
Finally setup protocol (e.g. RSVP) state is used to do admission
control, provide policing, allow reclassification, and allow
merging of reservation messages. The first two of these issues,
admission control and policing, are general issues involving both
unicast and multicast traffic, while the last two,
reclassification and reservation merging, are only issues with
multicast traffic.
2.1.1 General setup protocol state issues
Setup protocol state is used in admission control. Setup
protocol state contains the amount of resources reserved for
each admitted flow at a router. Admission control with full
IIS state involves computing how much network resources are
already committed to existing reservations and whether there
are sufficient resources to admit a new flow with certain
resource requirements. In the absence of setup protocol state,
admission control decisions can be made only on the basis of
the reservation request control message and load measurements
on the router. We call this type of admission control
"measurement based admission control"[8].
Berson, Vincent Expiration: February 1998 [Page 4]
Internet Draft RSVP Aggregation August 1998
Setup protocol state is also used for traffic policing.
Policing is done in an IIS network at traffic merge points and
at traffic split points. A traffic merge point (see Figure a)
is where the traffic from two or more sources for the same
session merge. For an RSVP shared style reservation, the
traffic from all the sources needs to be policed to the
reservation parameters at traffic merge points. This means
that though the traffic arriving on links L1 and L2 is within
the reservation parameters, the sum of the traffic exiting on
link L3 may exceed the reservation parameters. In this case,
policing is needed on link L3.
Policing is also done at traffic split points (see Figure b).
A traffic split point is where multicast traffic has multiple
outgoing interfaces. Because of RSVP reservation merging and
because some outgoing interfaces may have differing
reservations, traffic at a split point needs to be policed on
each outgoing interface to the proper reserved values for that
interface. In the figure, link L5 has a reservation Q1 while
interface L6 has a reservation Q2. Policing is needed to make
the traffic on the outgoing links conform to the link
reservation.
[ Figure omitted in .txt version - see .ps version ]
Figure 1: Traffic split and merge nodes
2.1.2 Multicast setup protocol state issues
Setup protocol state is used to allow reclassification of
packets from reserved to best effort. This reclassification is
necessary at traffic flow split points (see Figure b) where
there are one (or more) outgoing interfaces with reservations
and one (or more) outgoing interfaces without reservations. In
the figure, links L5 and L6 have reservations, while link L7
has no reservation and is forwarding best effort. Since data
packets are marked with their with their service class, the
packets may need to be remarked at traffic split points. At
these points packets forwarded to outgoing interfaces with no
reservations such as link L7 need to be reclassified as best
effort.
Finally, setup protocol state is used to merge reservation
messages coming from the egresses to the ingress. With setup
protocol state for each session, and hop by hop processing of
reservation messages, each router can limit the number of
reservation refreshes it sends. Without setup protocol state,
each reservation refresh message from each egress would be sent
Berson, Vincent Expiration: February 1998 [Page 5]
Internet Draft RSVP Aggregation August 1998
to the ingress, requiring a large amount of processing for any
large multicast groups.
2.2 Basic aggregation architecture
We propose a scheme for unicast traffic with a constant amount of
scheduler state at all routers, a constant amount of classifier
state at interior routers, and no setup protocol state at interior
routers. For multicast traffic, we propose a scheme with bounded
scheduler state, and greatly reduced classifier and setup protocol
state. In our approach, a fixed number of traffic service classes
are defined and configured at all routers in an aggregating
region. Each traffic service class is subject to admission
control at the ingress to the region. Traffic policing (and
reclassification) is done at the ingress for unicast traffic, and
at the ingress plus at traffic split points for multicast traffic.
Since only a fixed number of traffic classes are available, the
scheduler state at all routers is constant.
Data packets are classified and "tagged" on entry to the
aggregating region with some identifier indicating to which
aggregated traffic class the packet should belong. This
identifier can consist of some bits in the packet header (e.g.
type of service bits) or the packet could be encapsulated. The
tag (or encapsulation) encodes the traffic service class that this
packet will receive across the aggregating region. Tagging or
encapsulating each packet bounds the amount of classifier state in
the interior of the aggregating region.
Full setup protocol state is stored at the borders of the
aggregating region, but only a small amount of multicast setup
protocol state is needed in the interior of the region. When a
reservation message arrives at an ingress to the region (from an
egress), and that reservation passes admission control, then
packets from the flow associated with the new reservation are
assigned to one of the configured traffic service classes.
Admission control will be measurement-based, and, since there is
no unicast and minimal multicast setup protocol state in the
interior, admission control will be done at the ingress for a
session. But the decision will be based on congestion
measurements within the aggregating region. Thus each node in the
aggregating region, upon receiving an admission control setup
protocol message, will make a local congestion decision. This
local congestion decision will be made on a threshold basis where
new reservations are not admitted if the existing measured load
plus the expected additional load from the new flow is greater
than a (possibly dynamic) threshold.
Berson, Vincent Expiration: February 1998 [Page 6]
Internet Draft RSVP Aggregation August 1998
To implement the local congestion decision, each node keeps an
estimate of its current load per traffic class. As an admission
control message traverses the path between ingress and egress,
each interior router must admit that reservation. Each router
that provisionally admits the reservation should factor the new
reservation into its currect traffic estimate. To admit the flow,
an estimate of the amount of the reserved traffic due to this
reservation must be made, e.g. based on peak rate specified in the
admission control message. If some router does not admit the
reservation, the admission control message is marked appropriately
by the rejecting router and the message is forwarded. When the
admission control message arrives at the egress, the egress node
forwards the control message back to the ingress. The ingress
checks the message to see if any router rejected the message. If
some router rejected the reservation, then the ingress will reject
the reservation and send a reservation error message.
In summary, our approach provides for reduction of packet
scheduler state, packet classifier state, and setup protocol (e.g.
RSVP) state in the following ways. A constant amount of packet
scheduler state at all routers in an aggregating region is
achieved by using preconfigured traffic service classes. A
constant amount of packet classifier state for unicast traffic at
all interior routers in the aggregating region is accomplished by
tagging or encapsulating each packet with its traffic service
class. No setup protocol state at interior routers for unicast
traffic is achieved by doing admission control and policing only
at the edges of the aggregating region. For multicast traffic,
only a small amount of RSVP state is stored at routers, while
classifier state is stored only at traffic split points and only
on those outgoing interfaces with no reservation.
2.3 Multicast setup protocol state
We would like to apply the above approach to multicast traffic to
eliminate all of the setup protocol state in the network interior.
However, there are some fundamental differences between unicast
and multicast traffic that results in additional setup protocol
state being desirable. Since traffic with multiple destinations
is being classified and tagged at the ingress router, a tagged
multicast packet will receive reserved service everywhere in the
cloud, including branches for which there are no reservations.
This all-or-nothing reservation property, caused by tagging at the
ingress, complicates aggregating state for multicast sessions.
The complications derive from two features of multicast sessions,
"heterogeneity" and "dynamic group membership". Heterogeneity
refers to the situation where different branches of a multicast
distribution tree have different reservations, including the case
Berson, Vincent Expiration: February 1998 [Page 7]
Internet Draft RSVP Aggregation August 1998
where some branches have no reservation. Unreserved packets
receiving reserved service can adversely affect packet flows that
properly have a reservation. Without additional state, there is
no way to determine which packets have a legitimate reservation.
The other multicast feature causing complications is dynamic group
membership. Dynamic group membership means that the members of a
multicast session can be changing over time by having new
receivers join, and old receivers leave. Due to the all-or-
nothing property, a new best effort receiver joining a multicast
session with a reservation in place will be receiving reserved
service. Admission control will not have been done for that new
receiver, and so those reserved packets to the new receiver can
cause congestion for other properly reserved packets. Thus a best
effort receiver can disrupt reserved traffic.
Our approach to aggregation and multicast is to keep some
additional setup protocol state for multicast sessions but only at
split nodes. Since setup protocol state is not on the router fast
path, this option is reasonable since scheduler state and
classifier state are still minimized. Some additional classifier
state is needed, but only for sessions with heterogeneous
branches, and only at those nodes with heterogeneous outgoing
interfaces. This classifier state can be established dynamically
from setup protocol state and routing state. When a node
discovers that it has heterogeneous outgoing interfaces,
classifier entries are established on the best effort branches.
The packets that the classifier matches have the reserved markings
removed and new markings inserted indicating that the packets are
to be forwarded as best effort.
2.4 Policing in the interior
There is still an issue with state aggregation and shared (e.g.
RSVP wildcard or shared explicit) style reservations for unicast
packets at traffic merge points. At a merge point, the traffic
entering the node may conform to the reservation, but the traffic
exiting the node may be non-conforming due to multiple senders.
With setup protocol state, the traffic would be policed at the
merge node. Since there is no unicast setup protocol state in the
interior of the network, it is impossible to police the traffic of
an individual flow in the interior. The traffic will eventually
be policed at the next ingress, but may interfere with actual
reserved traffic between the merge point and the egress. Since
the traffic will eventually be policed, there is no "free
bandwidth" for a user trying to exploit this feature. However
there is a security problem where a malicious user could tie up
reserved bandwidth traffic in a transit network. The simplest
Berson, Vincent Expiration: February 1998 [Page 8]
Internet Draft RSVP Aggregation August 1998
solution to this problem is to limit or prohibit unicast shared
style reservations, which are of limited usefulness. Other
approaches involve detection at the egress of abusive behavior,
and cancelling the offending reservation.
3. RSVP operations/extensions
In this section we describe how this aggregation scheme would be
applied to RSVP. We assume that a measurement based admission
control algorithm[8] is defined, and we describe how to utilize this
system to implement aggregation. The basic issues are gathering the
measurement data, keeping track of which reservations are new, and
describing the appropriate data structures.
3.1 RSVP protocol changes for aggregation
In order for RSVP to support aggregation of IIS state, two new
RSVP message types are needed, admission request (ADREQ) and
admission reply (ADREP). The ADREQ is used by an ingress to set
up the reservation across the aggregating region, while the ADREP
is used by the egress to report that the reservation has succeeded
or not.
In addition to new message types, an admission control object
(ADMISSION), and an admission control status (STATUS) object types
are needed. The ADMISSION object and zero or more STATUS objects
are included as part of a ADREQ or ADREP message. The ADMISSION
object contains a common object header, a handle from the ingress
node, and some flags. The handle is included by the ingress node
on initiating aggregated admission control and is used to uniquely
identify reservation state on the ingress. The IP address of the
ingress is stored in an RSVP_HOP object in the ADREQ message. The
STATUS object has a common header, an RSVP_HOP, and a load status.
The RSVP_HOP object contains the IP address of the node supplying
the load report, while the load status is the measured load from a
node.
The format of the ADREQ and ADREP messages are as follows:
<ADREQ> ::= <Common Header> <FLOWSPEC> <ADMISSION> <RSVP_HOP>
<status_report>
status_report ::= <empty> | <status_report> <STATUS>
<ADREP> ::= <Common Header> <ADMISSION> <status_report>
struct {
Object_header header;
Berson, Vincent Expiration: February 1998 [Page 9]
Internet Draft RSVP Aggregation August 1998
Handle handle;
int flags;
} ADMISSION;
#define ADMITTED 1
#define REJECTED 0
struct {
Object_header header;
RSVP_HOP sess;
Load load;
} STATUS;
#define RSVP_ADREQ 11
#define RSVP_ADREP 12
3.2 RSVP behavior - unicast
Our approach to collecting measurement information for admission
control is to originate the state collection from the ingress upon
receiving an RSVP reservation message (RESV). When an ingress
receives a new RSVP RESV message (see figure ) and local admission
control is successful, the ingress initiates aggregated admission
control by sending an ADREQ message. The FLOWSPEC from the RESV
message is used in the ADREQ message, as well as an ADMISSION
object containing a handle chosen by the ingress. The basic
exchange of messages is shown in Figure . Note that no processing
is needed in the interior of the aggregating region on the RESV or
the preceding PATH messages. But when the ingress receives a new
RESV message (i.e. a message for which it has no traffic control
state), the ingress initiates admission control. For admission
control, the ingress sends an ADmission REQuest (ADREQ) message
hop-by-hop through the interior of the aggregating region to the
egress (known from the previous RSVP hop field in the RESV
message). At each hop through the region, the node attempts to
admit the reservation. If admission control succeeds at a node,
the ADREQ message is forwarded with an optional status object to
the next hop. If admission control fails at a node, a failure
status object is appended to the ADREQ message and then the
message is forwarded. When the egress receives the ADREQ message,
an ADREP message is generated and sent back to the ingress
containing all the status objects. The ingress checks if any
interior node appended a failure status object to the message. If
there is no rejection information in the ADREP message, then the
reservation is accepted and the packets for this flow will be
marked as reserved. If there is a failure status object in the
message, the reservation is rejected and a reservation error
Berson, Vincent Expiration: February 1998 [Page 10]
Internet Draft RSVP Aggregation August 1998
message is generated.
[ Figure omitted in .txt version - see .ps version ]
Figure 2: Admission control exchange of messages
Note that if either an ADREQ or an ADREP message is lost, then the
ingress behaves as a router that lost an RSVP reservation message.
The ingress will wait until the reservation message is refreshed
and then send a new ADREQ.
3.3 RSVP behavior - multicast
Multicast behavior is more complicated due to the dynamic nature
of receivers joining and leaving groups and due to the possibility
that some hosts request reservations while other hosts do not. In
figure , there is a sender s1 upstream of router R1 and receivers
r4 and r5 downstream of routers R4 and R5. If r4 has a
reservation for a session and r5 does not, it is important that
traffic for that session with reserved markings do not travel on
the R3-R5 link (as the traffic commitments to other sessions over
that link might be disrupted). To prevent marked traffic from
transitting links without a reservation, a "reclassifier" needs to
be installed on the unreserved link (e.g. R3-R5) to remove the
reserved traffic bits in the data packets. With the reserved bits
removed, the traffic will travel as ordinary best effort.
[ Figure omitted in .txt version - see .ps version ]
Figure 3: Internet aggregating region
In order to reclassify the traffic, RSVP state will be needed at
traffic split points (such as R3). The accumulating of RSVP state
is triggered by the formation of a split point in data traffic.
When a second (or higher) multicast session join (e.g. over link
R3-R5) reaches a router (e.g. R3), the router needs to activate
RSVP state management for that router for that session. In
addition, the router needs to establish a reclassifier on the
newly joined link for the session.
The next PATH message for this session will be received and
processed by R3 (and state stored). If a RESV message is then
received on R3-R5, an ADREQ message will be sent out the link.
When an ADREP message is received from the egress (or next
downstream split point), the reservation is in place. When the
reservation is in place on all outgoing links at a node for a
session, any reclassifiers are removed. Also, if R3 receives an
ADREQ from R2 for this session, an ADREP is generated in response.
Berson, Vincent Expiration: February 1998 [Page 11]
Internet Draft RSVP Aggregation August 1998
When the penultimate outgoing link is removed from the multicast
session at a node, the RSVP state accumulation may end, and the
existing state for this session may be purged.
3.4 Other approaches
There are three other possible approaches to aggregated admission
control that may be useful in certain types of network
environments, but which have serious limitations in general. One
approach is to put the admission control request in RSVP
reservation messages. This approach is conceptually simpler than
the above scheme, but assumes that the reverse route of the data
(i.e. egress to ingress) through the aggregating region is known.
There are cases where this holds, most notably in networks using
link state routing protocols, but in general this is not the case.
The second approach to collecting admisson control information is
an RSVP path message which travels on the forward route from data
ingress to data egress. When this message is processed at each
interior node, admission control information is collected. The
accumulated admission control information is then included in a
corresponding RSVP reservation message from egress to ingress.
The disadvantage with this scheme is that each PATH message would
need to be processed by interior routers. ADREQand ADREP messages
are only generated on a new reservation.
The third approach to collecting admission control information is
by out-of-band communication, e.g. as part of routing protocols.
In this case, the ingress site can do the admission control based
on the out-of-band communication. Further work is needed in this
area.
4. Reserved traffic congestion
One last issue is traffic congestion in reserved traffic classes.
There are two ways that admitted load can cause high levels of
congestion on a router, (1) measurement based admission control
failure and (2) link failure. Measurement based admission control
failure occurs due to past load not being representative of the
future. For example, if many idle reserved sources become very
active at the same time, some links may become congested. Link
failure is caused by a link being declared down and a new set of
routes are generated. The traffic that was traversing the failed
link may now be added to an already heavily loaded link. In both of
these cases, links may become overcommitted.
For small amounts of congestion, reserved traffic can preempt best
effort traffic, i.e. best effort traffic packets are dropped, but new
Berson, Vincent Expiration: February 1998 [Page 12]
Internet Draft RSVP Aggregation August 1998
admission control requests are rejected. For larger amounts of
congestion, reserved packets need to be dropped or reservations need
to be preempted. For link failure in a per-flow IIS network, the
setup protocol would typically use reservation preempting (while
admission control mistakes are expected not to happen). With
aggregated IIS state, the point at which the routing changes may not
have setup protocol state. Thus a node typically cannot distinguish
an overload caused by a link failure from one caused by transient
heavy congestion. The response is the same for either cause of
congestion; the ingress nodes in this case will need to preempt
reservations.
5. Conclusions
This draft has described a scheme for providing Internet Integrated
Services with greatly reduced state requirements. This scheme bounds
the scheduler state at all routers in an aggregating region. For
unicast traffic, the classifier state and setup protocol state is
stored only at the border routers. For multicast traffic, full
classifier state is stored at the border routers, while a limited
amount of additional classifier and additional setup protocol state
is stored at traffic split points.
6. Acknowledgements
This draft is the result of discussions with many people particularly
Bob Braden and Bob Lindell.
REFERENCES
[1] Ballardie, T., Francis, P., and Crowcroft, J., "Core Based Trees
(CBT): An Architecture for Scalable Inter-Domain Multicast Routing,"
SIGCOMM '93.
[2] Berson, S., and Vincent, S., "Aggregation of Internet Integrated
Services State," IWQoS '98.
[3] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S.,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification," RFC 2205.
[4] Braden, R., Clark, D., and Shenker, S., "Integrated Services in the
Internet Architecture: an Overview," RFC 1633.
[5] Deering, S., Estrin, D., Farinacci, D., Jacobson, V., Liu, C., and
Wei, L., "An Architecture for Wide-Area Multicast Routing," SIGCOMM
'94.
Berson, Vincent Expiration: February 1998 [Page 13]
Internet Draft RSVP Aggregation August 1998
[6] Floyd, S., and Jacobson, V., "Link-sharing and Resource Management
Models for Packet Networks," IEEE/ACM Transactions on Networking,
Vol. 3 No. 4, pp. 365-386, August 1995.
[7] Guerin, R., Blake, S., and Herzog, S., "Aggregating RSVP-based QoS
Requests," Internet Draft.
[8] Jamin, S., Shenker, S., and Danzig, P., "Comparison of Measurement-
based Admission Control Algorithms for Controlled-Load Service,"
Infocomm '97.
[9] Waitzman, D., Partridge, C., and Deering, S., "Distance Vector
Multicast Routing Protocol," RFC 1075.
[10] Wroclawski, J., "Specification of the Controlled-Load Network
Element Service," RFC 2211.
Security Considerations
Security considerations have not been addressed in this draft.
Author's Address
Steven Berson
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310 822 1511
EMail: berson@isi.edu
Subramaniam Vincent
USC Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292
Phone: +1 310 822 1511
EMail: svincent@isi.edu
Berson, Vincent Expiration: February 1998 [Page 14]
| PAFTECH AB 2003-2026 | 2026-04-22 17:10:14 |