idnits 2.17.1 draft-kandlur-issll-rsvp-mars-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (17 September 1996) is 10082 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Unexpected draft version: The latest known version of draft-ietf-ipatm-ipmc is -11, but you're referring to -12. -- Possible downref: Normative reference to a draft: ref. 'Ber96a' == Outdated reference: A later version (-03) exists of draft-ietf-issll-atm-support-00 -- Possible downref: Normative reference to a draft: ref. 'Ber96b' -- No information found for draft-borden-intserv-atm-mapping - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'BG96' == Outdated reference: A later version (-01) exists of draft-ietf-ion-marsmcs-00 ** Downref: Normative reference to an Informational draft: draft-ietf-ion-marsmcs (ref. 'RT96') -- No information found for draft-yavatkar-sbm-ethernet - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RY96' Summary: 10 errors (**), 0 flaws (~~), 3 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force R. Guerin 2 INTERNET DRAFT D. Kandlur 3 D. Williams 4 IBM 5 17 September 1996 7 Extensions to the MARS model for Integrated Services 8 draft-kandlur-issll-rsvp-mars-00.txt 10 Status of This Memo 12 This document is an Internet-Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet Drafts are draft documents valid for a maximum of six 18 months, and may be updated, replaced, or obsoleted by other documents 19 at any time. It is not appropriate to use Internet Drafts as 20 reference material, or to cite them other than as a ``working draft'' 21 or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check 24 the ``1id-abstracts.txt'' listing contained in the internet-drafts 25 Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 Abstract 31 This memo describes an extension to the IP multicast architecture 32 now being developed by the IP over ATM working group, also known as 33 MARS (Multicast Address Resolution Server). This extension expands 34 the responsibilities of the Multicast Server (MCS) to adapt it to 35 the Integrated Services Internet Architecture and related signaling 36 protocols such as RSVP. 38 1. Introduction 40 The MARS document [Arm96] describes a mechanism for handling IP 41 multicast over ATM. Clusters of endpoints, currently defined by 42 IP subnetwork boundaries, share a MARS and use it to track and 43 disseminate information on membership in multicast groups. This 44 allows endpoints to establish VCCs and to transmit to their multicast 45 group over these VCCs. Multicasting is supported using either meshes 46 of VCs or ATM-level multicast servers (MCSs). The choice is made on 47 a per-group basis and is transparent to the endpoints. 49 1.1. The Problem 51 In a IP/ATM subnetwork using the MARS protocol for IP multicast 52 address resolution, an Multicast Server (MCS) may be used to forward 53 IP multicast datagrams. This Multicast Server is transparent to the 54 end stations and its operation is further defined in [RT96]. An end 55 station (the MARS client) requests the MARS server for resolution 56 of IP multicast addresses and receives a list of ATM addresses. It 57 then creates a virtual connection to members of this list, which 58 may consist of the MCS or all of the local members of the multicast 59 group, to deliver packets addressed to this multicast address. 60 Currently, this connection is set up with best-effort service class. 61 The purpose of this document is to investigate the operation of the 62 MARS/MCS in the presence of IP Integrated Services and RSVP. 64 We consider the ``classical'' framework for handling RSVP and 65 Integrated Services over ATM described in [Ber96b, Ber96a]. In 66 this model, an RSVP ``flow'' is mapped onto an ATM VCC with QoS 67 attributes. The guidelines for this mapping are described in 68 [BG96]. Specifically, for multicast flows, when a source receives 69 a RESV message for a given multicast session, it is responsible for 70 creating a virtual connection with the appropriate quality-of-service 71 specification to match the service requested in the RESV message. 72 However, when an MCS is used, this virtual connection only extends 73 from the source to the MCS (see Fig. 1). The forwarding path 74 from the MCS to the destination end-stations will continue to be 75 best-effort since the MCS has no knowledge of the QoS information, 76 and the delivery mechanisms currently defined for the MCS only 77 specify UBR VCCs. Moreover, since the MCS does not process RSVP 78 messages, the destination stations would not be able to detect this 79 breach of service. 81 Figure 1: Data flow with MCS 83 2. Possible Solutions 85 One solution is to place IP multicast group information in the ATM 86 setup message when the sender creates an ATM VC (to the MCS). The 87 receiver, in this case the MCS, can then use this information to 88 create a QoS VC towards the receivers of the multicast group. It 89 would derive the QoS parameters from the QoS and traffic information 90 elements received in the ATM SETUP message, and IP multicast group 91 information from the information elements reserved for protocol 92 information. Unfortunately, this approach has several deficiencies: 94 1. the MCS does not have access to RESV messages so it is not able 95 to distinguish between receivers which have made reservations 96 from those that have not made any reservation 98 2. the MCS would require additional information to handle shared 99 reservations 101 A second approach would be to apply the SBM mechanism [RY96] to 102 ATM. In this approach, the SBM would be co-located with the MCS and 103 receivers would send RESV messages to the SBM/MCS. However, it has 104 some disadvantages in the ATM context: 106 1. unlike the Ethernet environment, the SBM/MCS is used only for 107 reservations for multicast sessions. This requires special 108 mechanism for differentiating between unicast and multicast 109 sessions. 111 2. it requires either additional configuration of end-stations (for 112 the SBM address) or a cheap multicast mechanism. 114 A third, and we believe more effective, solution would be to make 115 the MCS participate in RSVP signaling by processing IP/RSVP packets. 116 The MCS would intercept PATH messages and change the RSVP_PHOP field 117 to the address of the MCS. This change would ensure that the RSVP 118 agents on the receivers would direct their RESV responses to the 119 MCS. The MCS would process these RESV responses, perform merging as 120 applicable, and then forward them to the appropriate previous hops. 121 The processing done by the MCS is similar to that performed by an 122 RSVP router, or a subnetwork bandwidth manager (SBM). This approach 123 differs from the SBM approach in that the MCS also processes RSVP 124 PATH messages. There are several advantages to this approach: 126 1. it is transparent to end-stations 128 2. it does not require any protocol modifications to RSVP 130 3. it places responsibility on the MCS, which is part of the data 131 forwarding path and, hence, necessarily involved with the setup 132 of QoS connections. 134 4. it requires no additional configuration to end-stations or a 135 multicast mechanism for discovery of the MCS. 137 3. Summary 139 This draft described several approaches to handling IP Integrated 140 Services flows in the presence of an MCS. From the discussion, it is 141 apparent that the preferred solution is one in which the MCS is RSVP 142 aware and participates in the signaling process in a manner that is 143 transparent to end stations. Further specification of this approach 144 will be pursued based on the recommendation of the working group. 146 References 148 [Arm96] G. Armitage. Support for Multicast over UNI 3.1 based ATM 149 Networks. Internet Draft, draft-ietf-ipatm-ipmc-12.txt, 150 February 1996. 152 [Ber96a] L. Berger. RSVP over ATM: Framework and UNI 3.0/3.1 Method. 153 Internet Draft, draft-berger-rsvp-over-atm-00.ps, June 1996. 155 [Ber96b] S. Berson. IP Integrated Services Support in ATM. Internet 156 Draft, draft-ietf-issll-atm-support-00.ps, June 1996. 158 [BG96] M. Borden and M. Garrett. Interoperation of Controlled-Load 159 and Guaranteed-Service with ATM. Internet Draft, 160 draft-borden-intserv-atm-mapping-00.txt, June 1996. 162 [RT96] M. Ammar R. Talpade. Multicast Server Architectures 163 for MARS-based ATM multicasting. Internet Draft, 164 draft-ietf-ion-marsmcs-00.txt, June 1996. 166 [RY96] D. Hoffman R. Yavatkar, E. Patki. SBM (Subnet Bandwidth 167 Manager): A Proposal for Admission Control over Ethernet. 168 Internet draft, draft-yavatkar-sbm-ethernet-00.txt, June 169 1996. 171 4. Authors' Address 173 Roch Guerin 174 IBM T.J. Watson research Center 175 P.O. Box 704 176 Yorktown Heights, NY 10598 177 guerin@watson.ibm.com 178 VOICE +1 914 784-7038 179 FAX +1 914 784-6318 181 Dilip Kandlur 182 IBM T.J. Watson research Center 183 P.O. Box 704 184 Yorktown Heights, NY 10598 185 kandlur@watson.ibm.com 186 VOICE +1 914 784-7722 187 FAX +1 914 784-6205 189 Doug Williams 190 IBM T.J. Watson research Center 191 P.O. Box 704 192 Yorktown Heights, NY 10598 193 dougw@watson.ibm.com 194 VOICE +1 914 784-5047 195 FAX +1 914 784-6318