The Signaling Protocol for IntServ Operation over DiffServ Model

全文

(1)Workshop on Computer Networks The Signaling Protocol for IntServ Operation over DiffServ Model. Chin-Ling Chen. Department of Information Management, National Pingtung Institute of Commerce, Pingtung, Taiwan. Corresponding Address: Dr. Chin-Ling Chen Department of Information Management, NPIC, No. 51, Min-Sheng E. Road, Pingtung, Taiwan 900 Email:clchen@npic.edu.tw Fax: 886-8-7232917 1.

(2) ABSTRACT RSVP (ReSerVation Protocol) is the signaling protocol defined by IETF (Internet Engineering Task Force) to guarantee QoS (Quality of Services) per flow in IntServ network. This paper presents a simple and yet effective new RSVP/COPS signaling model to support the delivery of end-to-end QoS across IntServ network and DiffServ domain. In this model the end-to-end RSVP messages are carried in the content of COPS across DiffServ domain, which eliminates the requirement of both COPS-PR and COPS-ODRA protocols. An admission control algorithm has also been developed in this model for Bandwidth Broker to check QoS parameters when communicating with routers and to dynamically provide resources provisioning for DiffServ domain. The new model along with statistical methods are applied to analyze the typical DiffServ operations and to compute the probability of directional Internet flow moving from one router to another. Simulation result shows that the proposed model can provide lower setup time than others.. Keywords: RSVP, COPS, DiffServ, admission control algorithm and Bandwidth Broker.. 2.

(3) 1. Introduction New applications like VoIP and multimedia that require strict delay bound drive the urgent need for Internet QoS. IETF working groups have defined two models to support QoS over Internet: Integrated Services (IntServ) [1-2] and Differentiated Services (DiffServ) [3-6]. In IntServ network, QoS guarantee is based on per-flow, and RSVP (ReSerVation Protocol) [7-11] is the signaling protocol. There are two fundamental RSVP message types: PATH and RESV. The source sends PATH message downstream to the receiver. PATH message contains Sender_TSpec and AD_Spec. Sender_TSpec object carries the traffic specification generated by the source within an RSVP session. It is transported through the network and delivered to the intermediate nodes and the receiving applications. AD_Spec object carries information, which is generated at either sources or intermediate network elements, flows downstream towards the receiver. AD_ Spec can be used and updated inside the network before being delivered to the receiver. This information includes parameters describing the properties of the data path, such as the availability of specific QoS control services, and parameters required by specific QoS control services to operate correctly. The receiver sends RESV messages upstream back to the source. RESV messages must follow exactly the reverse of the paths that PATH message had traversed. RESV message includes Flow_Spec and Filter_Spec. Flow_Spec contains TSpec (Traffic Spec) and RSpec (Reserve Spec), whose usages depend on the type of services (Guaranteed Services [12] and Controlled-Load Services [13]) they are in. Filter_Spec defines a subset of session data packets that should receive in the desired QoS. IntServ provides QoS control for traffic based on per-flow and the router loading increases as the number of users grows. DiffServ, therefore, is proposed to deal with the low scalability problem. DiffServ provides QoS control for traffic based on 3.

(4) per-class, rather than per-flow. Several similar QoS flows can be aggregated into a larger one, and the Edge Routers mark one aggregate with a DiffServ codepoint (DSCP). Core routers simply look up the DSCP mark to decide the services of the packet (Per Hop Behavior, PHB). In DiffServ Domain, COPS (Common Open Policy Service) [14] protocol is used for exchange of messages between routers and Bandwidth Broker to make sure the current available bandwidth can support the new request. The COPS supports two common models for policy control: Outsourcing and Configuration. In Outsourcing model, Edge Router delegates responsibility to Bandwidth Broker to make decisions on its behalf. When a RSVP reservation message arrives, Edge Router must outsource this decision by sending COPS protocol to query Bandwidth Broker to decide whether to admit or reject the request. In Configuration model, provisioning makes sure the entire router QoS configuration happen at both IntServ network and DiffServ domain. In [15], a framework for IntServ operation over DiffServ domain was proposed for resource management. Two options exist for resources management in DiffServ domain to meet the needs of end-to-end IntServ flows. The first [16] applies aggregate RSVP as signaling protocol to dynamically provision resource as well as classify the aggregate traffic for different flows in DiffServ domain. A benefit of supporting aggregate RSVP signaling within the DiffServ domain is that it may affect changes at once in the provisioning of DiffServ domain in response to resource requests from IntServ network. However, synchronization of bursts from different flows may occur. It implies that one flow may suffer delay from the burst of another. The second takes Bandwidth Broker as a centralized resource controller for all routers in DiffServ domain by using on COPS-PR [17] and COPS-ODRA [18], based on COPS [19], to dynamically provision resources. However, both [17] and [18] themselves do not describe the detailed signaling protocol distributed between IntServ network and 4.

