home *** CD-ROM | disk | FTP | other *** search
-
-
-
-
-
-
- Network Working Group G. Armitage
- Request for Comments: 2269 Lucent Technologies
- Category: Informational January 1998
-
-
- Using the MARS Model in non-ATM NBMA Networks
-
- Status of this Memo
-
- This memo provides information for the Internet community. It does
- not specify an Internet standard of any kind. Distribution of this
- memo is unlimited.
-
- Copyright Notice
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- Abstract
-
- Initially developed for IP over ATM, the RFC 2022 (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. RFC 2022 is not required over NBMA networks
- that offer Ethernet-like group addressing functionality.
-
- 1. Introduction
-
- Most network layer models, like the one described in STD 5, 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 (RFC 2022) [2] was originally developed by the IP over
- ATM working group, and so uses ATM-centric descriptive language. For
- completeness this memo explains how RFC 2022 can be applied to other
- NBMA technologies.
-
-
-
-
-
-
-
-
- Armitage Informational [Page 1]
-
- RFC 2269 MARS Model in non-ATM NBMA Networks January 1998
-
-
- 2. RFC 2022'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
- 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.
-
-
-
-
-
- Armitage Informational [Page 2]
-
- RFC 2269 MARS Model in non-ATM NBMA Networks January 1998
-
-
- 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
- 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.
-
-
-
- Armitage Informational [Page 3]
-
- RFC 2269 MARS Model in non-ATM NBMA Networks January 1998
-
-
- 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
- have leaf nodes on a pt-mpt call, without hacking the MARS model [6].
-
- On going developments in server synchronisation protocols for
- distributed RFC 2022 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.
-
-
-
-
-
- Armitage Informational [Page 4]
-
- RFC 2269 MARS Model in non-ATM NBMA Networks January 1998
-
-
- Security Considerations
-
- 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 memo 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] Deering, S., "Host Extensions for IP Multicasting", STD 5, RFC
- 1112, Stanford University, August 1989.
-
- [2] Armitage, G., "Support for Multicast over UNI 3.0/3.1 based ATM
- Networks.", RFC 2022, November 1996.
-
- [3] Luciani, J., et. al., "NBMA Next Hop Resolution Protocol (NHRP)",
- Work in Progress.
-
- [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] Armitage, G., "Issues affecting MARS Cluster Size", RFC 2121,
- March 1997.
-
-
-
-
-
-
-
- Armitage Informational [Page 5]
-
- RFC 2269 MARS Model in non-ATM NBMA Networks January 1998
-
-
- Full Copyright Statement
-
- Copyright (C) The Internet Society (1998). All Rights Reserved.
-
- This document and translations of it may be copied and furnished to
- others, and derivative works that comment on or otherwise explain it
- or assist in its implementation may be prepared, copied, published
- and distributed, in whole or in part, without restriction of any
- kind, provided that the above copyright notice and this paragraph are
- included on all such copies and derivative works. However, this
- document itself may not be modified in any way, such as by removing
- the copyright notice or references to the Internet Society or other
- Internet organizations, except as needed for the purpose of
- developing Internet standards in which case the procedures for
- copyrights defined in the Internet Standards process must be
- followed, or as required to translate it into languages other than
- English.
-
- The limited permissions granted above are perpetual and will not be
- revoked by the Internet Society or its successors or assigns.
-
- This document and the information contained herein is provided on an
- "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
- TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
- BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
- HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
- MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Armitage Informational [Page 6]
-
-