How to implement RSVP protocols in the H.323 and SIP system Lu Zheng 2003/08/19 Abstract: This article mainly introduces the use of RSVP protocols in IP network communication protocols H.323 and SIP, and special in voice / video communication data Sex, then described in detail how the Vocal system uses RAPI to implement QoS management of RSVP, and how to improve the performance of RSVP in Vocal, and discusses how to modify the data structure in RAPI when using DiffServ, so that RSVP is implemented. Map of DIFFSERV. Preface: RSVP (Resource Reserved Agreement) is a service quality protocol, which is also a business open protocol. Of course it is a large agreement on the Internet. If it is a banknote flowing on the network, this is described It can be said that it is right, but uses the RSVP message, the endpoint application can propose network bandwidth and buffer size and delay in data transfer according to the requirements, and also determine the policy of transmitting scheduling along the router along the way. QoS of a data stream for control. RSVP supports two service types: controlled payload services and guarantee services, the former is a very light load of the network, all data streams are handled in a way as they do, and the network buffer is empty, for audio signals This method is just right, and the latter is not like this, not only requiring bandwidth, but also requires the maximum transmission delay, then the result is that the result will not make QoS very significantly when the network is increased. If the transfer type supported by RSVP is distinguished, it can be divided into three transmission types: Best-Effort, rate-sensitive and delay-sensitive. Data stream service used to support these transport types relies on ensuring QoS protocol implementation. For example, various TCP / IP protocols are the transmission service protocols that follow the best performance transmission: TFTP, HTTP, SMTP, POP3, etc.; rate sensitive transmission gives up timely sex, and ensures transmission rate. For example: rate sensitive transmission request 128 Kbps bandwidth, such as the actual transmission 256 Kbps in the extended period, the router may perform data queue buffer, and delay transmission; this type of transmission is related to the use of the electric switching network, of course, in Internet main network and edge network There is also a case where the RSVP service supports rate sensitive transmission, called a bit rate guarantee service. Delay-sensitive transmission requires timely transmission, and thus changes its rate. For example: SIP or H.323 protocol transmission adopts the H.261 protocol to compress the image and the traffic may reach 384-768kbps, 384kbps may correspond to a static background, while 768kbps may be a dynamic image. People who are familiar with the H.261 agreement know that there are two compression methods of I-Frame and P-Frame in H.261. The former is local compression, then a quenched data spike is inevitably produced, while the latter and average bandwidth requirements And close, a Microsoft Netmeeting produces an I-Frame every 15 P-Frames, since a single frame requires that the decoder speed is not allowed, or the transmission of the I-FRAME must be given a specific priority. Level coordination, RSVP service supports delay sensitive transmission, which can be seen as hybrids for controlling delay service (non-real service) and forecast service (real-time service).
The service type and transmission type of RSVP is explained in detail so that we can see that QoS guarantees are more complicated in H.323 or SIP-based video communication systems, that is, there is a service that delay sensitive transmission. The service-sensitive service, RSVP is currently available to these two services, I will explain how to implement RSVP in the H.323 and SIP protocol stacks, focus on VOVIDA Vocal The SIP implementation is implemented, but here is the case where point-to-point, and does not introduce multi-point interconnection and broadcast. The specific content of the RSVP resource reserved protocol can see the specific definition of RSVP in RFC 1633, which defines the basic API function calls related to RSVP in Draft-IETF-RSVP-RAPI-01.txt. The RSVP work order is described below: The sender sends a PATH message. The message contains data service features. The message is transmitted along the selected path, and the router along the path is prepared by PATH. After receiving the path message, according to the reception party Business features and the required QoS calculations required for the resources, send the resv message, including the parameters included in the message including the requested bandwidth, returning the original path of the PATH, and the router along the way receives the ResV operation before executing resource reservation operating. The sender receives the user data after receiving the Resv message. Briefly describe how to implement RSVP function in the H.323 protocol: For a H.323 or SIP multimedia communication system, in order to ensure the quality of real-time communication, many aspects are used to ensure QoS, for H.323 It is said that there is no SIP, and there are several ways to enhance QoS guarantee in the H.323v3 version, and the situation is not considered for the case. a. Enhanced RAS process, indicated whether there is resource reservation (B. Enhanced ability exchange process, the transmission and reception endpoint has RSVP function, can have RSVP capabilities in both parties (RSVP belongs to a combination of capacity collection Part), a parameter QoScapability defines a parameter QoScapability in OpenLogicalChannel primitives; C. Enhanced logical channel capabilities contain both paths and resvs in the logical channel opening process. Let's use the figure to represent the open process of the logical channel and the resource reservation process: 1. Send the endpoint to the receiving endpoint to the OpenLogicalChannel message in QoScapability in QoScapability and the RSVP parameters and integrated business categories. 2. Receive endpoint Create an RSVP session (call Rapi_Session API) Send OpenLogicalChannel Ack to the send endpoint. 3. In the OpenLogical ACK, FlowControl = 0 is included, suppressing current media data streams. 4. 4 and 5 show that the transmit endpoint and the receiving endpoint perform the RSVP process. 5. The receiving endpoint receives ResvConfirm and knows that the reservation is successful. 6. FlowControl is the maximum bit rate, the current media data stream is the largest. It should be noted that the communication is a two-way actual above-described process transmitting and recipient, especially in the case where the capacity set of both parties is different, and the above process is required to perform the above process. To implement RSVP function in SIP: as an example in VOVIDA, a very easy way to implement RSVP is provided in the SIP protocol stack software of Vocal, of course, the RSVP is quite immature, many participants are applied in this way. The program has no feedback and processes, only the mutual reports between the routers, but this simple manner implements the RSVP architecture, so there is still a certain value of use.
The steps to implement RSVP in VOVIDA's SIP are as follows: The part of the solid line in the figure is the SIP command, the dotted portion is the RSVP implementation process in the RSVP message Vocal: Let's first look at the process defined in the RSVP API: Let's see The API call process of RSVP: (Click to enlarge) First, open a UNIX domain's RAPI Socket through RAPI_Session (), and create a session instance of RSVP, if successful, returns a non-zero value to represent the established session ID number. For example, in the SIP Stack in Vocal: session_id = rapi_session (& (DEST_ADDR), // session peer destination address; proto_id, // protocol number UDP 17; RAPI_USE_INTSERV, / / Here, IntServ definition (corresponding to DiffServ) (RAPI_EVENT_RTN_T) UpCallHandler, // In the RSVP error, the callback function 0, // RSVP event filter filter & rtn_code); / / Establish a session error return value. Creating a session using the RAPI_SESSION is sent to the RSVP PATH or send RSVP Resv. You need to call it before calling the corresponding function. Now let's see the calling process of the specific program part below: 1. The first is the call part sends an invite command, and we know that the command contains a calling description (here we refer to Remote SDP); 2. After receiving the calling INVITE message in the OPRING, the called part is received in the OPRING. After the calling INVITE message and the calling SDP, the calling address and the RSVP port (RTP port); The called call setuprsvp subroutine sends a PATH message containing data stream identification and data traffic characteristics to the caller, and the specific transmission of traffic TSPEC features are as follows: // sender TSPEC (data stream traffic description feature) definition: RAPI_TSPEC_T * tspec_ptr = & (snd_tspec); qos_tspecx_t * qos_tspec = & (tspec_ptr-> tspecbody_qosx); qos_tspec-> spec_type = QOS_TSPEC; // Flag sender traffic flow characteristics qos_tspec-> xtspec_r = 10000; // traffic qos_tspec-> xtspec_b = 200; // Mark storage bucket width QoS_TSPEC-> XTSPEC_P = 10000; // burst flow QoS_TSPEC-> XTSPEC_M = 200; // Local buffer maximum retention amount (drain bar parameters) QoS_TSPEC-> XTSPEC_M = 200; // SDU maximum tspec_ptr-> len = sizeof (rapi_hdr_t) sizeof (qos_tspecx_t); // RAPI Sender tspec_ptr-> form = RAPI_TSPECTYPE_Simplified; ... ... we first look at the function sends a PATH message in the RSVP API defined: rtn_code = RAPI_SENDER (session_id, // The session ID number created in the RAPI_Session.
0, // This flag is temporarily unused using & (src_addr), // source address, and the source port null, // sender's port number and source address, can be empty & (SND_TSPEC), // sender data stream The traffic description characteristics null, / * sender adsepc * / // APSPEC content, can be empty null, / * policy * / / / send party policy value, generally empty TTL); // message survival cycle `` `` `Here and the spirit of the RSVP - the caller sent the Path message, there are some violations. It is a call to send the PATH message. In fact, there is no difference. First of all, the calling party, did not receive the called party's SDP, so It is not possible to determine the port and IP address of the called party to receive the RSVP message. Secondly, the media stream is two-way, both sides must prestipate resources by Path - RESERVE. 3. After completing a series of SIP commands and status (Ring, OK procedure), the calling party began to send the ACK message, that is, when operating opfarendanswered (), call RSVPFAREndanswered Send RSERVE message, why do you want this time? Send a RESERVE message? Because the call is called the next process (after receiving the ACK message), all the routers between all the calling to the called called the called called have received the PATH reserved message, 4. The 5th, 6 messages are the router between the calling endpoint to the called endpoint, and receive the process of receiving the peer RESV message. The process of 1, 2, 3 is basically the same, and finally before the RTP channels of both parties open, the router between the calling / being called realizes the stable state, which is all information reserved for the call and the called resource. .
Let's take a look at how the call is how to define the resv message: // RAPI_RSTYLE_WILDCARD method is suitable for sound media transmission, while the maximum requirements are met // FlowSpec when multiple requests ///// rapi_rstyle_fixed is suitable for sound media transmission, separate reservations for each transmission source; // rapid_rstyle_se Indicates the maximum number of reserved numbers should be all reserved requests received from the interface, this party // formula mainly for video media style = RAPI_RSTYLE_FIXED; / * RAPI_RSTYLE_WILDCARD = 1 RAPI_RSTYLE_FIXED = 2 RAPI_RSTYLE_SE = 3 * / resv_flag = 0; / * RAPI_REQ_CONFIRM * / rapi_flowspec_t * flowspec_cl_ptr = & (flowspec_cl); qos_flowspecx_t * qos_flowspec_cl = & flowspec_cl_ptr-> specbody_qosx; // data stream Description (Flowspec) projects in Tspec, and service features to the same PATH qos_flowspec_cl-> spec_type = QOS_CNTR_LOAD; qos_flowspec_cl-> xspec_r = 10000; qos_flowspec_cl-> xspec_b = 200; qos_flowspec_cl-> xspec_p = 10000; qos_flowspec_cl -> xspec_m = 200; qos_flowspec_cl-> xspec_M = 200; / * 65535 * / flowspec_cl_ptr-> form = RAPI_FLOWSTYPE_Simplified; flowspec_cl_ptr-> len = sizeof (rapi_flowspec_t); Rspec // item data stream description, according to the end of the PATH The end delay and indicators and the parameters of the ADSPEC are calculated, and the estimated method is used directly in Vocal, and RSPEC is a reservation.
rapi_flowspec_t * flowspec_g_ptr = & (flowspec_g); qos_flowspecx_t * qos_flowspec_g = & flowspec_g_ptr-> specbody_qosx; qos_flowspec_g-> spec_type = QOS_GUARANTEEDX // QoS guarantee type, the most commonly used settings; qos_flowspec_g-> xspec_R = 10000; // pre-stream bandwidth qos_flowspec_g -> xspec_s = 0; // Relaxation, used to indicate QoS rich quantity QoS_flowspec_g-> xspec_r = 10000; // Business traffic QoS_flowspec_g-> xspec_b = 200; // Mark storage bucket width QoS_FLOWSPEC_G-> XSPEC_P = 10000 ; // burst traffic qos_flowspec_g-> xspec_m = 200; // maximum retention of the local buffer (the leaky bucket parameters) qos_flowspec_g-> xspec_M = 200; // the maximum flowspec_g_ptr- SDU> form = RAPI_FLOWSTYPE_Simplified; flowspec_g_ptr-> len = SIZEOF (RAPI_FLOWSPEC_T); // Screening Description, is used to indicate which or those senders perform resource reserves filter_spec.form = RAPI_FILTERFORM_BASE; / / indicates that the socket address // Sockets of the sender Filter_SPEC .len = sizeof (rapi_hdr_t) sizeof (rapi_filter_base_t); filter_spec.rapi_filt4 = * (struct sockaddr_in *) & src_addr;. rtn_code = rapi_reserve (session_id, // session ID number created in the rapi_session resv_flag, // indicating whether Rolling function (can be set to 0) & rcv_sockaddr, // receive address and port STYLE, / / Reserved Way (WF, FF, SF) NULL, / / Extended Reserved Type list, can be empty null, // receive policy 1, // filterno value, 1 means not ignoring filterSpec_list & (Filter_SPEC ), // Screening Description 1, // FlowSpecnO value, 1 means that FlowSpec_List & (FlowSpec_cl)) is not ignored; // FlowSpec Data Stream Description Structure. 5. A function called primarily in the called end: a. Void setuprsvp (SIPSDP & localsDP, SIPSDP & Remotesdp) is mainly called by the called end, used to return the called resource based on the calling SDP after receiving the call. Leave the path message. B. Void rsvpfarendanswered (sptr localsdp, sptr remotesdp) is mainly called by the calling side, which is used to send the resv message to the called end to send the resv message and start the calling resource to reserve the PATH message to the called end.
c. Void RSvPackHandler (sptr localsdp, sptr remotesdp) is mainly called by the called end, and is used to return the call resource to reserve the RESV message according to the SDP resource based on the calling SDP after receiving the call. 6. How to implement the RSVP mechanism to DiffServ's mapping: For the process of processing the RSVP current in Vocal, there is no specific operation for ADSPEC and TSPEC to delay the delay indicator of Adspec and TSPEC, And reserved bandwidth, just the router on the advertisement path to reserve resources, so if it is a simple area network of a simple network state, this method is of course unfaicable, but if it is complex Wide area online online can be said to be very good, generally, in the backbone network, the mechanism of the DiffServ (Classification service) (all streams are grouped into multiple service categories), so The RSVP news on the backbone will of course be ignored, so our Path and SESV messages must be mapped to DiffServ's mapping. In order to make a sentence, let the backbone look like a node of RSVP, generally talk about us The DTOT minimum path delay in ADSPEC (or the propagation delay of the subnet to the backbone network is defined in RFC 2205) Changes to the value of the propagation delay and a flat queue of the backbone network (this is the main network Luo entrance / outlet router) Work) This approximation is generally effective because the chance of backbone network failure is relatively small, and if the backbone network is a Gigabit router, then each PATH message can be updated on the relay section. When returning the resv message, for classified services, it is not a separate queue to define each corresponding RSVP operation. For the backbone network router, it is unrealistic, and can only be arranged relative to the service level in the most similar queue. in. There are several situations where there is a case if the backbone network needs to be careful: a. If there is a stream does not meet TSPEC - and this time the router has planned every virtual link for all the entrances and exports, one The flow that does not meet the TSPEC is enough to destroy the quality of the service of the same category, such as the low-quality video / audio flow at the entrance, there is a high quality video stream. B. Dispersed / burst flows into a gentle stream. However, in general, each router has the ability to check the stream of TSPEC, especially the router that is the mainstry network entry (eg, some large network (BGP / EBGP) into / export). When running a video conference or a lot of harsh working conditions in other bursts. 7. Modify Vocal's SIP protocol stack to achieve RSVP: We have repeatedly explained: in Vocal, only a simple RSVP architecture, the most important thing is that it cannot achieve soft status, that is, periodic Refresh the TSPEC and RSPEC, if such a situation is particularly frequent when transmitting the video signal, since the video signal is not always in a stable gentle state transmission, the RSVP message needs to be able to Accurate reciprocation along the new routing (this situation may occur, especially in large networks).
The way to solve the above problem is first to establish a guaranteed service predetermined in RSVP, that is It is two parameters: DTOT and CTOT, the first parameter is the minimum path delay, the second is the path bandwidth, through these two parameters according to the formula D = (B (bucket depth) CTOT) / P DTOT calculated Delay between end-to-end: for example: initial feature of the PATH stream: TSPEC (P = 10Mbps, L = 2kbps, r = 1Mbps, b = 32kbps) adspec (ctot = 0, dtot = 0) After the first router: TSPEC (P = 10Mbps, L = 2kbps, r = 1 Mbps, b = 32kbps) Adspec (ctot = 11, dtot = 0.05s) After the second router: TSPEC (P = 10Mbps, L = 2kbps, r = 1 Mbps, B = 32kbps) Adspec (CTOT = 55, DTOT = 0.1s) Now let's calculate the RSPEC project in Resv: the longest delay is a delay of 0.1s, and the reserved bandwidth calculated in RSPEC must meet this requirements, then according to Formula: D = (B CTOT) / P DTOT B: The bucket depth calculated D is 0.185s We calculate the reserved bandwidth R = ((PR) (L CTOT) (BL) in accordance with this formula. p) / ((T-DTOT) (PR) BL) R: Business Flow T: The required delay Note: The required delay varies between 0.1-0.185 so that we have drawn a relatively exactly the above formula. R value r = 1.66Mbps. So rspec is: r = 1.66Mbps; relaxation item (s): Used to indicate the rich amount of QoS, if all routers are reserved in R, then the end-to-end delay on the entire path is less than the required time 5 Mixt: 0.05s here, that is, there is a relatively cleared bandwidth, you can implement other data transfer, or let the current media data do its best to transfer, the specific relaxation calculation can see the RFC 2205 definition. Above we solve the problem of service-booking, but it only allows our terminal program to run further rationalization, and the correct plan can require reserved bandwidth, but there is still a key issue in the middle, which is the soft state we say above - - Regular refresh TSPEC and RSPEC, as well as the change in detecting / perceived trunk routing from the program to implement these facts, we can use a process to send Path and Resv messages in a process of opening media communication, letting flow The recipient is regularly refreshed, especially when the interframed frame is blocked in the video communication phase (using the H.263 algorithm), the traffic will inevitably increase, this time, if you refresh the reserved state in advance, then we can In the early days, it avoids the problem of blocking problems. Of course, if traffic exceeds the criteria that the path is affected, then it will inevitably rely on the S (relaxity) to send packets, if more than bandwidth license, this time, inevitable communication will appear More obvious delays, but according to experimental results, these are still acceptable.