(5) DiffServ domain. In [20], the signaling protocol with integrating RSVP, COPS-PR and COPS-ODRA across IntServ network and DiffServ domain had been proposed. Edge routers with RSVP daemon use COPS-ODRA to communicate with a Bandwidth Broker and then a Bandwidth Broker uses COPS-PR to inform corresponding routers to do resources provision. However, COPS-PR has defined too many client types, which are considered useless in resources provisioning. Furthermore, the process that COPS-ODRA messages are used to exchange COPS messages is too complex and is difficult to implement. In view of these drawbacks, this paper presents a new model to simplify RSVP implementation process. This model utilizes a new RSVP/COPS signaling protocol to support the delivery of end-to-end QoS across IntServ network and DiffServ domain. The RSVP/COPS, with RSVP messages carried in COPS content, can effectively replace both COPS-PR and COPS-ODRA protocols to enhance the delivery speed. To further improve the communication flexibility, COPS signaling protocol is used for Bandwidth Broker to dynamically provide resources provisioning in DiffServ domain. The rest of the paper is organized as follows. Section 2 describes the new model where COPS content format, model architecture, signaling protocol and admission control algorithm are discussed. The simulation result and its analysis are discussed in section 3. Section 4 concludes the paper and summarizes the key benefits of this model. 2. The Proposed Model 2.1 COPS Content format In COPS, formats for context object to process RSVP can be classified two types: Request Type (R-Type) field and Message Type (M-Type) field [16]. R-Type can be further divided into three types of requests: Incoming-Message, Resource-Allocation 5.

(6) and Outgoing-Message. Incoming-Message and Outgoing-Message are used when a router receives an incoming RSVP message and forwards an outgoing RSVP message, respectively. Resource-Allocation is used when Bandwidth Broker is about to commit local resources to an RSVP flow (admission control). In the proposed model, only Resource-Allocation message is required in COPS. The value of M-Type field is mapped to the “msg type” field in RSVP header. The COPS supports four RSVP message types: PATH, RESV, PATHErr and RESVErr [16]. All objects that were received in an RSVP message are encapsulated inside Signaled Client Specific Information Object (ClientSI). For clarity, PATH and RESV messages are encapsulated in P_REQ and R_REQ shown in Fig. 1 (a) and Fig. 2 (a), respectively. P_DEC (Fig. 1 (b)) and R_DEC (Fig. 2 (b)) are their corresponding responses for final decision. Two decision commands (Install/Remove) are applied in COPS.. Common Header. Common Header. Client Handler:. Client Handler:. Context: in & out, PATH. Context: in & out, PATH. In-Interface:. DEC: Common = Install/Remove. Out-Interface:. Integrity. ClientSI: PATH message. (b). Common Header Session RSVP_HOP Policy_Data Sender Description Integrity. (a) Fig. 1 (a) PATH Encapsulated in Signaled ClientSI P_REQ, and (b) P_DEC. 6.

