idnits 2.17.1 draft-armitage-ion-mars-nbma-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 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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. == Outdated reference: A later version (-14) exists of draft-ietf-rolc-nhrp-07 Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft Grenville Armitage 2 Bellcore 3 May 23rd, 1996 5 Using the MARS model in non-ATM NBMA networks. 6 8 Status of this Memo 10 This document was submitted to the IETF IP over NBMA WG. Publication 11 of this document does not imply acceptance by the IP over NBMA WG of 12 any ideas expressed within. Comments should be submitted to the 13 ion@nexen.com mailing list. 15 Distribution of this memo is unlimited. 17 This memo is an internet draft. Internet Drafts are working documents 18 of the Internet Engineering Task Force (IETF), its Areas, and its 19 Working Groups. Note that other groups may also distribute working 20 documents as Internet Drafts. 22 Internet Drafts are draft documents valid for a maximum of six 23 months. Internet Drafts may be updated, replaced, or obsoleted by 24 other documents at any time. It is not appropriate to use Internet 25 Drafts as reference material or to cite them other than as a "working 26 draft" or "work in progress". 28 Please check the lid-abstracts.txt listing contained in the 29 internet-drafts shadow directories on ds.internic.net (US East 30 Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or 31 munnari.oz.au (Pacific Rim) to learn the current status of any 32 Internet Draft. 34 Abstract 36 The MARS model developed by the IP over ATM working group is also 37 applicable to other NBMA networks that provide the equivalent of 38 switched, point to multipoint connections. This short document is 39 intended to state the obvious equivalences, and explain the less 40 obvious implications. No changes to the MARS model per se are 41 suggested or required. The MARS model is not required for NBMA 42 networks that offer a link level group addressing service that maps 43 directly onto the IP multicast model. 45 This document is informational, and may influence the development of 46 MARSv2/NHRPv2 in line with the new ION charter and 'goals and 47 milestones' timeline. 49 1. Introduction. 51 Most network layer models, like the one described in RFC 1112 [1] for 52 IP multicasting, assume sources may send their packets to an abstract 53 'multicast group addresses'. Link layer support for such an 54 abstraction is assumed to exist, and is provided by technologies such 55 as Ethernet. 57 Some NBMA networks (e.g. ATM) do not support a multicast (or group) 58 address abstraction. In these environments multicasting is supported 59 through point to multipoint calls. The MARS model [2] was originally 60 developed by the IP over ATM working group. For completeness this 61 memo explains how the MARS model and protocol can be applied to other 62 NBMA technologies that offer similar, limited multicast support. 64 2. The MARS model's basic assumptions. 66 Section 3 of [2] describes the basic assumptions that the MARS model 67 makes about the services available from the (ATM) link layer network. 68 In summary (from the intro to section 3), these were: 70 The ATM model broadly describes an 'AAL User' as any entity that 71 establishes and manages VCs and underlying AAL services to 72 exchange data. An IP over ATM interface is a form of 'AAL User' 73 (although the default LLC/SNAP encapsulation mode specified in 74 RFC1755 really requires that an 'LLC entity' is the AAL User, 75 which in turn supports the IP/ATM interface). 77 The most fundamental limitations of UNI 3.0/3.1's multicast 78 support are: 80 Only point to multipoint, unidirectional VCs may be 81 established. 83 Only the root (source) node of a given VC may add or remove 84 leaf nodes. 86 Leaf nodes are identified by their unicast ATM addresses. 88 Given this point to multipoint call service, the MARS document goes 89 on to describe two architectures for emulating multipoint to 90 multipoint IP multicasting - the VC Mesh, and the Multicast Server. 91 In either case it was assumed that IP/ATM interfaces (whether in 92 routers or hosts) are allowed to originate and manage outgoing point 93 to multipoint calls without network operator intervention or manual 94 provisioning. 96 The MARS document also specifies that AAL5 be used for all SVCs, 97 implying a requirement that the underlying link service supports the 98 atomic exchange of PDUs. 100 3. Generalising the MARS model. 102 Any NBMA service that offers an equivalent to (or superset of) the 103 ATM point to multipoint call service can use the MARS model directly. 104 It must be possible to transmit atomic data units bi-directionally 105 with point to point calls, and unidirectionally (from root to leaves) 106 on point to multipoint calls. 108 A MARS is simply an entity with an NBMA address. 110 A MARS Client is simply an entity with an NBMA address. 112 An MCS (where needed) is simply an entity with an NBMA address. 114 The MARS control messages defined in sections 4 onwards of the MARS 115 document are shown carrying ATM addresses. Using different mar$afn 116 (Address Family) values in the fixed header of MARS control messages 117 allows MARS entities to indicate they are carrying other types of 118 'hardware' addresses. In a manner analagous to that described in NHRP 119 [3], the interpretation of the 'sub-address' fields shall be in the 120 context of the address family selected (which means it will often 121 simply be null). 123 In all cases where {IP, ATM.1, ATM.2, ...} mappings are referred to, 124 they may be interpreted as {IP, NBMA.1, NBMA.2, ...} in the context 125 of whatever NBMA network you are deploying MARS. 127 The MARS Cluster is defined in [2] as: 129 The set of ATM interfaces chosing to participate in direct ATM 130 connections to achieve multicasting of AAL_SDUs between 131 themselves. 133 It is trivial to observe that the cluster definition is independent 134 of the underlying link layer technology. A revised definition 135 becomes: 137 The set of NBMA interfaces chosing to participate in direct NBMA 138 connections to achieve multicasting of packets between themselves. 140 This document does not provide any additional information on how to 141 safely build a cluster that spans IP unicast subnet boundaries, the 142 existing caveat that a Cluster == a LIS remains. 144 The term 'Cluster Member' continues to refer to an endpoint that is 145 currently using a MARS for multicast support. The potential scope of 146 a cluster may be the entire membership of a LIS, while the actual 147 scope of a cluster depends on which endpoints are actually cluster 148 members at any given time. 150 Section 3.4 of [2] provided a somewhat stylised set of mneumonics for 151 the signalling functions available to AAL Users. These mneumonics are 152 then used in the remainder of [2] to indicate link layer events to 153 which MARS entities might react. Recast from the perspective of an 154 NBMA based MARS entity, the descriptions would now read: 156 The following generic signalling functions are presumed to be 157 available to local MARS entities: 159 L_CALL_RQ Establish a pt-pt call to a specific endpoint. 160 L_MULTI_RQ Establish pt-mpt call to a specific endpoint. 161 L_MULTI_ADD Add new leaf node to previously established pt-mpt 162 call. 163 L_MULTI_DROP Remove specific leaf node from established pt-mpt 164 call. 165 L_RELEASE Release pt-pt call, or all Leaves of a pt-mpt call. 167 The signalling exchanges and local information passed between MARS 168 entity and NBMA signalling entity with these functions are outside 169 the scope of this document. 171 The following indications are assumed to be available to MARS 172 entities, generated by by the local NBMA signalling entity: 174 L_ACK Succesful completion of a local request. 175 L_REMOTE_CALL A new call has been established to the MARS 176 entity. 177 ERR_L_RQFAILED A remote NBMA endpoint rejected an L_CALL_RQ, 178 L_MULTI_RQ, or L_MULTI_ADD. 179 ERR_L_DROP A remote NBMA endpoint dropped off an existing 180 call. 181 ERR_L_RELEASE An existing call was terminated. 183 The signalling exchanges and local information passed between MARS 184 entity and NBMA signalling entity with these functions are outside 185 the scope of this document. 187 4. Open Issues. 189 The trade offs between VC Mesh and Multicast Server modes may look 190 quite different for each NBMA technology. This will be especially 191 true in the area of VC (or equivalent) resource consumption in the 192 NICs of hosts, routers, and endpoints supporting MARSs or MCSs. The 193 use of VC mesh mode is most vulnerable to NBMA technologies that are 194 signalling intensive or resource challenged. 196 Sizing of Clusters (and hence LISes) will also be affected by a given 197 NBMA network's ability to support lots of pt-mpt calls. 198 Additionally, you cannot have more members in a cluster than you can 199 have leaf nodes on a pt-mpt call, without hacking the MARS model 200 (e.g. because of ClusterControlVC). 202 On going developments in server synchronisation protocols for 203 redundant MARS and MCS entities are expected to be applicable to 204 non-ATM NBMA networks. 206 Quality of service considerations are outside the scope of this 207 document. They will be very specific to each NBMA technology's 208 capabilities. Look to the ISSLL working group for answers here. 210 If the NBMA network offers some sort of native multipoint to 211 multipoint service then use of the MARS model may not be optimal. 212 Such situations require further analysis. 214 Use of NBMA networks other than ATM does not imply that the problems 215 associated with 'cut through' for multicast have been solved. This is 216 still an open issue. 218 Security Consideration 220 Security consideration are not addressed in this document. 222 Acknowledgments 224 Author's Address 226 Grenville Armitage 227 Bellcore, 445 South Street 228 Morristown, NJ, 07960 229 USA 231 Email: gja@thumper.bellcore.com 232 Ph. +1 201 829 2635 234 References 236 [1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, 237 Stanford University, August 1989. 239 [2] G.J. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM 240 Networks.", Bellcore, INTERNET DRAFT, draft-ietf-ipatm-ipmc-12.txt, 241 February 1996 243 [3] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", 244 INTERNET DRAFT, draft-ietf-rolc-nhrp-07.txt, December 1995.