Network Working Group Weijing Chen Internet Draft Keith Allen Expiration Date: October 2002 SBC Communications, Inc. April 2002 Extensions to RSVP for RSVP over Signaled QoS Network draft-weijing-rsvp-sqn-00.txt 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "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. Abstract This document describes the use of RSVP, including all the necessary extensions, to establish guaranteed QoS IP sessions over a signaled QoS network. The examples of signaled QoS network are ATM SVC network and MPLS network with proper UNI signaling. The specified approach is very scalable with large number of service subscribers and incurs minimum administrative and operation overhead of service providers. We propose three additional objects that extend RSVP, allowing the establishment of guaranteed QoS IP sessions from an IP Device to a Bridging Device of QoS network using RSVP as a signaling protocol. UNI signaling protocol of signaled QoS network then allows establishment of guaranteed QoS tunnel among Bridging Devices, through which guaranteed QoS IP sessions are tunneled. Consequently, the guaranteed QoS IP sessions among IP Devices are established over the signaled QoS network. Weijing, et al. [Page 1] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 1. Introduction This document discusses bridging native IP over native signaled QoS network (e.g. ATM SVC, MPLS) where UNI signaling of signaled QoS network is used to support QoS tunnel, RSVP with extension is used to support QoS IP flow. Bridging Device will take IP flow sent by IP Device and map them into proper QoS tunnel established in the signaled QoS network. QoS IP packet goes into QoS tunnel (e.g. CBR VC, VBR VC); best effort IP packet goes into best-effort tunnel (e.g. UBR VC). The entire tunnel establishment and IP flow to tunnel mapping happen dynamically through RSVP and QoS network signaling without management system intervention. This approach provides a scalable solution to offer IP QoS service with today's IP network and signaled QoS network. Section 2 covers the terminology used in this document. The detailed procedures for RSVP over signaled QoS network are described in section 3. Section 4 specifies the RSVP extension objects required by the described procedures. Rest of sections follow typical RFC template. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. Bridging Device A combination of IP Device and SQN User Device, which translates between RSVP and UNI signaling of QoS network, maps IP flow with QoS tunnel. IP device A network device which has IP function, e.g. PC, IP appliance, router, switch. IP flow A sequence of IP packets sent from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening IP devices. IP session An equivalent term of IP flow. Proxy Device An IP device which performs RSVP signaling on behalf of other IP devices. Weijing, et al. [Page 2] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 SQN (Signaled QoS Network) A switched QoS network with dynamic QoS tunnel establishment capability through signaling, e.g ATM SVC, MPLS with UNI signaling. SQN Switch Device A switching device in SQN, e.g. ATM switch, MPLS switch. SQN User Device A user device connected to SQN. SQN Tunnel A resource reserved path from a particular source to a particular (unicast or multicast) destination for which the source desires special handling by the intervening SQN switch devices. SQN UNI Signaling A signaling protocol and procedures for dynamically establishing, maintaining and clearing SQN tunnel at the SQN user device to switch device interface. 3. QoS IP Services With development of audiovisual application on the current Internet, the demands for predictable bandwidth and delay support are increasing in the IP network, which currently supports best effort communications. On the other hand, there are signaled QoS networks such as ATM SVC, MPLS LSP which are switched multiplexing with QoS tunnel (VP/VC, LSP), and guaranteed QoS per tunnel through signaling. It is quite natural to use these distinctive functions of signaled QoS network to support QoS IP service. Figure 1 shows an example scenario of network infrastructure for offering QoS IP service over SQN. Weijing, et al. [Page 3] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 SQN SQN SW device SW device +-----+ +-----+ | \ / | | \ / | BG device | X |==| |==| X | BG device |--------+ / \ | SQN | / \ +--------| +---+--+ +-----+ +-----+ +--+---+ +----+ | | | | +----+ | IP +....+-\ | | |-+....+ IP | +-û--+ | \ | | / | +----+ +---+--+ +-----+ +-----+ +--+---+ |<--------+-\ | IP | /-+------->| | R |==| |==| R | | \-+-------+-/ | +-----+default+-----+ IP router IP IP router Figure 1. Example scenario of network for QoS IP A default IP connection is established between IP devices through IP routers across IP networks. This default IP connection is used for normal best effort IP traffic between IP devices. However if an IP device requests a QoS IP session for a period of time, a QoS tunnel will be dynamic established between bridging devices across SQN networks. Hereafter, bridging device will route QoS IP flow through QoS tunnel instead of default IP connection during the period of QoS session. RSVP with minor extension is proposed for the QoS IP session setup protocol. The SQN UNI signaling MUST be the general connection setup protocol with confirmation procedure, for example ATM UNI 3.1 or ATM UNI 4.0. 3.1. QoS IP Session Figure 2 depicts an example procedure for QoS IP session establishment. Weijing, et al. [Page 4] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 IP BG Router Router BG IP device device device device device device Path | | --------->| | Path | | | | |->| (THOP) | | | | | |----------->| | Path | | | | |----------->| (THOP) | | | | | |----------->| | | | | | |->| Path | | | | | |----------> | | | | | | A. Sender's Path procedure IP BG SQN SW SQN SW BG IP device device device device device device | | Resv | | | | Setup | |<---------- | | | | (Resv) |<-| | | | |<-----------| | | | Setup | |----------->| | | | (Resv) |<-----------| Call proc | | | |<-----------| | | | |<-| | | | | |->| Conn | | | | | |----------->| | | | | |<-----------| | | | Resv |<-| Conn ack |----------->| Conn | | <---------| | | |----------->| | | | | |<-----------| | | | | | Conn ack |->| | | | | | | B. Receiver's Resv procedure Figure 2. Example procedure for QoS IP session Sender IP device sends a RSVP Path message for each QoS IP flow it originates. It MAY contains a RSVP_CYSPEC object specifying bidirectional traffic characteristics of QoS IP flow instead of RSVP SENDER_TSPEC. Weijing, et al. [Page 5] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 As in Figure 2.A, a Path message travels from a sender to receiver(s) along the default IP connection path used by the regular data packets. The sender Bridging device MUST insert its SQN address (e.g. ATM NSAP address) as RSVP_THOP object. All RSVP-capable routers along the path(s) MUST NOT modify this object. However, they MAY insert additional RSVP_THOP object(s) according to the rule defined in Section 4.1. The receiver Bridging device(s) capture the Path message and cache the mapping of the sender's IP address to the SQN address(s) in RSVP_THOP(s). It SHOULD remove the RSVP_THOP object(s) before passing Path message to the receiver IP device. As in Figure 2.B, receiver IP device receives and validates the Path message. It then responds a RSVP Resv message. It MAY contains a RSVP_CYSPEC object confirming bidirectional traffic characteristics of QoS IP flow instead of RSVP FLOWSPEC. Receiver Bridging device captures the Resv Message and launch a SQN call Setup message (e.g. ATM UNI SETUP) to the longest "short-cut" SQN address for a SQN QoS tunnel (e.g. ATM SVC). The SQN UNI signaling MUST support User-to-User signaling which enables the transfer of information between end-to-end users in the SQN (e.g. UU IE of ATM). The UU IE of the call Setup message MUST contain the Resv message. The assignment of Resv message in UU IE MUST follows RFC 3033 [8]. The traffic characteristics of SQN QoS tunnel MUST be constructed from RSVP traffic characteristics objects according to RFC 2210 [3], RFC 2211 [4], and RFC 2212 [5]. If SQN is ATM SVC network, the RFC 2381 [6] and RFC 2382 [7] MUST be followed in addition to above RFCs. If Resv message does not contain RSVP_CYSPEC, the upstream traffic characteristics of bidirectional SQN QoS tunnel are local matter. However, it is suggested that upstream QoS MAY be algorithmically calculated from RSVP FLOWSPEC. Thereafter, the Resv message travels "short-cut" path from receiver to sender instead of typical hop-by-hop default IP connection path. Sender Bridging device validates Resv with cached Path and accepts corresponding SQN call Setup. The Resv message is forwarded to sender IP device. Finally, both sender and receiver Bridging devices notify the IP layer entity that a new SQN QoS tunnel is established. Based on this information, the IP layer entity moves the QoS IP session to the new QoS tunnel as in Figure 3. Weijing, et al. [Page 6] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 SQN SQN SW device QoS SW device +-----+ tunnel+-----+ | \ / |-------| \ / | BG device | X |==| |==| X | BG device |<-------+ / \ | SQN | / \ +------->| +---+--+ +-----+ +-----+ +--+---+ +----+ | +/ | | | +----+ | IP +....+-\ | | |-+....+ IP | +-û--+ | \ | | / | +----+ +---+--+ +-----+ +-----+ +--+---+ |---------+-\ | IP | /-+--------| | R |==| |==| R | | \-+-------+-/ | +-----+default+-----+ IP router IP IP router Figure 3. Example of new SQN QoS tunnel for QoS IP The "soft state" natural of RSVP 2205 [2] SHALL be maintained to avoid orphan SQN QoS tunnel. Substantial losses of RSVP refreshment messages MUST cause a SQN QoS tunnel teardown. 3.2. Accounting Considerations The usage accounting data is normally associated with calling party of SQN QoS tunnel. However, according to the previous section the SQN calling party is the receiver of RSVP Path message. Therefore a new RSVP_SVCSPEC reverse charging object is proposed to allow that accounting data can be associated with SQN called party. The called party of SQN QoS tunnel is the sender of RSVP Path message. A Path and Resv message MAY contain RSVP_SVCSPEC reverse charging object to indicate that sender would like to accept the accounting charge instead of receiver bearing the charge. Bridging device MUST set the reverse charging indicator in SQN call Setup message when RSVP_SVCSPEC reverse charging indicator value is 1 (TRUE). If SQN UNI signaling does not support reverse charging, Bridging device MUST reject the RSVP message with corresponding error message. 4. Additional RSVP Object Definitions All the additional objects are defined here. The object follows format described in RFC 2205 [2]. The Class-Num of objects SHOULD be 11bbbbbb (192+). Weijing, et al. [Page 7] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 4.1. RSVP_THOP RSVP_THOP (transport hop) class = N1. 1. IPv4 RSVP_THOP object: Class = N1, C-Type = 1 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Transport Previous Hop Address (4) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2. IPv6 RSVP_THOP object: Class = N1, C-Type = 2 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 Transport Previous Hop Address (16) | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3. ATM RSVP_THOP object: Class = N1, C-Type = 3 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ATM Transport Previous Hop NSAP Address (20) | + + | | + + | | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object class MAY appear in RSVP Path message. It carries the transport network address of the interface through which the Path message was most recently sent. Only the IP Device that egress interface of RSVP Path message is connected to SQN (e.g. ATM SVC network) and ingress interface of RSVP Path is connected to a different transport network does send out this object. All other IP Devices must pass the object without modification. Multiple Weijing, et al. [Page 8] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 RSVP_THOP objects MAY appear in a PATH message. The order of objects in the Path message MUST be LIFO (Last-In-First-Out). 4.2. RSVP_CYSPEC RSVP_CYSPEC (bidirectional flow spec) class = N3. 1. RSVP_CYSPEC object: Class = N3, C-type = 2 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 (a) | reserved | Msg length - 1 (b) | +---------------------------------------------------------------+ | Tspec (RSVP FLOWSPEC without header) | +---------------------------------------------------------------+ | Rspec (RSVP FLOWSPEC without header) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ (a) - Message format version number (0) (b) - Overall message length not including header word This object contains bidirectional IP flow specification. It MAY appear in RSVP Path and Resv message. The Tspec field describers sending flow spec, Rspec field receiving flow spec. Rules for composing RSVP FLOWSPEC are defined in RFC 2210 [3]. 4.3. RSVP_SVCSPEC RSVP_SVCSPEC (SerViCe Specification) class = N4. This object class supports value-added RSVP service signaling from IP Device to IP Device. 1. RSVP_SVCSPEC reverse charging object: Class = N4, C-type = 2 31 24 23 16 15 8 7 0 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reverse charging indicator | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This object contains a Boolean value to indicate whether RSVP Path message sender requests "Called Party Pay" feature of SQN. A value of 1 (TRUE) indicates "Called Party Pay". A value of 0 (FALSE) indicates no "Called Party Pay". Other values are not defined. It MAY appear in Path and Resv message. Weijing, et al. [Page 9] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 5. Security Considerations The same considerations stated in RFC 2205 [2] apply to this document. There are no additional security issues raised in this document regarding RSVP. If the signaled QoS network is ATM SVC network, the same considerations stated in RFC 3033 [8] apply to this document. There are no additional security issues raised in this document regarding ATM UNI signaling. If the signaled QoS network is other type network, the proposal in this document does not weaken the security of UNI signaling of that network. 6. Acknowledgements Authors would like to thank Will Chorley and Kou-hui Liu of SBC Technology Resources, Inc. for their valuable support and advices. Authors would also like to thank Bob Daily, Paul Van Vleck, and Marco Schneider of SBC Technology Resources, Inc. for their valuable comments and discussions. Weijing, et al. [Page 10] Internet Draft draft-weijing-rsvp-sqn-00.txt March 2002 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [2] Bradner, S., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) û Version 1 Functional Specification", RFC 2205, September 1997. [3] Wroclawski, J., "The Use of RSVP with IETF Integrated Services", RFC 2210, September 1997. [4] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [5] Shenker, S., Partridge, C., Guerin, R., "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [6] Garrett, M., Borden, M., "Interoperation of Controlled-Load Service and Guaranteed Service with ATM", RFC 2381, August 1998. [7] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and J. Krawczyk, "A Framework for Integrated Services and RSVP over ATM", RFC 2382, August 1998. [8] Suzuki, M., "The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol", RFC 3033, January 2001. Authors' Addresses Weijing Chen SBC Technology Resources, Inc. 9505 Arboretum Blvd. Austin, Texas 78759 Phone: +1 512 372 5710 Email: wchen@tri.sbc.com Keith Allen SBC Technology Resources, Inc. 9505 Arboretum Blvd. Austin, Texas 78759 Phone: +1 512 372 5741 Email: kallen@tri.sbc.com Weijing, et al. [Page 11]