(7) Common Header. Common Header. Client Handler:. Client Handler:. Context: in & out, RESV. Context: in & out, RESV. In-Interface:. DEC: Common = Install/Remove. Out-Interface:. Integrity. ClientSI: RESV message. (b). Common Header Session RSVP_HOP Policy_Data Flow Description Integrity. (a) Fig. 2 (a) RESV encapsulated in Signaled ClientSI R_REQ, and (b) R_DEC 2.2 Model Architecture A new signaling protocol, called RSVP/COPS, is devised to integrate RSVP and COPS. Both RSVP and COPS rely on TCP to transmit. The system configuration is divided into three parts: Two IntServ networks and one DiffServ domain (Fig. 3). The assumptions are as follows. 1.. In IntServ network, all hosts and routers support RSVP.. 2.. In DiffServ domain, Edge Routers (Ingress/Egress) support both RSVP and COPS while Core Routers and Bandwidth Broker only support COPS. The layering relationship between Edge Routers and Core Router is shown at Fig. 4.. 7.

(8) R S RSVP. RSVP. Bandwidth Broker. IntServ network. Ingress Edge Router COPS. Egress Edge Router Core Router. IntServ network. Core Router. DiffServ domain. Fig. 3 System configuration. RSVP and COPS are used to do signaling and reserve resource in IntServ network and DiffServ domain, respectively. A QoS (r, p, B parameters) guarantee path from source to destination must be set up by RSVP/COPS signaling protocol across IntServ network and DiffServ domain.. Edge Router. IntServ network. Core Router. Edge Router. RSVP/COPS. COPS. RSVP/COPS. IP. IP. IP. DiffServ domain. IntServ network. Fig. 4 Layering relationship between Edge Routers and Core Routers. During reservation setup, two decision modules, policy control and admission control, must be made. Policy control determines whether the user has the permission 8.

(9) to make the reservation. Service menu provides five sets of TSpec parameter value, which is charged for different price. Each set of TSpec parameter value represents a distinct service level agreement (SLA). Users pay the service based on their specific requirement, picking an SLA from the service menu. Price level is: E>4>3>2>1. Admission control determines whether the routers along the path have sufficient available resources to support the requested QoS. A signaling protocol is triggered by source to find out one end-to-end QoS guarantee path across IntServ network and DiffServ domain. If both checks (policy control and admission control) succeed, parameters are set in the packet classifier in the packet scheduler to obtain the desired QoS and data transmission is then started. 2.3 Signaling Protocol In the proposed model, a signaling protocol, called RSVP/COPS, is designed to operate correctly through IntServ network and DiffServ domain. RSVP is used to deliver QoS requests to all nodes along the path in IntServ network. Since DiffServ domain does not support RSVP, COPS is devised to replace the function of RSVP to perform resource reservation in DiffServ domain. One QoS guarantee path is established with the implementation of RSVP/COPS across IntServ network and DiffServ domain. At initiation, Bandwidth Broker read the content of P_REQ message, which is sent by all nodes in DiffServ domain, to collect router capacity information (r, p, B) and store in its own dynamic state table. The signaling protocol consists of six steps, which are described as follows. Step 1. In IntServ network, source node transmits PATH messages downstream along routes provided by the routing protocol. The content of PATH message is stored at path state table in each node along the path. The content of path state table includes sender description and RSVP_HOP, which are used to provide TSpec information and RESV messages hop-by-hop route in the reverse 9.

(10) direction, respectively. Step 2. PATH message arrives at Ingress Edge Router in DiffServ domain (Fig. 5). RSVP process triggers COPS-client to encapsulate PATH into Signaled ClientSI P_REQ and then to send P_REQ to Bandwidth Broker. Bandwidth Broker stores TSpec parameter value, which is now in the content of PATH message, into dynamic status table for each P_REQ message. Bandwidth Broker then passes P_DEC (Install) to Ingress Edge Router to indicate the job is completed. Ingress Edge Router continues to forward P_REQ message to Core Routers. Core Routers do the same task as Ingress Edge Router, to communicate Bandwidth Broker. Both Ingress Edge Router and Core Routers forward P_REQ messages toward the destination address using their local routing process. Therefore, they are routed correctly through DiffServ domain. Step 3. P_REQ message arrives at Egress Edge Router. Egress Edge Router sends P_REQ message to Bandwidth Broker and then waits for P_DEC response. Egress Edge Router triggers RSVP process to decapsulate P_REQ message into its original PATH message. RSVP process consults its local routing table to obtain routes so that it can continue to forward PATH message to destination. Step 4. One QoS guarantee path from destination to Egress Edge Router with QoS guarantee is reserved by RESV message. RESV message is sent back hop-by-hop, following the same path created by PATH message. Each node in the IntServ network forwards RESV message to the address of previous RSVP hop, which is recorded in path state in each node.. 10.

