ATM Forum: Technical Committee ATM Forum/ 96-0314r1 ****************************************************************************** Source: Multiprotocol Sub-Working Group Secretary: Caralyn Brown Bay Networks, Inc. 2 Federal Street Billerica, MA 01821 Phone: (508) 436-3835 Fax: (508) 670-8760 Email: cbrown@baynetworks.com ****************************************************************************** Title: RSVP Birds of a Feather Meeting Minutes, February 1996 ****************************************************************************** Date: March 5, 1996February 23, 1996 ****************************************************************************** Distribution: Multiprotocol Sub-Working Group ****************************************************************************** Abstract: This document contains meeting minutes from the RSVP birds of a feather (BoF) held during the technical committee meeting held February 5-9, 1996. ****************************************************************************** Notice: This contribution has been prepared to assist the ATM Forum. This document is offered to the Forum as a basis for discussion and is not a binding proposal on Bay Networks, Inc. The requirements are subject to change in form and value after more study. ****************************************************************************** Minutes of the RSVP Birds of a Feather Meeting ATM Forum Beverly Hills, CA February 7, 1996 The meeting was called to order at 1:05 PM by MPOA chairman George Swallow. Contribution 0258 - presented by Steve Berson of USC Information Sciences Institute. IETF working group information: RSVP working group rsvp@isi.edu http://www.isi.edu/div7/rsvp/rsvp.html The next meeting of the IETF is scheduled for March 4-8 in Los Angeles. The speaker indicated that the goal of the RSVP effort in this context is seamless internetworking with IP and ATM. Assumptions. 1. IP “best effort” is default service 2. IP Multicast 3. Limited heterogeneity assumption IP best effort (or default) service = unreserved, and 1 reserved service. 4. Single VC per flow assumption simplifying assumption what is a flow - depends on reservation style, etc. What is RSVP RSVP is IP signaling. RSVP features: receiver oriented support for heterogeneity dynamic QoS multiple reservation styles simplex reservations “soft state” RSVP is not a routing protocol RSVP is not traffic management. Dynamic QoS and best effort service were mentioned as high priority discussion topics. The speaker indicated that reservation messages follow the path of the path messages and do not follow “normal” routing (path messages do use routing). He also said that tspec senders estimate what type of traffic they will be sending and indicate this in the tspec. Reservation Styles Sender Selection Distinct (e.g. video) Shared (e.g. audio) Explicit Fixed Filter Style (FF) Shared Explicit (SE) Wildcard none Wildcard filter (WF) FF SE WF Wildcard distinct n+1 VCs 2VCs 1 VC m VC Assume m sources and 1 receiver Assume n filters in explicit style reservation A filter specifies a traffic source, e.g. (IP address, source port) The speaker said that disparate filter styles is an error in this environment and that he assumed this would be coordinated at a session layer. Hierarchy of solution IntServ IP-over-ATM ATM Signaling This concentrates on signaling. Dynamic QoS 1. receiver makes a reservation (e.g. default to QoS) 2. receiver changes reservation (e.g. QoS to default) 3. sender changes traffic pattern 4. merging of reservations 5. number of sources changes (SE or WF style) Summary To best support next generation IP traffic 1. provide signaling support to “heterogeneous” VCs Particularly IP best effort and single QoS. 2. Provide renegotiation of point to multipoint VCs. Routing side effect issues. IP over ATM solutions Heterogeneity multiple VCs problem - duplicate traffic. Dynamic QoS tear down and reestablish VCs problem - signaling latency IntServ Solutions Heterogeneity Dynamic QoS relax the VC per flow assumption “large pipes” solves heterogeneity solves dynamic QoS solves signaling latency problem problem - how to allocate VCs important future research. Misc. Issues translating IP QoS to ATM QoS VCs for RSVP RSVP & multicast server vs. mesh Miscellaneous Future issues. aggregation on ATM “large pipes” RSVP & short cut routing. Contribution 96-0094 - presented by Roch Guerin of IBM Motivations RSVP and integrated services specifications together provide mechanisms to support end to end QoS guarantees, that many applications are expected to use. Goal: extend RSVP services across ATM networks. preserver RSVP/Int-Serv flexibility, scalability, and features leverage efficiency of ATM switching avoid wastage of ATM network resources Exploit facilities provided in emerging ATM standards for signaling (UNI 4.0), traffic management (TM 4.0) and network control (PNNI) and suggest possible extensions. The speaker indicated that if the group was not careful the solution could become very expensive. He continued to say that we could take what exists today and simply map RSVP to that and stop there. Instead, he proposed looking forward and attempt to influence the standard. Preliminaries RSVP session defined by a destination IP address, protocol type, destination port number an RSVP session may contain one or more flows originating at different sources service specification: one pass with advertising (path and reserve messages) receivers specify desired quality of service and reservation style distinct or shared reservations explicit or wildcard sour e selection. QoS is really the sum of those things along the path. Unicast Flows Leverage ATM switching map flows onto ATM VCs and maximize cut through to minimize layer 3 processing overhead. Cut through determination where to set it up? identify ingress and egress points (may depend on glow characteristics) When to set it up? need awareness of reservation parameters (from Reserve message) How to set IP up? mapping of ATM and RSVP signaling (Reserve <-> SETUP) Cut through maintenance preserve robustness to route changes (react to “meaningful” changes and ignore “meaningless” ones) -- -get route change, but it doesn’t effect your end station, so don’t want to tear it down just to set the same VC back up again. link ATM and RSVP connection maintenance mechanisms (soft vs hard states) Service mapping (more later) Shared reservations require additional ATM support to avoid wastage. signaling support (ATM level call correlator) switch/service support (policing/shaping for merging of flows). Multicast flows Same problem as unicast but more complex cut through to many egress points more complex interactions with routing sharing based on senders and receivers In addition, multicast flows also involve scalability of ATM point-to-multipoint setup handling of QoS heterogeneity on different leaves of ATM point-to-multipoint VC. Multicast flows - some specific issues ATM UNI 3.1 point-to-multipoint setup presents scalability problems source add-party does not scale handling of Reserve refresh messages. ATM UNI 4.0 addresses them partially with LIJ scalable solution for maintaining and managing multicast groups is required use of LIJ in higher level protocol mappings is required. QoS heterogeneity different receivers in a call may have different service requirements (impacts both signaling and service provision). can anything be done at the ATM layer to minimize wastage of resources (impact on shortcut selection)? IP routing may also change as a function of QoS requirements. Generic Service mapping issues Major areas to be considered. Mapping of services and associated guarantees guaranteed service -> RT VBR etc. packet vs cell loss, jitter, delay, etc. Handling of packets: compliance/conformance checking, policing, etc. where done? packets vs cell, etc. Availability of service characterization for end to end guarantees delay across the ATM network for ADSPEC update leveraging of ATM control information (PNNI or even I-PNNI). Summary There are several important issues that need to be considered while handling RSVP flows over an ATM network cut through routing signaling for point to multipoint flows traffic management and availability of ATM network information support for shared reservations Problems span many different areas including address resolution traffic management signaling routing, network control, etc. We believe that addressing these issues requires a concerted effort, but that they can be resolved without sacrificing much in terms of functionality and/or performance by appropriate extensions to the RSVP/Int-Serv and ATM specifications. Contribution 96-0039 - presented by Marty Borden of Bay Networks The speaker indicated that RSVP is indeed real and workable. During the Interop in September a multivender RSVP demonstration took place and was quite successful. Just what is QoS? ITU Service Categories ATMF Service Classes (CBR, VBR-rt...) ATMF QoS Parameters PCR, SCR, CLR, mean CTD, max CTD, CDV Other Ideas! prioritization (e.g. controlled-load) More to come! Some Related IETF Tasks Intserv -- Service Templates (first two are close to becoming standard) Guaranteed Service Controlled Load More RSVP -- “connection control” IDMR -- multicast routing not “QoS” spec, but the service needs it. General Work Areas Service Model Translation (IntServ) Map IP QoS to ATM QoS No unique method Not for standardization Signaling and reservation (RSVP) Multicast & QoS routing (IDMR) indirectly applicable to BOF topic work needed, but not part of this contribution. Different Services in a Flow Multiple source entry points - note that the new S5 does not necessarily have the same end points on the point-to- multipoint VC that was there for S1 and S2. Heterogeneous Receivers Two approaches construct tree with “maximum” QoS. Tear down, renegotiate or augment when maximum QoS requirement changes. Allow tree to have different QoS along branches. Use renegotiation and RSVP-style merging of QoS needs. Suggestions solutions should avoid proliferation of VCs Investigate renegotiation of QoS Investigate variegated point to multipoint trees. (different QoS on different branches on the tree) Avoid finer issues like cut-through for now. A participant commented that the word “proliferation” was ambiguous. Another asked the speaker whether the first and forth suggestion bullets contradicted each other. Some discussion about the merits of cut through ensued and the speaker covered up the fourth bullet and most seemed satisfied. Contribution 96-0096 - presented by Vijay Srinivasan of IBM The speaker indicated that this presentation did not propose any solutions. He further mentioned that he previously thought this was not a topic for standardization. Now, however, he believed that there were a sufficient number of issues that need consideration. Scope Generate work items and discussion within ATM forum Interoperability issues only related to mapping intserv service classes to ATM Limit attention to service specifications currently being considered by intserv group within IETF. Service Models: IETF/ATM Guaranteed Delay Constant Bit Rate Controlled Delay Real time variable Bit rate Predictive Non real time variable bit rate Controlled Load Available Bit rate Unspecified bit rate. IETF model uses RSVP to implement resource reservations Leaky bucket model (peak rate under consideration) to characterize traffic Delay is the only quantified QoS metric ATM model uses UNI/PNNI signaling or requesting QoS Similar traffic characterization QoS Classes (UNI 3.1 or later) or individual QoS parameters (UNI 4.0) Can specify CTD, CDV, CLR. The speaker indicated that he believed the intents of the model were similar but there are significant difference that threaten interoperability. ATM QoS Classes Service Class A: Circuit emulation, constant bit rate video -> QoS class 1 Service Class B. variable bit rate audio and video -> QoS class 2 Service Class C: connection oriented data issues -> QoS class 3 Connectionless data Transfer -> QoS class 4 Common Mapping Issues Definition of new QoS classes account for qualitative QoS measures performance issues, processing load on switches new QoS parameters What ATM traffic categories to map RSVP flows to? CBR/rt-VBR sufficient to support sessions with end to end bounds? need for new ATM traffic categories nrt-VBR, ABR, UBR? The speaker commented that we were leaving service classes for interoperability with ITU and backward compatibility, Use of the service classes for future work is being studied in several areas including the IETF.but we probably shouldn’t be using them for future work. This was not necessarily agreed upon by the membership. Renegotiation General issue related to mapping RSVP to ATM important to have a renegotiation mechanisms along Q.29xx (get best reference) Guaranteed delay service provides firm bounds on maximum end-to-end delay every conforming flow is guaranteed this delay with probability 1 a rate is reserved at every node the session traverses bound comprised of 3 parts: (i)delay for fluid source with “pipe” through the network (ii) “error” terms. Guaranteed delay -- issues What information is available from the ATM network to determine end-to-end delay bound? Need information for “error” terms Modifications to PNNI/UNI signaling Modifications to PNNI database Controlled Delay Service Applications choose from several levels of delays Level 1 “better” than level 2 “better” than level 3 ... No assurances of absolute levels of delays Node advertises estimates of delays over different time intervals for each delay level. Estimates obtained via measurement (need not be accurate). Controlled Delay -- issues Can interoperate easily with ATM by treating ATM layer delays as fixed conservative, since ATM delays can be quite variable Make similar measurements available from ATM layer? changes to UNI/PNNI signaling changes to PNNI database support from traffic management. A member commented that we should be sure of the assumption here before messing with signaling etc. Predictive Service Intended for applications that desire reserved rate with low packet loss “occasional” late or lost packets tolerated Similar model as controlled delay Controlled load service Most minimal service description only single level of service service closely resembles best effort delivery under “unloaded” network conditions policing at every network element Need to define a QoS Class that adequately captures requirement ABR, nrt-VBR, UBR appear to be candidates. modifications to ATM traffic categories? Summary Preliminary list of work items; need to generate complete list and consider work items at the earliest Work with other groups within ATM forum to achieve smooth interoperability between RSVP flows and ATM. Contribution 96-0160 - presented by Dean Skidmore of IBM. This was a two page contribution read it. The speaker indicated that there is software available from ISI which can be accessed via the www as indicated above (see notes from contribution 96-0258). Group address: A participant indicated that he felt that there were no proposals that would scale and that we need not mandate it right now. Another participant suggested that there was a viable solution, but that it had been neglected as a result of higher priority issues. The speaker suggested that the API for mapping RSVP “verbs” to sockets is important. Contribution 96-0019 - presented by Yakov Rekhter of Cisco Systems The speaker presented the same slides as were presented in the MPOA main meeting. Please refer to those meeting minutes for a summary of the slides. The speaker made the point that RSVP may be a mechanism to trigger a shortcut, but it should not be the only one. Contribution 96-0028 - presented by Yakov Rekhter of Cisco Systems Motivations IETF is working on extending “best effort” IP service intserv WG developed specifications for various quality of services RSVP working group developed a protocol to convey resource reservations to the network ATM provides QoS support How can IP exploit ATM QoS RSVP overview receiver initiated setup of resource reservation (stuff I missed) tspec (traffic specification) describes the traffic characteristics filter spec describes the set of packets that form the flow Rspec (reservation specification) defines the desired QoS Adspec (advertising specification) path messages from senders to receivers carry tspec, filter and adspec (options) reservation message (stuff I missed) rspec and filter spec One pass with advertisement (OPWA) provides receivers with the information that helps to predict end to end QoS adspec (carried in a path message) is updated by RSVP-capable routers along the path. Handling Adspec the amount of memory required to update adspec may be significant the measurements needed to update adspec may not be feasible in the fast switching path even if feasible, may be undesirable - could degrade switching performance. The speaker indicated that there is the theory and then there is practice. Between the two is a large gap. He further indicated that routers’ fast paths are not tuned to this behavior (counting and switching at the same time). A participant noted that there is no measurement required for the guaranteed service though others still require it. Another member defended the Adspec saying that it did not consume a significant amount of memory. Others seemed to disagree. There was also a suggestion that the Adspec was, perhaps, not sufficiently defined. For certain services the information required to update Adspec may not be available at all: requires Adspec to be updated with the value of the max packet transfer delay through each network element along a path what to do when some, but not all, the network elements are controlled at the RSVP level. RSVP controlled network elements should act as “proxies” for the network elements that are not directly controlled by RSVP: QoS supported by the network elements should be semantically equivalent to the QoS requested at the IP layer network elements not controlled by RSVP should have the required information there is a protocol to convey the information from the elements that are not RSVP-controlled to the elements that are RSVP controlled. An audience member pointed out that this need not be a full blown protocol. It could simply be a measurement (for example, from a “wire”). Use of RSVP “proxies” is fairly problematic in certain environments (e.g., switched Ethernet) ethernet switches do not have the required information. There was a comment that this is a larger problem because, though we call them legacy, these networks are 90% of the market. Use of RSVP “proxies” with ATM involves inaccurate estimates could lead to over-estimation. Used by: guaranteed QoS controlled delay QoS predictive QoS Not used by controlled load guaranteed bandwidth (implemented but not documented) The speaker indicated that he believed that those services require Adspec will remain as documents without working code. Observation: support for quality of services that involves Adspec has a fair number of open issues with or without ATM. Recommendation: perhaps we should focus (for now) on specifying support for quality of services that does not involve Adspec. One participant indicated that Adspec is important and we should not abandon those services that use it. Instead, they believed we should figure out how to make the Adspec work. Other disagree and state that RSVP was designed without Adspec and it was, therefore, not crucial to RSVP. A member suggested that we should concentrate on services that are implementable today. The group then discussed what working groups should be doing what and a member indicated that he felt the group was bashing the IETF and that this was not the point of the BoF. The presenter disagreed strongly that we were bashing the IETF. Contribution 96-0097 - presented by Dean Skidmore of IBM This was presented in the opening plenary also. The presenter started with a brief history of SAA since July of 1993 Problem space Objective efficient support of real time applications using IP integrated services and resource reservation setup protocol (RSVP) over an ATM switched network. Potential work areas programming interface extensions to gain access to RSVP or Q.2931 Internet integrated service definitions mapped to ATM service categories Interworking between RSVP and ATM SIG Network Element behaviors Recommendation Establish liaison with IETF Intserv and RSVP workgroups and use their draft documents as basis of analysis work. Based on SAA charter and work real time applications, we propose that a new ADHOC group under SAA be started. This ADHOC Group would be called real time protocols over ATM (RPOA) and would have the initial charter to identify the issues and requirements for the problem space. A member asked what it meant to create a liaison with the IETF. The presenter indicated that for one there were no mailing lists in common. Others indicate that the mailing lists were just created and this is no longer a problem. The presenter acknowledged he was unaware of these new lists. It was suggested that the first bullet could be translated into “let’s really talk to them.” The presenter suggested that a new group could manage the issues and was not necessarily obligated to create a new document A member pointed out that since documents are the only output from a work group it would be difficult to measure the groups usefulness. Perhaps they would produce a set of requirements. A participant suggested that there was already a group defined to do IP over ATM and asked what the imperative was to create another group. He further suggested that looking at RSVP from the top or the bottom created a very different perspective. Since the group woks on networking “stuff” the member indicated that we should be looking up at RSVP. Another participant indicated that he felt that having one working group tell another one what to do never works. We are dooming ourselves from the beginning. Still another participant believed that it might be helpful to create this group so that we have someone to contribute through. Others believed that the MPOA group can do this by contribution and that other groups were not needed.. MOTION: Dean Skidmore moved that, based on SA&A charter and work on real time applications, we propose that a new ADHOC group under SA&A be started. This motion was seconded by Eric Lampland of Digi International. It was clarified that this meant that this would be recommended at the closing plenary. Discussion: Some question what the actual work items proposed were. The presenter instructed the group to refer to the problem space slide. Several indicated that they felt this was a bad idea and that we would be stepping over our own toes. The speaker said that these issues were not being addressed elsewhere. Another noted that the IETF was working on the problem of mapping IntServ over ATM already and that creating new groups simply dilutes the pool of people available to do the work. Eric Lampland called the question. There was a second on the call and no one opposed. VOTE: Yes 3; No 27, abstain 11 The chairman indicated that the MPOA group is more than willing to accept contributions on this topic. The meeting was adjourned at 5:45 PM. RSVP BoF Meeting Minutes ATMF/96-0314r1 3/5/962/23/96 page 121