doc: Add RFC documents

1 files changed, 339 insertions, 0 deletions

diff --git a/doc/rfc/rfc2269.txt b/doc/rfc/rfc2269.txt
new file mode 100644
index 0000000..687bf53
--- /dev/null
+++ b/doc/rfc/rfc2269.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+