The IP over ATM Mailing List Archive by date[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Source ID - summary, opinion, and suggestion (long)
I've placed the following doc on the ipmc web page, and emailed
it here because its an open topic for the ipmc-07 conclusion.
It has 4 sections - Summary, Discussion, Opinion, and Suggestion.
cheers,
gja
_________________________________________________________________________
Grenville Armitage, Research Scientist, MRE 2P-255, 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
SOURCE ID:
My thoughts and biases. Comments, agreement, and contradictions
should be posted to the ip-atm WG email list for discussion,
since we need to reach closure on this asap.
Its a bit long, but take heart - I have suggested a way forward
at the end. I think its worth reading too, if only for the questions
I've raised (not too many answers, just questions).
gja
-------------------------------------------------------------------
Summary:
The progression of key ideas is:
- The use of ATM level multicast servers (MCS) in the AAL_SDU
forwarding path can result in copies of packets being reflected
back to their sources.
- Layer 3 mechanisms to identify reflections dont function reliably
when the AAL_SDU 'source' is a layer 3 mrouter forwarding into
a layer 3 multicast routing domain (aka LIS, or cluster in our
currentl model).
- ipcm-07 currently defines a 16 bit field carried along
with every multicasted packet, which uniquely identifies
one of 64k sources - Cluster Member ID (CMI).
- ipmc-07 currently assumes the CMI value is assigned
dynamically, and that its scope is restricted to
a single cluster.
- The receive-side behaviour of clients should be simple.
Currently if a packet arrives with your own CMI in it,
you silently discard the packet. Any other CMI value
will result in the packet being accepted and passed
up for appropriate layer 3 processing.
- There is a question of whether AAL_SDUs carrying multicast
packets may, in the future, be transmitted directly from
source logically associated with one cluster to a receiver
logically associated with another cluster, without going
through a Layer 3 mrouter. Termed "multicast cut through".
- If the answer to the previous question is "yes", the
immediate consequence is that the source and receiver
may have the same CMIs - resulting in failure to
communicate. Given this possibility, CMI allocation may
need to be:
- Synchronised to be unique across the possible
source/destination clusters, and/or
- Modified to use a much larger CMI space, or
- Globally unique CMI/sourceID values, statically
assigned. Globally unique ID will be 8 octets,
minimum, which MUST be carried per-packet.
- Alternatively, it is not clear that multicast cut through
is actually desirable, achievable, or necessary before
advances in ATM multicast support (e.g. group addressing,
leaf initiated joins, etc) provide an alternative path to
optimising IPmulticasting over ATM. In this case, ipmc-07
has no need to modify its existing CMI mechanism.
- A middle ground is to mandate that multicast cut through
in ipmc-07 based environments will only ever be applied when
there are NO MCS entities in the forwarding path between the
layer 3 source and destination. This ensures reflected packets
will not exist. If sources are able to identify such
circumstances they may set their CMI to 0 on outgoing
packets, ensuring the receivers will accept them.
Discussion:
The pivotal issue is how to resolve between the last 3 main
bullet points above. There are costs associated with the
sub-bullet points above - globally unique CMIs would require
more space in control plane messages (not too bad) _and_
data plane encapsulation overhead (not too good). Synchronising
the dynamic allocation of 16 bit CMIs across the affected
source/destination clusters requires additional inter-MARS protocols.
It also limits the total number of nodes that may participate in
multicast cut through to 64k, but requires no additional overhead
per packet in the data plane.
No mechanisms currently exist for multicast cut through. So, the
real question faced by the IP-ATM WG for the first release of
the MARS protocol is whether it is at all reasonable to 'plan for it'.
Equally important, assuming the previous point is answered "yes",
is then what sort of multicast cut through model will we likely
have, and therefore what do we specifically need to change in ipmc-07.
The compromise line is also worth exploring - what minimal set of
text do we need to add to ipmc-07 to prevent closing off future
options while allowing the first generation of MARS based clusters
to use minimal extended encapsulation.
Opinion: (mine - gja)
I'll say upfront (in case anyone has forgotten) that I believe
we will not develop a way to do unconstrained multicast cut through
for a long time. (The key here is 'unconstrained', because I can
come up with a number of 'constrained' cases that may be useful
and are quite adequately covered by a 16 bit CMI with inter-MARS
synchronisation of the CMI spaces.) By long time, I mean before
UNI4.0 based ATM signalling is being rolled out.
My fallback position is that we _may_ begin to consider the problem
tractable if we exclude MCSs from multicast cut through forwarding paths.
But as soon as we do that, we've deleted the source of reflected
packets. So, who needs a global CMI?
For the time being I'll simply bullet-point what I think multicast
cut through implies, and where the trouble spots are going to be
- In the 'classical' idmr model mrouters exist at the edges
of routing domains - aka subnets, or in our case the
LIS/cluster.
- Multicast cut through is about avoiding terminating
your pt-mpt VC on mrouters, but by-passing them and
terminating directly on the hosts within the domains
managed by the mrouters.
- The first problem faced by ipmc-07 is a mechanism for
sources to establish their pt-mpt VC forwarding path.
The ATM address of every group member you want to directly
communicate with must be passed to you. How do you
identify a practical scope for this initial information?
Currently this is bounded by the edges of your cluster.
(This is the MARS_REQUEST/MARS_MULTI phase.)
- Cutting through mrouters implies you have solved the question
of scoping - but how, and to where? Note that unlike unicast
cut through, there is no one single 'direction' (in the
layer 3 topological sense) in which your group members may
be found. (Note also that scoping is not just about 'do we
have a metric to measure it' but 'what resource consumption
is involved'.) Perhaps you follow the multicast routing
tables. How far, and what happens when you start to collect
more group members than you are allowed leaf nodes on a
pt to mpt VC (32k max)? How do you prioritise? (perhaps
you want real direct connection, but if you're running
out of allowable leaf nodes you'd be happy cutting through
part way - e.g. to the mrouter right of the edge of some
clusters containing the actual target group members.)
- The second problem faced by ipmc-07 is the management of
your pt-mpt VC to ensure that new group members you want
to directly communicate with is added, by you, as a leaf node.
(The propagation of MARS_JOIN/MARS_LEAVE on ClusterControlVC.)
- In reality the resolution of a cut-through MARS_REQUEST may
be the easy part. Having declared to the world that you're
interested in members of group X across all clusters
within some scope-metric of your cluster, YOU now need to track
membership changes of group X within each and every cluster
within your chosen scope. (You MUST, because having bypassed
the mrouters out of your local cluster, there's no way for
new remote cluster members to start receiving your traffic
any other way.) This means you'll be receiving MARS_JOIN/LEAVE
traffic from across all affected clusters - and we'll have
to create an inter-MARS mechanism for propagating this
information reliably, because the MARS Sequence Number
approach is hardly likely to work across cluster boundaries.
- Note further that while the previous bullet point might look
a bit like a problem already solved by IDMR, its actually
worse. IDMR can aggregate group membership information into
a message saying "yes, in this cluster there is now 1 or more
members, please route traffic for group X to me". We do not
have that luxury, since if you are managing your own VC you
need explicit knowledge of each and every group member in
the remote cluster.
- Another issue relating to the cross-cluster propagation
of group membership changes is how you _stop_ this information
being propagated into your cluster when no-one is a sender
to that group anymore. But how do you track the senders?
- On a milder note, there will be some interesting 'feature
interaction' with hop-count based IP level scoping ideas being
tossed around in IDMR. If there are multiple apps using the
same outgoing interface, sending to the same group X, but
explicitly specifying different TTLs, your cut through
will throw a spanner in the works. Why? Because your cut through
VC is an inclusive-OR of all group members within the scope-metric
you specific when establishing the VC. For arguments sake,
assume you specified the scope metric using IP level TTLs.
Assume further (and this may be a stretch) your driver new the
largest TTL required for any app sending to group X, and specified
it. Now packets transmitted with smaller TTLs will actually
reach destinations out to the largest TTL. Interesting.
Anyway, enough of those ramblings.
-------------------------------------------------------------------
Suggestion:
I have a suggestion for TWO distinct packet encapsulation mechanisms
that could be specified in ipmc-07, with text that allows one to be
used today (pre-multicast cut through), and the other to be used
in the future in a manner backward compatible with MARS clients built
before cut through was solved.
Format #1 is based on my October 12th synthesis of protocolID
discussion with James Watt (in another document):
[0xAA-AA-03][0x00-00-5E][0x00-01][Extended Layer 3 packet]
Format #2 has a new LLC/SNAP. MARS clients based on ipmc-07 must
be able to RECEIVE this format, but MUST NOT transmit using it:
[0xAA-AA-03][0x00-00-5E][0x00-04][Mega Extended Layer 3 packet]
The Mega Extended Layer 3 packet has the following formats:
If ar$pro.type != 0x80
[8 octet sourceID][ar$pro.type][Null pad][Layer 3 packet]
2octets 2octets
If ar$pro.type == 0x80
[8 octet sourceID][ar$pro.type][ar$pro.snap][Null pad][Layer 3 packet]
2octets 5octets 1octet
The [8 octet sourceID] field's contents can be left unspecified, provided
the following receive side algorithm is used by all ipmc-07 MARS clients:
An AAL_SDU arrives:
If format #1
check the CMI against your own,
and discard the packet if they match.
process packet according to pkt$pro field.
If format #2
If we have our own [8 octet sourceID]
{
check against [8 octet sourceID] in the AAL_SDU,
and discard packet if they match.
}
otherwise process packet according to ar$pro.type (and
optionally ar$pro.snap) field(s).
The logic here is that MARS based systems may be deployed before
we've figured out how to do cut through and what form a globally
unique source ID would look like. When we solve these problems,
we can define the sender behaviour required to generate format #2
packets.
Clients built prior to us solving those problems will simply ignore
the first 8 bytes of a format #2 extended header, but will know how
to process the packet nevertheless. Such clients have no need to detect
reflected format #2 packets, because by definition, they wont be
generating them.
The one assumption behind this scheme is that future multicast cut through
mechanisms will allow the sender to realise it should be sending
packets in format #2 rather than format #1. I think this is a reasonable
constraint to place on our future solution space.
-------------------------------------------------------------------
|
|