Tcp-ip tutorial and technical overview

For example, a flow might consist of one video stream between a given host pair.
To establish the video connection in both directions, two flows are necessary.
Each application that initiates data flows can specify which QoS are required forthis flow. If the videoconferencing tool needs a minimum bandwidth of 128 kbpsand a minimum packet delay of 100 ms to assure a continuous video display, sucha QoSs can be reserved for this connection.
Differentiated Services mechanism do not use per-flow signaling. Different servicelevels can be allocated to different groups of Internet users, which means that thewhole traffic is split into groups with different QoS parameters. This reduces themaintenance overhead in comparison to Integrated Services. The following sectionsdescribe Integrated Services and Differentiated Services in more detail.
10.2 Integrated Services
The Integrated Services (IS) model was defined by an IETF working group to bethe keystone of the planned IS Internet. This Internet architecture model includesthe currently used best-effort service and a new real-time service that providesfunctions to reserve bandwidth on the Internet.
IS was developed to optimize network and resource utilization for new applications,such as real-time multimedia, which requires QoS guarantees. Because of routingdelays and congestion losses, real-time applications do not work very well on thecurrent best-effort Internet. Videoconferencing, video broadcast and audioconferencing software needs a guaranteed bandwidth to provide video and audio inacceptable quality. Integrated Services makes it possible to divide the Internettraffic into the standard best-effort traffic for traditional uses and application dataflows with guaranteed QoS.
To support the Integrated Services model, an Internet router must be able toprovide an appropriate QoS for each flow, in accordance with the service model.
The router function that provides different qualities of service is called traffic control.
It consists of the following components: Packet scheduler
The packet scheduler manages the forwarding of different packet streams inhosts and routers, based on their service class, using queue managementand various scheduling algorithms. The packet scheduler must ensure thatthe packet delivery corresponds to the QoS parameter for each flow. Ascheduler can also police or shape the traffic to conform to a certain level ofservice. The packet scheduler must be implemented at the point wherepackets are queued. This is typically the output driver level of an operatingsystem and corresponds to the link layer protocol.
Packet classifier
The packet classifier identifies packets of an IP flow in hosts and routers thatwill receive a certain level of service. To realize effective traffic control, eachincoming packet is mapped by the classifier into a specific class. All packetsthat are classified in the same class get the same treatment from the packetscheduler. The choice of a class is based upon the source and destination IPaddress and port number in the existing packet header or an additionalclassification number which must be added to each packet. A class cancorrespond to a broad category of flows.
For example, all video flows from a videoconferencing with severalparticipants can belong to one service class. But it is also possible that onlyone flow belongs to a specific service class.
Admission control
The admission control contains the decision algorithm that a router uses todetermine if there are enough routing resources to accept the requested QoSfor a new flow. If there are not enough free routing resources, accepting anew flow would impact earlier guarantees and the new flow must be rejected.
If the new flow is accepted, the reservation instance in the router assigns thepacket classifier and the packet scheduler to reserve the requested QoS forthis flow. Admission control is invoked at each router along a reservationpath, to make a local accept/reject decision at the time a host requests areal-time service. The admission control algorithm must be consistent withthe service model.
Please note that admission control is sometimes confused with policy control,which is a packet-by-packet function, processed by the packet scheduler. Itensures that a host does not violate its promised traffic characteristics.
Nevertheless, to ensure that QoS guarantees are honored, the admissioncontrol will be concerned with enforcing administrative policies on resourcereservations. Some policies will be used to check the user authentification fora requested reservation. Unauthorized reservation requests can be rejected.
Admission control will play an important role in accounting costs for Internetresources in the future.
Figure 284 shows the operation of the Integrated Service model into a host and arouter.
Integrated Services use the Reservation Protocol (RSVP) for the signalling of thereservation messages. The IS instances communicate via RSVP to create andmaintain flow-specific states in the endpoint hosts and in routers along the path of aflow. Please see 10.2.2, “The Reservation Protocol (RSVP)” on page 511 for adetailed description of the RSVP protocol.
As shown in Figure 284, the application that wants to send data packets in areserved flow, communicates with the reservation instance RSVP. The RSVPprotocol tries to set up a flow reservation with the requested QoS, which will be accepted if the application fulfilled the policy restrictions and the routers can handlethe requested QoS. RSVP advises the packet classifier and packet scheduler ineach node to process the packets for this flow adequately. If the application nowdelivers the data packets to the classifier in the first node, which has mapped thisflow into a specific service class complying the requested QoS, the flow isrecognized with the sender IP address and is transmitted to the packet scheduler.
The packet scheduler forwards the packets, dependent on their service class, to thenext router or, finally, to the receiving host.
Because RSVP is a simplex protocol, QoS reservations are only made in onedirection, from the sending node to the receiving node. If the application in ourexample wants to cancel the reservation for the data flow, it sends a message tothe reservation instance which frees the reserved QoS resources in all routersalong the path, and the resources can be used for other flows. The ISspecifications are defined in RFC 1633.
10.2.1 Service Classes
The Integrated Services model uses different classes of service that are defined bythe integrated services IETF working group. Depending on the application, thoseservice classes provide tighter or looser bounds on QoS controls. The current ISmodel includes the Guaranteed Service which is defined in RFC 2212 and theControlled Load Service which is defined in RFC 2211. To understand theseservice classes, some terms need to be explained.
Because the IS model provides per-flow reservations, each flow has assigned aflow descriptor. The flow descriptor defines the traffic and QoS characteristics for aspecific flow of data packets. In the IS specifications, the flow descriptor consist ofa filter specification (filterspec) and a flow specification (flowspec).
The filterspec is used to identify the packets that belong to a specific flow with thesender IP address and source port. The information from the filterspec is used inthe packet classifier. The flowspec contains a set of parameters that are called theinvocation information. It is possible to assort the invocation information in twogroups: The Tspec describes the traffic characteristics of the requested service. In the ISmodel, this Tspec is represented with a token bucket filter. This principle defines adata-flow control mechanism that adds characters (token) in periodical timeintervals into a buffer (bucket) and allows a data packet to leave the sender only ifthere are at least as many tokens in the bucket as the packet length of the datapacket. This strategy allows a precise control of the time interval between two datapackets on the network. The token bucket system is specified by two parameters:the token rate r, which represents the rate at which tokens are placed into thebucket and the bucket capacity b. Both r and b must be positive.
The parameter r specifies the long term data rate and is measured in bytes of IPdatagrams per second. The value of this parameter can range from 1 byte persecond to 40 terabytes per second. The parameter b specifies the burst data rateallowed by the system and is measured in bytes. The value of this parameter canrange from 1 byte to 250 gigabytes. The range of values allowed for theseparameters is intentionally large to be prepared for future network technologies.
The network elements are not expected to support the full range of the values.
Traffic that passes the token bucket filter must obey the rule that over all timeperiods T, the amount of data sent does not exceed rT+b, where r and b are thetoken bucket parameters.
Two other token bucket parameters are also part of the Tspec. The minimumpoliced unit m and the maximum packet size M. The parameter m specifies theminimum IP datagram size in bytes. Smaller packets are counted against the tokenbucket filter as being of size m. The parameter M specifies the maximum packetsize in bytes that conforms to the Tspec. Network elements must reject a servicerequest if the requested maximum packet size is larger than the MTU size of thelink. Summarizing, the token bucket filter is a policing function that isolates thepackets that conform to the traffic specifications from the ones that do not conform.
The Service Request Specification (Rspec) specifies the Quality of Service theapplication wants to request for a specific flow. This information depends on thetype of service and the needs of the QoS requesting application. It may consist ofa specific bandwidth, a maximum packet delay or a maximum packet loss rate. Inthe IS implementation, the information from Tspec and Rspec is used in the packetscheduler.
10.2.1.1 Controlled Load Service
The Controlled Load Service is intended to support the class of applications that
are highly sensitive to overloaded conditions in the Internet, such as real-time
applications. These applications are working well on unloaded networks but
degrade quickly under overloaded conditions. If an application uses the Controlled
Load Service, the performance of a specific data flow does not degrade if the
network load increases.
The Controlled Load Service offers only one service level which is intentionallyminimal. There are no optional features or capabilities in the specification. Theservice offers only a single function. It approximates best-effort service over lightlyloaded networks. This means that applications that make QoS reservations usingControlled Load Services are provided with service closely equivalent to the serviceprovided to uncontrolled (best-effort) traffic under lightly loaded conditions. In thiscontext, lightly loaded conditions means that a very high percentage of transmittedpackets will be successfully delivered to the destination, and the transit delay for avery high percentage of the delivered packets will not greatly exceed the minimumtransit delay.
Each router in a network that accepts requests for Controlled Load Services mustensure that adequate bandwidth and packet processing resources are available tohandle QoS reservation requests. This can be realized with active admissioncontrol. Before a router accepts a new QoS reservation, represented by the Tspec,it must consider all important resources, such as link bandwidth, router or switchport buffer space and computational capacity of the packet forwarding.
The Controlled Load Service class does not accept or make use of specific targetvalues for control parameters such as bandwidth, delay or loss. Applications thatuse Controlled Load Services must be proof against small amounts of packet lossand packet delays.
QoS reservations using Controlled Load Services need to provide a Tspec thatconsists of the token bucket parameters r and b as well as the minimum policedunit m and the maximum packet size M. An Rspec is not necessary becauseControlled Load Services doesn't provide functions to reserve a fixed bandwidth orguarantee minimum packet delays. Controlled Load Service provides QoS controlonly for traffic that conforms to the Tspec that was provided at setup time. Thismeans that the service guarantees only apply for packets that respect the tokenbucket rule that over all time periods T, the amount of data sent can not exceedrT+b.
Controlled Load Service is designed for applications that can tolerate reasonableamount of packet loss and delay, such as audio and videoconferencing software.
10.2.1.2 Guaranteed Service
The Guaranteed Service model provides functions that assure that datagrams will
arrive within a guaranteed delivery time. This means that every packet of a flow
that conforms to the traffic specifications will arrive at least at the maximum delay
time that is specified in the flow descriptor. Guaranteed Service is used for
applications that need a guarantee that a datagram will arrive at the receiver not
later than a certain time after it was transmitted by its source.
For example, real-time multimedia applications, such as video and audiobroadcasting systems that use streaming technologies, cannot use datagrams that arrive after their proper play-back time. Applications that have hard real-timerequirements, such as real-time distribution of financial data (share prices), will alsorequire guaranteed service. Guaranteed Service does not minimize the jitter (thedifference between the minimal and maximal datagram delays), but it controls themaximum queueing delay.
The Guaranteed Service model represents the extreme end of delay control fornetworks. Other service models providing delay control have much weaker delayrestrictions. Therefore, Guaranteed Service is only useful if it is provided by everyrouter along the reservation path.
Guaranteed Service gives applications considerable control over their delay. It isimportant to understand that the delay in an IP network has two parts: a fixedtransmission delay and a variable queueing delay. The fixed delay depends on thechosen path, which is determined not by guaranteed service but by the setupmechanism. All data packets in an IP network have a minimum delay that is limitedby the speed of light and the turnaround time of the data packets in all routers onthe routing path. The queueing delay is determined by Guaranteed Service and itis controlled by two parameters: the token bucket (in particular, the bucket size b)and the bandwidth R that is requested for the reservation. These parameters areused to construct the fluid model for the end-to-end behavior of a flow that usesGuaranteed Services.
The fluid model specifies the service that would be provided by a dedicated linkbetween sender and receiver that provides the bandwidth R. In the fluid model, theflow's service is completely independent from the service for other flows. Thedefinition of guaranteed service relies on the result that the fluid delay of a flowobeying a token bucket (r,b) and being served by a line with bandwidth R isbounded by b/R as long as R is not less than r. Guaranteed Service approximatesthis behavior with the service rate R, where now R is a share of bandwidth throughthe routing path and not the bandwidth of a dedicated line.
In the Guaranteed Service model, Tspec and Rspec are used to set up a flowreservation. The Tspec is represented by the token bucket parameters. TheRspec contains the parameter R that specifies the bandwidth for the flowreservation. The Guaranteed Service model is defined in RFC 2212.
10.2.2 The Reservation Protocol (RSVP)
The Integrated Services model uses the Reservation Protocol (RSVP) to set up andcontrol QoS reservations. RSVP is defined in RFC 2205 and has the status of aproposed standard. Because RSVP is an Internet control protocol and not arouting protocol, it requires an existing routing protocol to operate. The RSVPprotocol runs on top of IP and UDP and must be implemented in all routers on thereservation path. The key concepts of RSVP are flows and reservations.
An RSVP reservation applies for a specific flow of data packets on a specific paththrough the routers. As described in 10.1, “Why QoS?” on page 505, a flow isdefined as a distinguishable stream of related datagrams from a unique sender to aunique receiver. If the receiver is a multicast address, a flow can reach multiplereceivers. RSVP provides the same service for unicast and multicast flows. Eachflow is identified from RSVP by its destination IP address and destination port. Allflows have dedicated a flow descriptor which contains the QoS that a specific flowrequires. The RSVP protocol does not understand the contents of the flow descriptor. It is carried as an opaque object by RSVP and is delivered to therouter's traffic control functions (packet classifier and scheduler) for processing.
Because RSVP is a simplex protocol, reservations are only done in one direction.
For duplex connections, such as video and audio conferences where each senderis also a receiver, it is necessary to set up two RSVP sessions for each station.
The RSVP protocol is receiver-initiated. Using RSVP signalling messages, thesender provides a specific QoS to the receiver which sends an RSVP reservationmessage back with the QoS that should be reserved for the flow from the sender tothe receiver. This behavior considers the different QoS requirements forheterogeneous receivers in large multicast groups. The sender doesn't need toknow the characteristics of all possible receivers to structure the reservations.
To establish a reservation with RSVP the receivers send reservation requests tothe senders depending on their system capabilities. For example, a fastworkstation and a slow PC want to receive a high-quality MPEG video stream with30 frames per second which has a data rate of 1.5 Mbps. The workstation hasenough CPU performance to decode the video stream, but the PC can only decode10 frames per second. If the video server sends the messages to the two receiversthat it can provide the 1.5 Mbps video stream, the workstation can return areservation request for the full 1.5 Mbps. But the PC doesn't need the fullbandwidth for its flow because it cannot decode all frames. So the PC may send areservation request for a flow with 10 frames per second and 500 kbps.
10.2.2.1 RSVP Operation
A basic part of a resource reservation is the path. The path is the way of a packet
flow through the different routers from the sender to the receiver. All packets that
belong to a specific flow will use the same path. The path gets determined if a
sender generates RSVP path messages that travel in the same direction as the
flow. Each sender host periodically sends a path message for each data flow it
originates. The path message contains traffic information that describes the QoS
for a specific flow. Because RSVP doesn't handle routing by itself, it uses the
information from the routing tables in each router to forward the RSVP messages.
If the path message reaches the first RSVP router, the router stores the IP addressfrom the last hop field in the message, which is the address of the sender. Thenthe router inserts its own IP address into the last hop field, sends the path messageto the next router and the process repeats until the message has reached thereceiver. At the end of this process, each router will know the address from theprevious router and the path can be accessed backwards. Figure 287 onpage 513 shows the process of the path definition.
Routers that have received a path message are prepared to process resourcereservations for a flow. All packets that belongs to this flow will take the same waythrough the routers; the way that was defined with the path messages.
The status in a system after sending the path messages is the following: Allreceivers know that a sender can provide a special QoS for a flow and all routersknow about the possible resource reservation for this flow.
Now if a receiver wants to reserve QoS for this flow, it sends a reservation (resv)message. The reservation message contains the QoS requested from this receiverfor a specific flow and is represented by the filterspec and flowspec that form theflow descriptor. The receiver sends the resv message to the last router in the pathwith the address it received from the path message. Because every RSVP-capabledevice knows the address of the previous device on the path, reservationmessages travel the path in reverse direction towards the sender and establish theresource reservation in every router. Figure 288 on page 514 shows the flow ofthe reservation messages trough the routers.
At each node, a reservation request initiates two actions: The RSVP process passes the request to the admission control and policycontrol instance on the node. The admission control checks if the router hasthe necessary resources to establish the new QoS reservation and the policycontrol checks if the application has the authorization to make QoS requests. Ifone of these tests fails, the reservation is rejected and the RSVP processreturns a ResvErr error message to the appropriate receiver. If both checkssucceed, the node uses the filterspec information in the resv message to setthe packet classifier and the flowspec information to set the packet scheduler.
After this, the packet classifier will recognize the packets that belong to thisflow and the packet scheduler will obtain the desired QoS defined by theflowspec.
Figure 289 on page 515 shows the reservation process in an RSVP router.
After a successful admission and policy check, a reservation request ispropagated upstream towards the sender. In a multicast environment, areceiver can get data from multiple senders. The set of sender hosts to whicha given reservation request is propagated is called the scope of that request.
The reservation request that is forwarded by a node after a successfulreservation can differ from the request that was received from the previous hopdownstream. One possible reason for this is that the traffic control mechanismmay modify the flowspec hop-by-hop. Another, more important reason is thatin a multicast environment, reservations from different downstream branchesbut for the same sender are merged together as they travel across theupstream path. This merging is necessary to conserve resources in therouters.
A successful reservation request propagates upstream along the multicast treeuntil it reaches a point where an existing reservation is equal or greater thanthat being requested. At this point, the arriving request is merged with thereservation in place and need not be forwarded further.
Figure 290 on page 516 shows the reservation merging for a multicast flow.
Figure 290. RSVP Reservation Merging for Multicast Flows If the reservation request reaches the sender, the QoS reservation was establishedin every router on the path and the application can start to send packetsdownstream to the receivers. The packet classifier and the packet scheduler ineach router make sure that the packets are forwarded according to the requestedQoS.
This type of reservation is only reasonable if all routers on the path support RSVP.
If only one router doesn't support resource reservation, the service cannot beguaranteed for the whole path because of the "best effort" restrictions that apply fornormal routers. A router on the path that doesn't support RSVP would be abottleneck for the flow.
A receiver that originates a reservation request can also request a confirmationmessage that indicates that the request was installed in the network. The receiverincludes a confirmation request in the Resv message and gets a ResvConfmessage if the reservation was established successfully.
RSVP resource reservations maintain soft-state in routers and hosts, which meansthat a reservation is canceled if RSVP doesn't send refresh messages along thepath for an existing reservation. This allows route changes without resulting inprotocol overhead. Path messages must also be resent because the path statefields in the routers will be reset after a time-out period.
Path and reservation states can also be deleted with RSVP teardown messages.
There are two types of teardown messages: PathTear messages travel downstream from the point of initiation to allreceivers, deleting the path state as well as all dependent reservation states ineach RSVP-capable device.
ResvTear messages travel upstream from the point of initiation to all senders,deleting reservation states in all routers and hosts.
Teardown request can be initiated by senders, receivers or routers that notice astate timeout. Because of the soft-state principle of RSVP reservations, it is notreally necessary to explicitly tear down an old reservation. Nevertheless, it isrecommended that all end hosts send a teardown request if a consistingreservation is no longer needed.
10.2.2.2 RSVP Reservation Styles
Users of multicast multimedia applications often receive flows from different
senders. In the reservation process described in 10.2.2.1, “RSVP Operation” on
page 512, a receiver must initiate a separate reservation request for each flow it
wants to receive. But RSVP provides a more flexible way to reserve QoS for flows
from different senders. A reservation request includes a set of options that are
called the reservation style. One of these options deals with the treatment of
reservations for different senders within the same session. The receiver can
establish a distinct reservation for each sender or make a single shared reservation
for all packets from the senders in one session.
Another option defines how the senders for a reservation request are selected. It ispossible to specify an explicit list or a wildcard that selects the senders belonging toone session. In an explicit sender-selection reservation, a filterspec must identifyexactly one sender. In a wildcard sender-selection the filterspec is not needed.
Figure 291 shows the reservation styles that are defined with this reservationoption: Distinct
The Wildcard-Filter style uses the options shared reservation andwildcard sender selection. This reservation style establishes a singlereservation for all senders in a session. Reservations from differentsenders are merged together along the path so that only the biggestreservation request reaches the senders.
A wildcard reservation is forwarded upstream to all sender hosts. If newsenders appear in the session, for example, new members enter avideoconferencing, the reservation is extended to this new senders.
The Fixed-Filter style uses the option's distinct reservations and explicitsender selection. This means that a distinct reservation is created fordata packets from a particular sender. Packets from different sendersthat are in the the same session do not share reservations.
The Shared-Explicit style uses the option's shared reservation andexplicit sender selection. This means that a single reservation coversflows from a specified subset of senders. Therefore a sender list mustbe included into the reservation request from the receiver.
Reservations established in shared style (WF and SE) are mostly used for multicastapplications. For this type of application, it is unlikely that several data sourcestransmits data simultaneously so that it is not necessary to reserve QoS for eachsender.
For example, in an audio conference that consists of five participants, every stationsends a data stream with 64 kbps. With a Fixed-Filter style reservation, allmembers of the conference must establish four separate 64 kbps reservations forthe flows from the other senders. But in an audio conference most times only oneor two people speak at the same time. Therefore it would be sufficient to reserve abandwidth of 128 kbps for all senders, because most audio conferencing softwareuses silence suppression which means that if a person doesn't speak, no packetsare sent. This can be realized if every receiver makes one shared reservation of128 kbps for all senders.
Using the Shared-Explicit style, all receivers must explicitly identify all other sendersin the conference. With Wildcard-Filter style the reservation counts for everysender that matches the reservation specifications. If, for example the audioconferencing tool sends the data packets to a special TCP/IP port, the receiverscan make a Wildcard-Filter reservation for all packets with this destination port.
10.2.2.3 RSVP Messages Format
Basically an RSVP message consists of a common header, followed by a body
consisting of a variable number of objects. The number and the content of these
objects depends on the message type. The message objects contain the
information that is necessary to realize resource reservations, for example the flow
descriptor or the reservation style. In most cases, the order of the objects in an
RSVP message makes no logical difference. RFC 2205 recommends that an RSVP
implementation should use the object order defined in the RFC but accept the
objects in any permissible order. Figure 292 shows the common header of a
RSVP message:
0 1234567 89101112131415 16 920212223 2425262728293 31 4-bit RSVP protocol number. The current version is 1.
4-bit field that is reserved for flags. No flags are defined yet.
8-bit field that specifies the message type: 16-bit field. The Checksum can be used by receivers of an RSVPmessage to detect errors in the transmission of this message.
8-bit field, which contains the IP TTL value the message was sent with.
16-bit field that contains the total length of the RSVP message includingthe common header and all objects that follow. The length is counted inbytes.
The RSVP objects that follow the common header consist of a 32-bit header andone or more 32-bit words. Figure 293 shows the RSVP object header: 0 1234567891011121314151617181920212223 2425262728293031 16-bit field that contains the object length in bytes. This must be amultiple of 4. The minimum length is 4 bytes.
Identifies the object class. The following classes are defined: The NULL object has a Class-Number of zero. The length of thisobject must be at least 4, but can be any multiple of 4. The NULLobject can appear anywhere in the object sequence of an RSVPmessage. The content is ignored by the receiver.
The session object contains the IP destination address, the IPprotocol ID and the destination port, to define a specific session forthe other objects that follow. The session object is required in everyRSVP message.
The RSVP_HOP object contains the IP address of the node thatsent this message and a logical outgoing interface handle. Fordownstream messages (for example, path messages) theRSVP_HOP object represents a PHOP (previous hop) object and forupstream messages (for example, resv messages) it represents anNHOP (next hop) object.
The Time_Values object contains the refresh period for path andreservation messages. If these messages are not refreshed withinthe specified time period, the path or reservation state is canceled.
The style object defines the reservation style and some style-specificinformation that is not in Flowspec or Fiterspec. The style object isrequired in every resv message.
This object specifies the required QoS in reservation messages.
The Filterspec object defines which data packets receive the QoSspecified in the Flowspec.
This object contains the sender IP address and additionaldemultiplexing information, which is used to identify a sender. TheSender_Template is required in every Path message.
This object defines the traffic characteristics of a data flow from asender. The Sender_Tspec is required in all path messages.
The adspec object is used to provide advertising information to thetraffic control modules in the RSVP nodes along the path.
This object specifies an error in a PathErr, ResvErr, or aconfirmation in a ResvConf message.
This object contains information that allows a policy module todecide whether an associated reservation is administrativelypermitted or not. It can be used in Path, Resv, PathErr, or ResvErrmessages.
The integrity object contains cryptographic data to authenticate theoriginating node and to verify the contents of an RSVP message.
The Scope object contains an explicit list of sender hosts to whichthe information in the message are sent. The object can appear ina Resv, ResvErr, or ResvTear messages.
This object contains the IP address of a receiver that requestsconfirmation for its reservation. It can be used in a Resv orResvConf message.
The C-Type specifies the object type within the class number. Differentobject types are used for IPv4 and IPv6.
The object content depend on the object type and has a maximumlength of 65528 bytes.
All RSVP messages are built of a variable number of objects. The recommendedobject order for the most important RSVP messages, the path and the resvmessage are shown in the following. Figure 294 gives an overview about theformat of the RSVP path message. Objects that can appear in a path message butthat are not required are parenthesized.
0 1234567 89101112131415 16 920212223 2425262728293 31 If the Integrity object is used in the path message, it must immediately follow thecommon header. The order of the other objects may differ in different RSVPimplementations, but the one shown above is recommended by the RFC.
The RSVP Resv messages looks similar to the path message. Figure 295 onpage 522 shows the objects used for reservation messages: 0 1234567 89101112131415 16 920212223 2425262728293 31 As in the path message, the Integrity object must follow the common header if it isused. Another restriction applies for the Style object and the following flowdescriptor list. They must occur at the end of the message. The order of the otherobjects follows the recommendation from the RFC.
For a detailed description of the RSVP message structure and the handling of thedifferent reservation styles in reservation messages, please consult RFC 2205.
10.2.3 The Future of Integrated Services
At the moment it is not known if the integrated services model will win recognitionin the future Internet. More and more router manufacturers support RSVP in theirrouters. But to provide IS for a larger group of users, many Internet routers shouldsupport RSVP.
An important point that should be monitored by the router manufacturers is thetraffic control overhead in RSVP-capable routers that may decrease the routingperformance. The more data flows are passing a router, the more RSVP sessionsmust be handled by the RSVP daemon inside of the router. Router manufacturersmust make sure that in high traffic situations a router is not blocked with managingRSVP sessions instead of routing data packets and keeping up with routing tableupdates.
Future extensions of the policy control module may implement a priority mechanismthat allows users to send reservation requests with higher priority than others. Ifthe routers on the path run out of routing capacity, the high-priority requests will befavored. This may be coupled with a billing system that charges the user for

Source: http://www.ila.lt/moduliai/T120B024/papild/RSVP.pdf