(11) Bandwidth Broker P_REQ P_REQ. P_DEC. P_DEC. P_REQ. COPS-Client. COPS-Client P_REQ. PATH. P_DEC. COPS-Client P_REQ. RSVP. Routing. RSVP. Process. Process. Process. Routing. Routing. Process. Process. Ingress Edge Router IntServ network. Core Router DiffServ domain. PATH. Egress Edge Router IntServ network. Fig. 5 Operation of PATH Message between Edge Router and Core Router. Step 5. One path with QoS guarantee from Egress Edge Router to Ingress Edge Router is set up. Whenever Egress Edge Router receives RESV message (Fig. 6), RSVP process triggers COPS-client to encapsulate RESV message into R_REQ message and then pass R_REQ message to Bandwidth Broker. Bandwidth Broker read the content of R_REQ message to obtain the desired QoS defined by the Flow_Spec and gets QoS parameters (r, p, B) of the routers along the path by checking its own dynamic status table. Bandwidth Broker runs admission control algorithm to determine whether the path is satisfied QoS requirement or not. If check successes, Bandwidth Broker responds to all Edge Routers (Ingress/Egress) and Core Routers by sending R_DEC (Install) message back to make sure the bandwidth reservation along 11.

(12) the path is completed. Bandwidth Broker then forwards R_REQ message to Ingress Edge Router. Step 6. At the time Ingress Edge Router receives R_REQ message from Bandwidth Broker, Ingress Edge Router triggers COPS-client to decapsulate R_REQ message into its original RESV message. Egress Edge Router continues to forward RESV message to the source, following the previous path found by PATH message.. Bandwidth Broker. R_REQ. R_REQ. R_DEC R_DEC R_DEC COPS-Client. COPS-Client. COPSRSVP Process. RSVP Process. Client. RESV. RESV. Routing. Routing. Process. process. Ingress Edge Router. Core Router. IntServ network. DiffServ domain. Egress Edge Router. IntServ network. Fig. 6 Operation of RESV message between Edge Router and Core Router. 2.4 Admission Control Algorithm The flow is defined as the traffic associated with a user request and user data.. 12.

(13) The flows, which have the same next-hop destination, are considered to be as one aggregate. Assume V is router set in the DiffServ domain. The subgraph Vj ⊂ V represents these routers are recorded by flow j in dynamic status table at Bandwidth Broker. The set (rR(i), pR(i), BR(i)) indicates QoS parameters in router i, which is used to policy network condition. The set (rf(j), pf(j), Bf(j)) indicates QoS parameters in P_REQ message within flow j. When Bandwidth Broker receives R_REQ message, it must determine whether the path from Ingress Edge Router to Egress Edge Router is satisfied, by running Admission Control Algorithm. Assume ki indicate the total number of flows currently in the ith router. The QoS parameters set (rR(i), pR(i), BR(i)) in each router i along this path must satisfy the following constraints. rR(i) ≥. ki. ∑r j =1. f. ( j) ,. ki. pR(i) ≥ ∑ p f ( j ) , j =1 ki. BR(i) ≥ ∑ B f ( j ) . j =1. The parameter of Token Bucket (Fig. 7) is described as follows. r : Token Bucket Rate, B :Token Bucket Size, p : Peak Data Rate, m : Minimum Policed Unit, M : Maximum Packet Size. The condition that no packets lost in the Token Bucket is M+p×t≤B+r×t. That is, p≤(B−M)/t. Bandwidth Broker calculates QoS parameter value for all the nodes along the path with looking up dynamic status table whenever receiving the R_REQ message initiated from Egress Edge Router. Admission control algorithm of Bandwidth Broker is described as follows.. 13.

