Internet Draft Radhakrishna C, Expires December, 2000 Motorola India Electronics Ltd., draft-rk-diffserv-rsvp-sig-00.txt June, 2000 Use of RSVP for Differentiated Services Signaling and Admission Control Status of this Memo This document is an Internet Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts. Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Distribution of this memo is unlimited. Abstract This document describes the use of RSVP for admission control and signaling in differentiated services networks. A small subset of RSVP message objects are used to provide end-to-end dynamic QoS control in differentiated services networks. rk Expiration: December 2000 [Page 1] draft-rk-diffserv-rsvp-sig-00.txt June 2000 1. Introduction This section describes the mechanics of using RSVP for end-to-end QoS control in Differentiated Services network. RSVP is used to establish an end-to-end DiffServ session as shown in figure 1. In figure 1, the end-to-end DiffServ session Sai (DS_SESSION object) is identified by session identifier i assigned by the originating Edge/Boundary node and its IP address a. Sai = {a, i} <--------------------------------> ________ _______________ ________ / \ / \ / \ / \ / \ / \ |---| | |---| |---| |---| |---| |---| | |---| |Tx |-| |ER1|---|BR1|---|CRx|---|BR2|---|ER2| |-|Rx | |---| | |-- | |---| |---| |---| |---| | |---| \ / \ / \ / \________/ \_______________/ \________/ Diffserv/Non-Diffserv Diffserv region 2 Diffserv/Non-Diffserv region 1 region 3 Figure 1: Sample Network Configuration The sender side edge/boundary node initiates a DiffServ session for each flow to which the reservation has to be set up, by creating a DiffServ session and assigning an identifier unique to the node. The DiffServ session Sai all along the path is identified by the node's address along with the identifier and is carried in all RSVP messages. Each node along the path creates a DiffServ session on receipt of first Path message for the DiffServ session Sai. Receiver node on receipt of Path message, creates a DiffServ session for Sai and generates a Resv message (back to the sender node) with required DiffServ flowspec (DS_FLOWSPEC). DiffServ flowspec includes PHB or PHB group for the session (PHB_ID) and PHB parameters (PHB_PARAM). Reservation confirmation is also requested by including RESV_CONFIRM object in RESV message. Unlike standard RSVP processing, the intermediate nodes are not required to process messages originated from the receiver node and hence they are not carried hop-by-hop to the sender node along the reverse path. This simplifies the processing in intermediate nodes and these nodes maintain a simple state of whether a reservation is set up or not. rk Expiration: December 2000 [Page 2] draft-rk-diffserv-rsvp-sig-00.txt June 2000 The sender node on receipt of Resv message, does local admission control (availability of resources) and sends ResvConf message if the admission control succeeds (otherwise sends ResvErr message which results in tearing down of session in all nodes). Each intermediate node along the path checks the availability of resources on receipt of ResvConf message and passes the ResvConf message to next node if the resources are available. Otherwise, ResvErr message is sent which results in tearing down of the session in all nodes. The arrival of ResvConf message at the receiver node indicates the successful reservation for the session. The packets belonging to the established session are conditioned and marked (as per the PHB parameters passed in the Resv message) at the sender node and all other nodes do simple DiffServ processing (applying PHBs as per the markings). The session can be teared down by PathTear message from the sender node or session timeout. Use of RSVP as described above, will keep all the simplicity and scalability of Diffserv without adding any overheads in the data path. RSVP is used only for establishing Diffserv sessions and admission control. Its processing is much simpler compared to standard RSVP processing, since the session and states are much simpler. rk Expiration: December 2000 [Page 3] draft-rk-diffserv-rsvp-sig-00.txt June 2000 2. Detailed Operation 2.1 DiffServ session establishment, refresh and termination R1 R2 R3 | | | 1. Session | Path(Sr1i) | Path(Sr1i) | initiation |-------------------------->|-------------------------->| | | | | Resv(Sr1i, DSpec) | 2. Session |<------------------------------------------------------| establish- | ResvConf(Sr1i, DSpec) | ResvConf(Sr1i, DSpec) | ment |-------------------------->|-------------------------->| | | | | Path(Sr1i) | Path(Sr1i) | 3. Session |-------------------------->|-------------------------->| Refresh | Resv(Sr1i, DSpec) | |<------------------------------------------------------| | ResvConf(Sr1i, DSpec) | ResvConf(Sr1i, DSpec) | |-------------------------->|-------------------------->| | | | 4. Session | PathTear(Sr1i) | PathTear(Sr1i) | terminat- |-------------------------->|-------------------------->| ion | Termination on | | timeout | | ResvTear(Sr1i) | PathTear(Sr1i) | |<--------------------------|-------------------------->| | PathTear(Sr1i) | | |-------------------------->| | | | | 5. Session | Path(Sr1i) | Path(Sr1i) | Failure |-------------------------->|-------------------------->| for non- | Resv(Sr1i, DSpec) | availabi- |<------------------------------------------------------| lity of | ResvConf(Sr1i, DSpec) | ResvErr(Sr1i) | resources |-------------------------->|-------------------------->| | ResvTear(Sr1i) | |<------------------------------------------------------| | PathTear(Sr1i) | PathTear(Sr1i) | |-------------------------->|-------------------------->| Sr1i - DiffServ session (DS_SESSION) DSpec - DiffServ flowspec (DS_FLOWSPEC) Figure 2: DiffServ session establishment, refresh and termination Figure 2 illustrates the establishment of DiffServ session. Each DiffServ node allows a pre-configured number of sessions. An identifier i (1 to maximum allowed sessions) is assigned by the sending edge/boundary node and is identified by the assigned identifier i and address a of the sending node in all the nodes. All the RSVP messages carry this DiffServ session object (Sr1i). rk Expiration: December 2000 [Page 4] draft-rk-diffserv-rsvp-sig-00.txt June 2000 In figure 2, - Router R1 initiates the DiffServ session by sending Path message with DiffServ Session object Sr1i downstream to R3. - Router R2 creates session Sr1i and passes the Path message to R3. - Router R3 creates session Sr1i and sends Resv message upstream to R1. - R1 sends ResvConf message downstream to R3 after updating the available resources. - R2 passes ResvConf message to R3 after updating the available resources. - To terminate the session R1 sends PathTear message downstream to R3 after terminating its Sr1i session. - R2 terminates Sr1i session and passes PathTear message to R3. - R3 terminates Sr1i session. - Session Sr1i may also get terminated on timeout where in R2 sends PathTear message to R3 and ResvTear message to R1. - In case of non-availability of resources, R2 sends ResvErr message to R3, which in turn sends ResvTear message to R1. R1 sends PathTear message downstream to R3 and session is terminated. - Note that a session is terminated in a Router when it either generates a PathTear message (on timeout) or it receives PathTear message. rk Expiration: December 2000 [Page 5] draft-rk-diffserv-rsvp-sig-00.txt June 2000 2.2. Admission control and Data processing _________________________ | ____________________ | | | | | | | Application | | | |_________________^__| | | " " | | | " " ____V___ |Host | ___V____ " | | | | | | " | RSVP | | | | Marker <---| Process| | | |________| " |____^___| | | " " | | |_____"______"______|_____| " | "data |RSVP _____"_____________|____________ ______________________ | " " ____V___ | | ________ | | ___V___ " | | |RSVP | | | | | | | " | RSVP <-------------------> RSVP |----------> | | MF/BA <----| Process| | | | Process| | | |Class- | " |________| | | |________| | | | ifier | " | | | | | |_______| " | | | | | " "===|===============| |======================| | " | | | | | _V__________V_ | | | | | | ________ | | ______ ________ | | | (Marker &) | | | |data | | | | | | | | Traffic |==> Packet |=========> BA |==> Packet |===> | | Conditioner | |Schedulr| | | |Class-| |Schedulr| | | |______________| |________| | | | ifier| |________| | | | | |______| | |________________________________| |______________________| Edge/Boundary node Intermediate Node Figure 3: Admission control and data processing As shown in figure 3, policing and admission control is done only in edge/boundary nodes. Packets belonging to established sessions are classified based on DiffServ CodePoints and sender IP addresses. In the absence of host marking, MF classifiers associated with the sessions are used to mark the packets using DiffServ codepoints received in Resv message. The classified packets are policed for the TSpecs of the associated sessions and then serviced for their respective PHBs (indicated by DiffServ CodePoints) using appropriate scheduling mechanisms. Rest of the packets are treated as best effort (some of them may be dropped based on policy conditions). rk Expiration: December 2000 [Page 6] draft-rk-diffserv-rsvp-sig-00.txt June 2000 The classified packets are policed and conditioned using traffic conditioners. A traffic conditioner is associated with each BA (marked with same codepoint or set of codepoints) from each source (or group of sources) and the conditioning parameters are set using TSpecs received in Resv messages of the associated sessions (sessions that belong a BA from same source or group of sources). Only one traffic conditioner is enough for all the sessions belonging to a BA from a source (or group of sources) and conditioning parameters set will be the sum of the TSpecs of all the associated sessions. The intermediate node is involved only in RSVP signaling for admission control purposes and it services the packets as per the PHBs indicated by DiffServ CodePoints. 3. RSVP message objects The objects used for DiffServ session are - - DS_SESSION - DS_FLOWSPEC 3.1 DS_SESSION object The DS_SESSION object identifies end-to-end session in a DiffServ domain. It is carried in all RSVP messages and has the following format: o IPv4 DS_SESSION: Class = 1, C-Type = 3 0 | 1 | 2 | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Sender Address (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Identifier assigned by the sender (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ o IPv6 DS_SESSION: Class = 1, C-Type = 4 0 | 1 | 2 | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | | + IPv6 Sender Address (16 bytes) + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Session Identifier assigned by the sender (4 bytes) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ rk Expiration: December 2000 [Page 7] draft-rk-diffserv-rsvp-sig-00.txt June 2000 3.2 DS_FLOWSPEC object The DS_FLOWSPEC object provides the QoS specifications for a DiffServ session. It is carried in Resv and ResvConf messages and has the following format: DS_FLOWSPEC: Class = 9, C-Type = 3 0 | 1 | 2 | 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (a) | reserved | PHB Identifier [PHB_ID] | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PHB parameters Fragment [PHB_PARAM] 1 + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . . . PHB_PARAM 2 to x-1 . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + PHB_PARAM x + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) PHBID - Identifies a PHB or set of PHBs for the DiffServ session PHB_PARAM - PHB parameters for each PHB that applies to DiffServ session. o PHB_ID format: The PHB_ID format is defined in draft-ietf-diffserv-phbid-00.txt and is repeated below. PHB_ID is a 16 bit field is as given below. Case 1: PHBs defined by standards action, as per [RFC 2474]. The encoding for a single PHB is the recommended DSCP value for that PHB, left-justified in the 16 bit field, with bits 6 through 15 set to zero. Note that the recommended DSCP value MUST be used, even if the network in question has chosen a different mapping. The encoding for a set of PHBs is the numerically smallest of the set of encodings for the various PHBs in the set, with bit 14 set to 1. (Thus for the AF1x PHBs, the encoding is that of the AF11 PHB, with bit 14 set to 1.) +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | DSCP | 0 0 0 0 0 0 0 0 X 0 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ rk Expiration: December 2000 [Page 8] draft-rk-diffserv-rsvp-sig-00.txt June 2000 Case 2: PHBs not defined by standards action, i.e. experimental or local use PHBs as allowed by [RFC 2474]. In this case an arbitrary 12 bit PHB identification code, assigned by the IANA, is placed left- justified in the 16 bit field. Bit 15 is set to 1, and bit 14 is zero for a single PHB or 1 for a set of PHBs. Bits 12 and 13 are zero. 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ | PHB id code | 0 0 X 1 | +---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ Bits 12 and 13 are reserved either for expansion of the PHB identification code, or for other use, at some point in the future. o PHB_PARAM format: 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1 | 0 (a) | reserved | 7 (b) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2 | reserved | 0 | DSCPc | TC | 0 | DSCPnc | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3 | 127 (c) | 0 (d) | 5 (e) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4 | Token Bucket Rate [r] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5 | Token Bucket Size [b] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6 | Peak Data Rate [p] (32-bit IEEE floating point number) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7 | Minimum Policed Unit [m] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8 | Maximum Packet Size [M] (32-bit integer) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) (b) - Overall length (7 words not including header) (c) - Parameter ID, parameter 127 (Token Bucket TSpec) (d) - Parameter 127 flags (none set) (e) - Parameter 127 length, 5 words not including per-service header DSCPc - DiffServ CodePoint for traffic that meets TSpec. TC - Traffic conditioning for traffic that exceeds TSpec. 0 - Drop, 1 - Shape, 2 - Pass through next Token Bucket, 3 - Mark with DiffServ CodePoint DSCPnc DSCPnc - DiffServ CodePoint for traffic that exceeds b. rk Expiration: December 2000 [Page 9] draft-rk-diffserv-rsvp-sig-00.txt June 2000 4. Aggregation and Resource re-nogatiation The sender host/node can aggregate the reservations of multiple flows for the same destination. A single DiffServ session is enough for these flows and resources can be re-negotiated as and when the flows become active. 5. Dynamic provisioning in DiffServ networks By using RSVP as explained in this document, the DiffServ networks can be dynamically provisioned for various services without much overheads and complexity. 6. Integrated Services with DiffServ networks The hosts/nodes which use Integrated Services with standard RSVP mechanisms can be supported by using the model described in this document without much overheads and complexity. The edge/boundary nodes can do a simple mapping of Integrated Services to DiffServ PHBs by establishing a DiffServ session for single or group of flows. 7. Security Considerations The use of ISPEC (IP security) is not a problem with DiffServ because - o Per flow processing of data packets is not needed. o DiffServ session is identified by sender's address and an identifier assigned by the sender. However, message integrity and sender authentication can be applied for RSVP messages to protect from unauthorized reservations using INTEGRITY objects. But, it is required only at edge/boundary routers as against to standard RSVP processing (where it is done for each hop). rk Expiration: December 2000 [Page 10] draft-rk-diffserv-rsvp-sig-00.txt June 2000 8. References [AF] Heinanen, J., Baker, F., Weiss, W., Wroclawski, J., "Assured Forwarding PHB Group", RFC 2597, June 1999. [CL] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997 [DCLASS] Bernet, Y., "Usage and Format of the DCLASS Object With RSVP Signaling", Internet Draft draft-ietf-issll-dclass-00.txt [DIFFSERV] Blake, S., Black, D., Carlson, M., Davies, E., Wang Z., Weiss, W., "An Architecture for Differentiated Service", RFC 2475, December 1998. [EF] Jacobson, V., Nichols, K., Poduri, K., "An Expedited Forwarding PHB", RFC 2598, June 1999. [G] Schenker, S., Partridge, C., Guerin, R., "Specification of Guaranteed Quality of Service", RFC 2212 September 1997 [GENCHAR] Shenker, S., Wroclawski, J., "General Characterization Parameters for Integrated Service Network Elements", RFC 2215, September 1997 [ISDSFRAME] Several hundred people, Internet Draft draft-ietf-issll-diffserv-rsvp-03.txt [PHBID] S. Brim, B. Carpenter, F. Le Faucheur, "Per Hop Behavior Identification Codes", Internet Draft, draft-ietf-diffserv-phbid-00.txt [RSVP] Braden, R., L. Zhang, S. Berson, S. Herzog, S. Jamin, "Resource Reservation Protocol (RSVP) - Version 1 Functional Specification", RFC 2205, September 1997 [RSVPAGGR] Baker, F., Iturralde, C., Le Faucheur, F., Davie, B., "Aggregation of RSVP for IPv4 and IPv6 Reservations", Internet Draft draft-ietf-issll-rsvp-aggr-02.txt [RSVPINTSERV] Wroclawski, J., "The use of RSVP with IETF Integrated Services", RFC 2210, September 1997. 9. Authors' addresses Radhakrishna C Motorola India Electronics Ltd., The Senate, 22A, Ulsoor Road, Bangalore-560042, INDIA Phone: +91 80 559 8615 EMail: rk@miel.mot.com rk Expiration: December 2000 [Page 11]