idnits 2.17.1 draft-ietf-issll-atm-imp-guide-01.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-18) 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 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 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. ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([3], [6], [8]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 75: '... implementations SHOULD send RSVP cont...' RFC 2119 keyword, line 116: '... implementations SHOULD use independen...' RFC 2119 keyword, line 173: '... implementations SHOULD simply follow ...' RFC 2119 keyword, line 175: '...hat same end-point SHOULD be used when...' RFC 2119 keyword, line 227: '... implementations SHOULD implement one ...' (1 more instance...) 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 (July 11, 1997) is 9778 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) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' == Outdated reference: A later version (-03) exists of draft-ietf-issll-atm-support-02 -- Possible downref: Normative reference to a draft: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' -- Possible downref: Non-RFC (?) normative reference: ref. '6' -- Possible downref: Non-RFC (?) normative reference: ref. '7' -- Possible downref: Non-RFC (?) normative reference: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '9' Summary: 10 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft L. Berger 2 Expires: January 1998 FORE Systems 3 File: draft-ietf-issll-atm-imp-guide-01.txt 5 RSVP over ATM Implementation Guidelines 7 July 11, 1997 9 Status of Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as "work in progress." 21 To learn the current status of any Internet-Draft, please check the 22 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Abstract 29 This note presents specific implementation guidelines for running 30 RSVP over ATM switched virtual circuits (SVCs). The general problem 31 is discussed in [8]. Implementation requirements are discussed in 32 [3]. Integrated Services to ATM service mappings are covered in [6]. 33 The full set of documents present the background and information 34 needed to implement Integrated Services and RSVP over ATM. 36 1. Introduction 38 This note discusses running IP over ATM in an environment where SVCs 39 are used to support QoS flows and RSVP is used as the internet level 40 QoS signaling protocol. It applies when using CLIP/ION, LANE2.0 and 41 MPOA methods for supporting IP over ATM. The general issues related 42 to running RSVP[7] over ATM have been covered in several papers 43 including [8,4,2,5]. This document is intended as a companion to 44 [8,3] and as a guide to implementers. The reader should be familiar 45 with both documents. 47 This document will provide a recommended set of functionality for 48 implementations using ATM UNI3.x and 4.0, while allowing for more 49 sophisticated approaches. We expect some vendors to additionally 50 provide some of the more sophisticated approaches described in [8], 51 and some networks to only make use of such approaches. The 52 recommended set of functionality is defined to ensure predictability 53 and interoperability between different implementations. Requirements 54 for RSVP over ATM implementations are provided in [3]. 56 This document uses the same terms and assumption stated in [3]. 58 2. Implementation Recommendations 60 This section provides implementation guidelines for implementation of 61 RSVP over ATM. Several recommendations are common for all, both 62 unicast and multicast, RSVP sessions. There are also recommendations 63 that are unique to unicast and multicast session types. 65 2.1 RSVP Message VC Usage 67 The general issues related to which VC should be used for RSVP 68 messages is covered in [8]. It discussed several implementation 69 options including: mixed control and data, single control VC per 70 session, single control VC multiplexed among sessions, and 71 multiple VCs multiplexed among sessions. QoS for control VCs was 72 also discussed. The general discussion is not repeated here and 73 [8] should be reviewed for detailed information. 75 RSVP over ATM implementations SHOULD send RSVP control (messages) 76 over the best effort data path, see figure 1. It is permissible 77 to allow a user to override this behavior. The stated approach 78 minimizes VC requirements since the best effort data path will 79 need to exist in order for RSVP sessions to be established and in 80 order for RSVP reservations to be initiated. The specific best 81 effort paths that will be used by RSVP are: for unicast, the same 82 VC used to reach the unicast destination; and for multicast, the 83 same VC that is used for best effort traffic destined to the IP 84 multicast group. Note that for multicast there may be another 85 best effort VC that is used to carry session data traffic, i.e., 86 for data that is both in the multicast group and matching a 87 sessions protocol and port. 89 Data Flow ==========> 91 QoS VCs 92 +-----+ --------------> +----+ 93 | | --------------> | | 94 | Src | | R1 | 95 | | Best Effort VC(s) | | 96 +-----+ <-----------------> +----+ 97 /\ 98 || 99 || 100 RSVP Control 101 Messages 103 Figure 1: RSVP Control Message VC Usage 105 The disadvantage of this approach is that best effort VCs may not 106 provide the reliability that RSVP needs. However the best-effort 107 path is expected to satisfy RSVP reliability requirements in most 108 networks. Especially since RSVP allows for a certain amount of 109 packet loss without any loss of state synchronization. 111 2.2 Aggregation 113 As discussed in [8], data associated with multiple RSVP sessions 114 could be sent using the same shared VCs. Implementation of such 115 "aggregation" models is still a matter for research. Therefore, 116 RSVP over ATM implementations SHOULD use independent VCs for each 117 RSVP reservation. 119 2.3 Short-Cuts 121 Short-cuts allow ATM attached routers and hosts to directly 122 establish point-to-point VCs across LIS boundaries, i.e., the VC 123 end-points are on different IP sub-nets. Short-cut support for 124 unicast traffic has been defined in [9] and [1]. The ability for 125 short-cuts and RSVP to interoperate has been raised as a general 126 question. The area of concern is the ability to handle asymmetric 127 short-cuts. Specifically how RSVP can handle the case where a 128 downstream short-cut may not have a matching upstream short-cut. 129 In this case, which is shown in figure 2, PATH and RESV messages 130 following different paths. 132 ______ 133 / \ 134 +-------- / Router \ <-------+ 135 | \ / | <....... RESVs Follow 136 | \______/ | Hop-by-hop Path 137 | | 138 | | 139 V QoS VCs | 140 +-----+ ==============> +----+ 141 | | ==============> | | 142 | Src | | R1 | 143 | | Best Effort VC(s) | | 144 +-----+ <=================> +----+ 146 /\ 147 :: Data Paths: 148 :: ----> Hop-by-hop (routed) 149 PATHs and Data ====> Short-cut 150 Follow Short-cut 151 Path 153 Figure 2: Asymmetric RSVP Message Forwarding With ATM Short-Cuts 155 Examination of RSVP shows that the protocol already includes 156 mechanisms that allows support of short-cuts. The mechanism is 157 the same one used to support RESV messages arriving at the wrong 158 router and the wrong interface. The key aspect of this mechanism 159 is RSVP only processing messages that arrive at the proper 160 interface and RSVP forwarding of messages that arrive on the wrong 161 interface. The proper interface is indicated in the NHOP object 162 of the message. So, existing RSVP mechanisms will support 163 asymmetric paths. 165 The short-cut model of VC establishment still poses several issues 166 when running with RSVP. The major issues are dealing with 167 established best-effort short-cuts, when to establish short-cuts, 168 and QoS only short-cuts. These issues will need to be addressed by 169 RSVP implementations. 171 The key issue to be addressed by any RSVP over ATM solution is 172 when to establish a short-cut for a QoS data flow. RSVP over ATM 173 implementations SHOULD simply follow best-effort traffic. When a 174 short-cut has been established for best-effort traffic to a 175 destination or next-hop, that same end-point SHOULD be used when 176 setting up RSVP triggered VCs for QoS traffic to the same 177 destination or next-hop. This will happen naturally when PATH 178 messages are forwarded over the best-effort short-cut. Note that 179 in this approach when best-effort short-cuts are never 180 established, RSVP triggered QoS short-cuts will also never be 181 established. 183 2.4 Data VC Management for Heterogeneous Sessions 185 Heterogeneous sessions can only occur with multicast RSVP 186 sessions. The issues relating to data VC management of 187 heterogeneous sessions are covered in detail in [8] and are not 188 repeated. In summary, heterogeneity occurs when receivers request 189 different levels of QoS within a single session and also when some 190 receivers do not request any QoS. Both types of heterogeneity are 191 shown in figure 3. 193 +----+ 194 +------> | R1 | 195 | +----+ 196 | 197 | +----+ 198 +-----+ -----+ +--> | R2 | 199 | | ---------+ +----+ Receiver Request Types: 200 | Src | ----> QoS 1 and QoS 2 201 | | .........+ +----+ ....> Best-Effort 202 +-----+ .....+ +..> | R3 | 203 : +----+ 204 /\ : 205 || : +----+ 206 || +......> | R4 | 207 || +----+ 208 Single 209 IP Mulicast 210 Group 212 Figure 3: Types of Multicast Receivers 214 [8] provides four models for dealing with heterogeneity: full 215 heterogeneity, limited heterogeneity, homogeneous, and modified 216 homogeneous models. The key issue to be addressed by an 217 implementation is providing requested QoS downstream. One of or 218 some combination of the discussed models [8] may be used to 219 provide requested QoS. Unfortunately, none of the described 220 models is the right answer for all cases. For some networks, e.g. 221 public WANs, it is likely that the limited heterogeneous model or 222 a hybrid limited-full heterogeneous model will be desired. In 223 other networks, e.g. LANs, it is likely that a the modified 224 homogeneous model will be desired. 226 Since there is not one model that satisfies all cases, 227 implementations SHOULD implement one of either the limited 228 heterogeneity model or the modified homogeneous model. 229 Implementations SHOULD support both approaches and provide the 230 ability to select which method is actually used, but are not 231 required to do so. 233 3. Security 235 The same considerations stated in [7] and [10] apply to this 236 document. There are no additional security issues raised in this 237 document. 239 4. Acknowledgments 241 This work is based on earlier drafts [2,4] and comments from the 242 ISSLL working group. The author would like to acknowledge their 243 contribution, most notably Steve Berson who coauthored [4]. 245 5. Author's Address 247 Lou Berger 248 FORE Systems 249 6905 Rockledge Drive 250 Suite 800 251 Bethesda, MD 20817 253 Phone: +1 301 571 2534 254 EMail: lberger@fore.com 256 REFERENCES 258 [1] The ATM Forum, "MPOA Baseline Version 1", May 1997. 260 [2] Berger, L., "RSVP over ATM: Framework and UNI3.0/3.1 Method", 261 Internet Draft, June 1996. 263 [3] Berger, L., "RSVP over ATM Implementation Requirements, Internet 264 Draft, July 1997. 266 [4] Berson, S., Berger, L., "IP Integrated Services with RSVP over ATM," 267 Internet Draft, draft-ietf-issll-atm-support-02.txt, November 1996. 269 [5] Borden, M., Crawley, E., Krawczyk, J, Baker, F., and Berson, S., 270 "Issues for RSVP and Integrated Services over ATM," Internet Draft, 271 February 1996. 273 [6] Borden, M., and Garrett, M., "Interoperation of Controlled-Load and 274 Guaranteed-Service with ATM," Internet Draft, March 1997. 276 [7] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., 277 "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 278 Specification," Internet Draft, June 1997. 280 [8] Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M., and 281 Krawczyk, J, "Issues for Integrated Services and RSVP over ATM," 282 Internet Draft, July 1997. 284 [9] Luciani, J., Katz, D., Piscitello, D., Cole, B., "NBMA Next Hop 285 Resolution Protocol (NHRP)," Internet Draft, January 1997. 287 [10] Perez, M., Liaw, F., Grossman, D., Mankin, A., Hoffman, E., and 288 Malis, A., "ATM Signalling Support for IP over ATM," RFC 1755.