(14) B. .. r. .. M p Fig. 7 Token bucket. Algorithm: {Admission control of Bandwidth Broker} Input: Vj: subset of all routers, which are routed by flow j rR(i): token arrival rate for router i BR(i): token bucket capacity for router i pR(i), pR(i) ≤ (BR(i)− M)/t {Maximum output rate for router i} rf(j): token arrival rate for flow j Bf(j): token bucket capacity for flow j pf(j), pf(i) ≤ (Bf(i)− M)/t {Maximum output rate for flow j} ki: the total number of flows currently in router i Output: the value of R_DEC {The value of DEC for R_REQ} {The principle of admission control is that Bandwidth Broker calculates QoS 14.

(15) parameter set by looking up dynamic status table for all nodes along the path to decide to accept or reject R_REQ message} Step 1. for i =1 to V j. /* all routers the flow j must traverse */. { Step 2.. for j =1 to ki /* check QoS parameters set for all flows in router i */ { rf =+rf(j); pf=+ pf(j); Bf =+Bf(j); } if ((rR(i) ≥ rf) and (pR(i) ≥ pf) and (BR(i) ≥ Bf)). Step 3.. { status(i) = ‘0’;}. /* router i meet the requirement */. else { status(i) = ‘1’;. /* router i can not meet the requirement */. goto Step 5; } Step 4.. status(i) = status(i) || status(i−1); i++; }. Step 5.. if (status(i) ==0) {R_DEC = Install;}. /* request is accepted */. else {R_DEC = Remove;}. /* request is rejected */. 3. Simulation Results and The Analysis In this section, we present the simulation model to compare the performance of the proposed scheme with that of two previous researches— aggregate RSVP [16] and the integrated signaling protocol [20]. Fig. 8 shows the network topologies used in the simulation. The setup time is defines as the time for the model to complete the end-to-end setup process time. In Fig. 9, when the number of aggregated flow increases, the average setup time of three schemes increases at the steady state. We found that the proposed scheme outperforms the other two ones because it reduces the complexity of signaling messages needed. Fig. 10 and Fig. 11 compare the different 15.

(16) setup time of three schemes based on the number of router in the IntServ network and DiffServ domain, respectively. Fig. 10 shows that the number of routers in IntServ has not significantly effect the setup time for all three schemes. Three curves become smooth with slow increasing trend. The reason is that all three schemes use RSVP as signaling protocol in IntServ network and each source handles its own communication message exchange. In Fig. 11, the curve for aggregate RSVP increases radically as the number of routers in DiffServ is over 40. The other two curves increase slowly since bandwidth broker takes the task of centralized controlling for the signaling messages within DiffServ domain. The performance of the proposed scheme is still better than that of integrated signaling protocol with its simple signaling messages exchange. S R. IntServ. DiffServ. IntServ. Fig. 8 Network topology used in simulation. 16.

(17) 100 1. the proposed model. 60. 2. aggregate RSVP 3. the integrated. 40 20 0 0. 10. 20. 30. 40. 50. Number of flow to be aggregated (x105). Fig. 9 Setup time as a function of number of flows to be aggregated. Setup time. Setup time. 80. 35 30 25 20 15 10 5 0. 1. the proposed model 2.aggregate RSVP 3. the integrated. 0. 10. 20. 30. 40. 50. Number of router in Intserv. Fig. 10 Setup time as a function of number of routers in IntServ. 17.

(18) 100 Setup time. 80. 1. the proposed model. 60. 2. aggregate RSVP 3. the integrated. 40 20 0 0. 10. 20. 30. 40. 50. Number of router in Diffserv. Fig. 11 Setup time as a function of number of routers in DiffServ. 4. Conclusions The paper presents a new RSVP/COPS signaling protocol to support the distribution of end-to-end QoS between IntServ network and DiffServ domain. This new model provides benefits of:  Simplicity in RSVP Implementation: only end-to-end RSVP messages are carried in the content of COPS across DiffServ domain. There is no need for COPS-PR and COPS-ODRA protocols. Only one, rather than three, request messageis required in COPS.  Effective Bandwidth Broker: the admission control algorithm allows Bandwidth Broker to look at path state table of all nodes before making decision on RSVP messages.  Quantitative Description of Internet Flow: the directional Internet flow moving probability between routers can be computed for DiffServ operation. To verify the conclusion, we have conducted simulation to evaluate the performance of the proposed model. With simple signaling message exchange and the centralized control bandwidth broker, the proposed model demonstrates low setup 18.

