One document matched: draft-armitage-ion-mars-nbma-01.txt

Differences from draft-armitage-ion-mars-nbma-00.txt

Internet-Draft                                      Grenville Armitage
                                                              Bellcore
                                                   November 26th, 1996


             Using the MARS model in non-ATM NBMA networks.
                 <draft-armitage-ion-mars-nbma-01.txt>


Status of this Memo

   This document was submitted to the IETF Internetworking over NBMA
   (ION) Working Group. 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

   The MARS model developed by the IP over ATM working group 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. The MARS model is not required for NBMA
   networks that offer a link level group addressing service that maps
   directly onto the IP multicast model.

   This document is informational, and may influence the development of
   MARSv2/NHRPv2 in line with the new ION charter and 'goals and



Armitage                 Expires May 26th, 1997                  [Page 1]

Internet Draft     <draft-armitage-ion-mars-nbma-01> November 26th, 1996


   milestones' timeline.

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) do not support a multicast (or group)
   address abstraction. In these environments multicasting is usually
   supported through point to multipoint calls (or emulated with
   multiple point to point calls).  The MARS model [2] was originally
   developed by the IP over ATM working group.  For completeness this
   memo explains how the MARS model and protocol can be applied to other
   NBMA technologies that offer similar, limited multicast support.

2.  The MARS model'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 (from the intro to section 3),
   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'
      (although the default LLC/SNAP encapsulation mode specified in
      RFC1755 really requires that an 'LLC entity' is the AAL User,
      which in turn supports the IP/ATM interface).

      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



Armitage                 Expires May 26th, 1997                  [Page 2]

Internet Draft     <draft-armitage-ion-mars-nbma-01> November 26th, 1996


   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 simply an entity with an NBMA address.

   A MARS Client is simply an entity with an NBMA address.

   An MCS (where needed) is simply an entity with an 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 for 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.

   This document does not provide any additional information on how to
   safely build a cluster that spans IP unicast subnet boundaries. The



Armitage                 Expires May 26th, 1997                  [Page 3]

Internet Draft     <draft-armitage-ion-mars-nbma-01> November 26th, 1996


   existing caveat that a Cluster == a LIS remains unchanged.

   The term 'Cluster Member' continues to refer to an endpoint that is
   currently using a 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 endpoints are actually cluster
   members at any given time.

   Section 3.4 of [2] provided a somewhat stylised 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.

      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.







Armitage                 Expires May 26th, 1997                  [Page 4]

Internet Draft     <draft-armitage-ion-mars-nbma-01> November 26th, 1996


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
   (e.g. because of ClusterControlVC).

   On going developments in server synchronisation protocols for
   redundant MARS and MCS entities 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. Look to the ISSLL working group for answers here.

   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.

   Use of NBMA networks other than ATM does not imply that the problems
   associated with multicast 'short cuts' have been solved. This is
   still an open issue.



Security Consideration

   Security consideration are not addressed in this document.

Acknowledgments



Author's Address

   Grenville Armitage
   Bellcore, 445 South Street
   Morristown, NJ, 07960
   USA




Armitage                 Expires May 26th, 1997                  [Page 5]

Internet Draft     <draft-armitage-ion-mars-nbma-01> November 26th, 1996


   Email: gja@bellcore.com


References
   [1] S. Deering, "Host Extensions for IP Multicasting", RFC 1112,
   Stanford University, August 1989.

   [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-10.txt, October 1996.







































Armitage                 Expires May 26th, 1997                  [Page 6]