It is difficult to present a generic interface to traffic control, because the details of establishing a reservation depend strongly upon the particular link layer technology in use on an interface.
Merging of RSVP reservations is required because of multicast data delivery, which replicates data packets for delivery to different next-hop nodes. At each such replication point, RSVP must merge reservation requests from the corresponding next hops by computing the "maximum" of their flowspecs. At a given router or host, one or more of the following three replication locations may be in use.
IP multicast forwarding performs replication in the IP layer. In this case, RSVP must merge the reservations that are in place on the corresponding outgoing interfaces in order to forward a request upstream.
Replication might take place downstream from the node, e.g., in a broadcast LAN, in link-layer switches, or in a mesh of non-RSVP-capable routers (see Section 2.8). In these cases, RSVP must merge the reservations from the different next hops in order to make the reservation on the single outgoing interface. It must also merge reservations requests from all outgoing interfaces in order to forward a request upstream.
For a multi-access technology, replication may occur in the link layer driver or interface card. For example, this case might arise when there is a separate ATM point- to-point VC towards each next hop. RSVP may need to apply traffic control independently to each VC, without merging requests from different next hops.
In general, these complexities do not impact the protocol processing that is required by RSVP, except to determine exactly what reservation requests need to be merged. It may be desirable to organize an RSVP implementation into two parts: a core that performs link-layer-independent processing, and a link-layer-dependent adaptation layer. However, we present here a generic interface that assumes that replication can occur only at the IP layer or in "the network".
Call: TC_AddFlowspec( Interface, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_Flags )
-> RHandle [, Fwd_Flowspec]
The TC_Flowspec parameter defines the desired effective QoS to admission control; its value is computed as the maximum over the flowspecs of different next hops (see the Compare_Flowspecs call below). The TC_Tspec parameter defines the effective sender Tspec Path_Te (see Section 2.2). The TC_Adspec parameter defines the effective Adspec. The Police_Flags parameter carries the three flags E_Police_Flag, M_Police_Flag, and B_Police_Flag; see Section 3.8.
If this call is successful, it establishes a new reservation channel corresponding to RHandle; otherwise, it returns an error code. The opaque number RHandle is used by the caller for subsequent references to this reservation. If the traffic control service updates the flowspec, the call will also return the updated object as Fwd_Flowspec.
Call: TC_ModFlowspec( Interface, RHandle, TC_Flowspec,
TC_Tspec, TC_Adspec, Police_flags )
[ -> Fwd_Flowspec ]
This call is used to modify an existing reservation. TC_Flowspec is passed to Admission Control; if it is rejected, the current flowspec is left in force. The corresponding filter specs, if any, are not affected. The other parameters are defined as in TC_AddFlowspec. If the service updates the flowspec, the call will also return the updated object as Fwd_Flowspec.
Call: TC_DelFlowspec( Interface, RHandle )
This call will delete an existing reservation, including the flowspec and all associated filter specs.
Call: TC_AddFilter( Interface, RHandle,
Session , FilterSpec ) -> FHandle
This call is used to associate an additional filter spec with the reservation specified by the given RHandle, following a successful TC_AddFlowspec call. This call returns a filter handle FHandle.
Call: TC_DelFilter( Interface, FHandle )
This call is used to remove a specific filter, specified by FHandle.
Call: TC_Advertise( Interface, Adspec,
Non_RSVP_Hop_flag ) -> New_Adspec
This call is used for OPWA to compute the outgoing advertisement New_Adspec for a specified interface. The flag bit Non_RSVP_Hop_flag should be set whenever the RSVP daemon detects that the previous RSVP hop included one or more non-RSVP-capable routers. TC_Advertise will insert this information into New_Adspec to indicate that a non- integrated-service hop was found; see Section 3.8.
Upcall: TC_Preempt() -> RHandle, Reason_code
In order to grant a new reservation request, the admission control and/or policy control modules may preempt one or more existing reservations. This will trigger a TC_Preempt() upcall to RSVP for each preempted reservation, passing the RHandle of the reservation and a sub-code indicating the reason.