(19) time for system to compare end-to-end QoS request, as compared the previous researches that employs complicated signaling protocol and distributed message handling mechanism.. References [1] R. Braden, D. Clark, and S. Shenker, ”Integrated Services in the Internet Architecture”, IETF RFC 1633, June 1994. [2] C. Weider, P. Deutsch, “A Vision of an Integrated Internet Information Service,” IETF RFC 1727, December 1994. [3] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, “An Architecture for Differentiated Services,” IETF RFC 2475, December 1998. [4] K. Nichols, S. Blake, F. Baker, and D. Black, “Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers,” IETF RFC 2474, December 1998. [5] Y. Bernet, J. Binder, S. Blake, M. Carlson, E. Davies, B. Ohlman, D. Verma, Z. Wang, and W. Weiss, "A Framework for Differentiated Services," Internet Draft, draft-ierf-diffserv-framework-01.txt, October. 1998. [6] M. Biegi, S. Rao, and D. Verma, “Supporting Service Level Agreements using Differentiated Services,” Internet Draft, draft-verma-diffserv-ntimplem-00.txt, November 1998. [7] R. Braden, Ed., “Resource ReSerVation Protocol (RSVP) – Version 1 Functional Specification,” Internet RFC 2205, September 1997. [8] L. Zhang, S. E. Deering, S. Shenker, and D. Zappala, “RSVP: A New Resource ReSerVation Protocol,” IEEE Network, pp. 8-18, September 1993. [9] L. Berger and T. O’Malley, “RSVP Extensions for IPSEC DATA Flows,” Internet RFC 2207, September 1997. 19.

(20) [10] R. Braden and L. Zhang, “Resource ReSerVation Protocol (RSVP) – Version 1 Message Processing Rules,” Internet RFC 2209, September 1997. [11] J. Wroclawski, “The Use of RSVP with Integrated Services,” Internet RFC 2210, September 1997. [12] S. Shenker, C. Partridge, and R. Guerin, “Specification of Guaranteed Quality of Service,” Internet RFC 2212, September 1997. [13] J. Wroclawski, “Specification of The Controlled-Load Network Element Service,” Internet RFC 2211, September 1997. [14] D. Durham, J. Boyle, R. Cohen, S. Herzog, R. Rajan and A. Sastry, “The COPS (Common Open Policy Service) Protocol,“ Internet RFC 2748, January 2000. [15] Y. Bernet, Y. Bernet, P. Ford, R. Yavatkar, F. Baker, L. Zhang, M. Speer, R. Braden, B. Davie, J. Wroclawski and E. Felstaine, “A Framework for Integrated Services Operation over DiffServ Networks,” Internet RFC 2998, November 2000. [16] F. Baker, C. Iturralde, F. Le Faucheur and B. Davie, “Aggregation of RSVP for IPv4 and IPv6 Reservations,” Internet RFC 3175, September 2001. [17] K. Chan, J. Seligson, D. Durham, S. Gai, K. McCloghrie, S. Herzog, F. Reichmeyer and A. Smith, ”COPS Usage for Policy Provisioning (COPS-PR),” Internet RFC 3084, March 2001. [18] S. Salsano, “COPS Usage for Outsourcing DiffServ Resource Allocation”, Internet Draft, draft-salsano-issll-cops-odra-00.txt, February 2000. [19] S. Herzog, J. Boyle, R. Cohen, D. Durham, R. Rajan and A. Sastry, “COPS Usage for RSVP,” Internet RFC 2749, January 2000. [20] Hung-Chi Su and Ren-Hung Hwang, "Multicast Provision in a Differentiated Services Network," ICOIN-15, Japan, Jan. 2001. 20.

(21)