Internet Draft Internet-Draft Grenville Armitage Lucent Technologies July 10th, 1997 Using the MARS model in non-ATM NBMA networks. <draft-armitage-ion-mars-nbma-02.txt> Status of this Memo This document was submitted to the IETF Internetworking over NBMA (ION) Working Group. It is intended for consideration as an INFORMATIONAL RFC. Publication of this document does not imply acceptance by the ION WG of any ideas expressed within. Comments should be submitted to the ion@nexen.com mailing list. Distribution of this memo is unlimited. This memo is an internet draft. 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. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress". Please check the lid-abstracts.txt listing contained in the internet-drafts shadow directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim) to learn the current status of any Internet Draft. Abstract Initially developed for IP over ATM, the RFC2022 (MARS) model is also applicable to other NBMA networks that provide the equivalent of switched, point to multipoint connections. This short document is intended to state the obvious equivalences, and explain the less obvious implications. No changes to the MARS model per se are suggested or required. RFC2022 is not required over NBMA networks that offer Ethernet-like group addressing functionality. Armitage Expires January 10th, 1998 [Page 1] Internet Draft <draft-armitage-ion-mars-nbma-02.txt> July 10th, 1997 1. Introduction Most network layer models, like the one described in RFC 1112 [1] for IP multicasting, assume sources may send their packets to an abstract 'multicast group addresses'. Link layer support for such an abstraction is assumed to exist, and is provided by technologies such as Ethernet. Some NBMA networks (e.g. ATM using UNI3.0 or UNI3.1 signaling [4,5]) do not support a multicast (or group) address abstraction. In these environments multicasting is typically supported through point to multipoint calls (or emulated with multiple point to point calls). The MARS model (RFC2022) [2] was originally developed by the IP over ATM working group, and so uses ATM-centric descriptive language. For completeness this memo explains how RFC2022 can be applied to other NBMA technologies. 2. RFC2022's basic assumptions. Section 3 of [2] describes the basic assumptions that the MARS model makes about the services available from the link layer network (using ATM as the specific case). In summary these are: The ATM model broadly describes an 'AAL User' as any entity that establishes and manages VCs and underlying AAL services to exchange data. An IP over ATM interface is a form of 'AAL User' The most fundamental limitations of UNI 3.0/3.1's multicast support are: Only point to multipoint, unidirectional VCs may be established. Only the root (source) node of a given VC may add or remove leaf nodes. Leaf nodes are identified by their unicast ATM addresses. Given this point to multipoint call service, the MARS document goes on to describe two architectures for emulating multipoint to multipoint IP multicasting - the VC Mesh, and the Multicast Server. In either case it was assumed that IP/ATM interfaces (whether in routers or hosts) are allowed to originate and manage outgoing point to multipoint calls without network operator intervention or manual provisioning. The MARS document also specifies that AAL5 be used for all SVCs, implying a requirement that the underlying link service supports the Armitage Expires January 10th, 1998 [Page 2] Internet Draft <draft-armitage-ion-mars-nbma-02.txt> July 10th, 1997 atomic exchange of PDUs. 3. Generalising the MARS model. Any NBMA service that offers an equivalent to (or superset of) the ATM point to multipoint call service can use the MARS model directly. It must be possible to transmit atomic data units bi-directionally with point to point calls, and unidirectionally (from root to leaves) on point to multipoint calls. A MARS is an entity known by its NBMA address. A MARS Client is an entity known by its NBMA address. An MCS (where needed) is an entity known by its NBMA address. The MARS control messages defined in sections 4 onwards of the MARS document are shown carrying ATM addresses. Using different mar$afn (Address Family) values in the fixed header of MARS control messages allows MARS entities to indicate they are carrying other types of NBMA addresses (as done in NHRP[3]). As for NHRP, the interpretation of the 'sub-address' fields shall be in the context of the address family selected (which means it will often simply be null). In all cases where {IP, ATM.1, ATM.2, ...} mappings are referred to, they may be interpreted as {IP, NBMA.1, NBMA.2, ...} in the context of whatever NBMA network you are deploying MARS. The MARS Cluster is defined in [2] as: The set of ATM interfaces chosing to participate in direct ATM connections to achieve multicasting of AAL_SDUs between themselves. It is trivial to observe that the cluster definition is independent of the underlying link layer technology. A revised definition becomes: The set of NBMA interfaces chosing to participate in direct NBMA connections to achieve multicasting of packets between themselves. The term 'Cluster Member' continues to refer to an endpoint that is currently using a specific MARS for multicast support. The potential scope of a cluster may be the entire membership of a LIS, while the actual scope of a cluster depends on which LIS members are actually registered with the cluster's MARS at any given time. Section 3.4 of [2] provided a set of mneumonics for the signalling Armitage Expires January 10th, 1998 [Page 3] Internet Draft <draft-armitage-ion-mars-nbma-02.txt> July 10th, 1997 functions available to AAL Users. These mneumonics are then used in the remainder of [2] to indicate link layer events to which MARS entities might react. Recast from the perspective of an NBMA based MARS entity, the descriptions would now read: The following generic signalling functions are presumed to be available to local MARS entities: L_CALL_RQ Establish a pt-pt call to a specific endpoint. L_MULTI_RQ Establish pt-mpt call to a specific endpoint. L_MULTI_ADD Add new leaf node to previously established pt-mpt call. L_MULTI_DROP Remove specific leaf node from established pt-mpt call. L_RELEASE Release pt-pt call, or all Leaves of a pt-mpt call. The signalling exchanges and local information passed between MARS entity and NBMA signalling entity with these functions are outside the scope of this document. The following indications are assumed to be available to MARS entities, generated by by the local NBMA signalling entity: L_ACK Succesful completion of a local request. L_REMOTE_CALL A new call has been established to the MARS entity. ERR_L_RQFAILED A remote NBMA endpoint rejected an L_CALL_RQ, L_MULTI_RQ, or L_MULTI_ADD. ERR_L_DROP A remote NBMA endpoint dropped off an existing call. ERR_L_RELEASE An existing call was terminated. The signalling exchanges and local information passed between MARS entity and NBMA signalling entity with these functions are outside the scope of this document. 4. Open Issues. The trade offs between VC Mesh and Multicast Server modes may look quite different for each NBMA technology. This will be especially true in the area of VC (or equivalent) resource consumption in the NICs of hosts, routers, and endpoints supporting MARSs or MCSs. The use of VC mesh mode is most vulnerable to NBMA technologies that are signalling intensive or resource challenged. Sizing of Clusters (and hence LISes) will also be affected by a given NBMA network's ability to support lots of pt-mpt calls. Additionally, you cannot have more members in a cluster than you can Armitage Expires January 10th, 1998 [Page 4] Internet Draft <draft-armitage-ion-mars-nbma-02.txt> July 10th, 1997 have leaf nodes on a pt-mpt call, without hacking the MARS model [6]. On going developments in server synchronisation protocols for distributed RFC2022 implementations are expected to be applicable to non-ATM NBMA networks. Quality of service considerations are outside the scope of this document. They will be very specific to each NBMA technology's capabilities. Related work is being pursued outside the ION Working Group. If the NBMA network offers some sort of native multipoint to multipoint service then use of the MARS model may not be optimal. Such situations require further analysis. Security Consideration This memo is informational, and specifies no protocol for deployment. No specific non-ATM NBMA network technologies or security characteristics are discussed. Should enhancements to security be required, they shall be added as an extension to the base architecture in RFC 2022, or described in documents explicitly proposing use of RFC 2022 over specific NBMA technologies. Acknowledgments This draft was substantially developed while the author was with Bell Communications Research (Bellcore). Author's Address Grenville Armitage Bell Laboratories, Lucent Technologies. 101 Crawfords Corner Rd, Holmdel, NJ, 07733 USA Email: gja@lucent.com References [1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112, Stanford University, August 1989. Armitage Expires January 10th, 1998 [Page 5] Internet Draft <draft-armitage-ion-mars-nbma-02.txt> July 10th, 1997 [2] G.J. Armitage, "Support for Multicast over UNI 3.0/3.1 based ATM Networks.", Bellcore, RFC 2022, Bellcore, November 1996. [3] J. Luciani, et al, "NBMA Next Hop Resolution Protocol (NHRP)", INTERNET DRAFT, draft-ietf-rolc-nhrp-11.txt, March 1997. [4] ATM Forum, "ATM User-Network Interface Specification Version 3.0", Englewood Cliffs, NJ: Prentice Hall, September 1993. [5] ATM Forum, "ATM User Network Interface (UNI) Specification Version 3.1", ISBN 0-13-393828-X, Prentice Hall, Englewood Cliffs, NJ, June 1995. [6] G. Armitage, "Issues affecting MARS Cluster Size", Bellcore, RFC 2121, March 1997. Armitage Expires January 10th, 1998 [Page 6]