The IP over ATM Mailing List Archive by date

[Grenville Armitage <gja@thumper.bellcore.com>]

Mark,

Thought I'd post a summary of where I think we are at regarding
the evolution of ipmc-07.

Re-arranging a bit from your post 10 days ago:
	[..]
>>2. In parallel to the above, the issue(s) regarding ATM Forum MPOA
>>leverage of the MARS work and the use of protocol id's and source id's
>>in the control and data planes and cut-through issues will be resolved
>>and brought to the WG for consensus.

Barring further disagreement I think we now have suitable solutions
to the ProtocolID and SourceID issues (based on what I posted Oct.12th).
The protocol ID mechanism allows for SNAP based protocols to be
represented, while collapsing the per-packet overhead to the smallest
possible when Ethertype based protocols such as IPv4 and IPv6 are being
carried. The source ID problem is resolved using a receive side
parsing rule that will allow MARS clients built now to cope with
and receive 'cut through' traffic, without forcing us to define
and always use a larger sourceID.


>>1. Word-smithing work will be done to promote better clarity and to
>>fix perceived ambiguities. Grenville requests that if you have comments,
>>please also provide sample replacement text.
	[..]
>>Also, there has been some informational text prepared by Jim Rubas at
>>IBM which details some pseudo code

The pseudo-code, along with explicit clarifications requested during
the ipmc-07 Last Call, will go a long way to producing an
implementable spec. As Joel noted, the main text reads a bit more
like a book than a pure spec - I think adding Jim's pseudo-code
as an Appendix should satisfy the need for a more formal definition
of the protocol to exist somewhere in the document.

(http://gump.bellcore.com:8000/~gja/ipatm-ipmc/specific-diffs-07)

>>If there are any other issues, please bring them up now rather than
>>waiting for the above work to be completed.

Joel and James raised the issue of confusion between client behaviour
in the MCS and Mesh cases. The problem arises in the reader's mind
when they expect a complicated difference, but are left to infer
that there is, in fact, no difference in the client's behaviour for
each case. This can be solved trivially by making an explicit statement
of this fact in section 5, and modifying some early text in 5.1.

My explicit text changes are:

_________________________________________________________________________
Section 5, last paragraph:

   Most of this specification is concerned with managing and
   distributing information that allows the establishment of VCs for
   actually carrying layer 3 data packets. The actual format of the data
   carried on these VCs is almost completely outside the scope of this
   specification.  However, when using MCSs (described in section 3)
   endpoints need to filter out the reflected packets that can occur.
   The solution to this problem in a general way requires the use of
   additional per-packet encapsulation. This is discussed in section 5.5

Replaced with:

   The majority of this document covers the distribution of information
   allowing endpoints to establish and manage outgoing point to
   multipoint VCs - the forwarding paths for multicast traffic to
   particular multicast groups. The actual format of the AAL_SDUs
   sent on these VCs is almost completely outside the scope of this
   specification.  However, endpoints are not expected to know whether
   their forwarding path leads directly to a multicast group's members
   or to an MCS (described in section 3). This requires additional
   per-packet encapsulation (described in section 5.5) to aid in the
   the detection of reflected AAL_SDUs.
_________________________________________________________________________

_________________________________________________________________________
Section 5.1, 2nd & 3rd paragraph:

   When a packet arrives for transmission, and there is no outgoing VC
   already marked as serving the packet's multicast destination address,
   the MARS is queried for the set of ATM endpoints currently making up
   the multicast group.

   The query is executed by issuing a MARS_REQUEST.  The reply from the
   MARS may take one of two forms:

      MARS_MULTI - Sequence of MARS_MULTI messages returning the set of
                   ATM endpoints that are to be leaf nodes of the
                   outgoing VC.

Replaced with:

   When a local Layer 3 entity passes down a packet for transmission,
   the endpoint first ascertains whether an outbound path to the
   destination multicast group already exists. If it does not, the MARS
   is queried for a set of ATM endpoints that represent an appropriate
   forwarding path. (The ATM endpoints may represent the actual group
   members within the cluster, or a set of one or more MCSs. The
   endpoint does not distinguish between either case. Section 6.2
   describes the MARS behaviour that leads to MCSs being supplied
   as the forwarding path for a multicast group.)

   The query is executed by issuing a MARS_REQUEST.  The reply from the
   MARS may take one of two forms:

      MARS_MULTI - Sequence of MARS_MULTI messages returning the set of
                   ATM endpoints that are to be leaf nodes of an
                   outgoing point to multipoint VC (the forwarding path).
_________________________________________________________________________


I'm contemplating restructuring Section 6 (where there is perhaps
the most lack of clarity), but specific text from others would
be helpful.

Do we want an ipmc-08 out soon? I could do it by Wednesday based on
the diffs as they currently stand (and the ProtocolID/SourceID solution
I posted last week).

cheers,
gja
_________________________________________________________________________
Grenville Armitage, Research Scientist,      MRE 1G234B, 445 South Street
Internetworking Research Group, Bellcore.      Morristown, NJ, 07960, USA
(email) gja@thumper.bellcore.com  (voice) +1 201 829 2635 {.. 2504 (fax)}
        (www) http://gump.bellcore.com:8000/~gja/home.html