blank.gif (43 bytes)

Church Of The
Swimming Elephant

3.11.2 RSVP/Traffic Control Interface Connected: An Internet Encyclopedia
3.11.2 RSVP/Traffic Control Interface

Up: Connected: An Internet Encyclopedia
Up: Requests For Comments
Up: RFC 2205
Up: 3. RSVP Functional Specification
Up: 3.11 RSVP Interfaces
Prev: 3.11.1 Application/RSVP Interface
Next: 3.11.3 RSVP/Policy Control Interface

3.11.2 RSVP/Traffic Control Interface

3.11.2 RSVP/Traffic Control Interface

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.

  1. IP layer

    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.

  2. "The network"

    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.

  3. Link-layer driver

    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".

  • Make a Reservation

                  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.

  • Modify Reservation

                  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.

  • Delete Flowspec

                  Call: TC_DelFlowspec( Interface, RHandle )

    This call will delete an existing reservation, including the flowspec and all associated filter specs.

  • Add Filter Spec

                  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.

  • Delete Filter Spec

                  Call: TC_DelFilter( Interface, FHandle )

    This call is used to remove a specific filter, specified by FHandle.

  • OPWA Update

                  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.

  • Preemption Upcall

                  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.

Next: 3.11.3 RSVP/Policy Control Interface

Connected: An Internet Encyclopedia
3.11.2 RSVP/Traffic Control Interface


Protect yourself from cyberstalkers, identity thieves, and those who would snoop on you.
Stop spam from invading your inbox without losing the mail you want. We give you more control over your e-mail than any other service.
Block popups, ads, and malicious scripts while you surf the net through our anonymous proxies.
Participate in Usenet, host your web files, easily send anonymous messages, and more, much more.
All private, all encrypted, all secure, all in an easy to use service, and all for only $5.95 a month!

Service Details

Have you gone to church today?
All pages ©1999, 2000, 2001, 2002, 2003 Church of the Swimming Elephant unless otherwise stated
Church of the Swimming Elephant©1999, 2000, 2001, 2002, 2003 is a wholly owned subsidiary of Packetderm, LLC.

Packetderm, LLC
210 Park Ave #308
Worcester, MA 01609