Subject: [Diffserv] Model draft - sharing elements on multiple interfaces

From: Andrew Smith <[email-masked]>
Date: Tue, 05 Dec 2000 12:11:09 -0800

This is a proposal for a solution to the second issue in my earlier message
Ref: http://www.ietf.org/internet-drafts/draft-ietf-diffserv-model-05.txt

2. Sharing of elements amongst multiple interfaces.

Bob Moore has made a good point: right now the model describes everything that 
happens to a packet as it arrives on ingress to *an* interface, then it goes 
through a routing core, then it describes what happens on egress from *an* 
interface. The problem is that there are very valid scenarios (and 
implementation architectures too, although that's not really our problem here) 
where you want traffic streams from multiple ingress interfaces to receive 
shared processing before they get to the switch fabric. Ditto for a stream on 
egress to receive some diffserv processing before being split out to its final 
egress interface. This is a fairly fundamental ommission and I don't think it 
can be tackled by hand-waving. So we should choose whether to support it 
explicitly or not.

To support it, I think we need a modified top-level diagram that shows that you 
may repeat the routing core and subsequent "interface" blocks multiple times. 
The current figure 2 implies that you may have only one "ingress interface 
block" and one "egress interface block" per interface (the blocks are the dotted 
boxes in the figure). I believe we would need an additional "routing core" of 
some sort in between the first per-interface block and any subsequent 
shared-multi-interface block in order to express the interconnections (similar 
for egress). Do we then need arbitrary concatenations of such blocks or does 2 
on ingress and 2 on egress of each suffice?

I'm too lazy to draw the real picture right now (a real ASCII-art challenge to 
do it in only 72 columns) but it's something like this: right now we have one 
direction, the top half, of figure 2 as:

-> I -> core -> E ->

The proposal would be to modify this to something like:

-> I -+-> I -> core -> E -+-> E ->
       |                   |
-> I -+                   +-> E ->

Where "I" represents an Ingress block and "E" represents an Egress block. And 
you could represent the merge/split functions as additional routing cores 
(albeit simplified ones, still out of scope for this model: maybe this would be 
a use for those under-utilised Multiplexor and Demultiplexor elements but they'd 
have to be redefined so that their scope could span multiple interfaces - right 
now all elements are implicitly instantiated per-interface in this model).

[I don't know if this solves Bob's issue or not - hopefully he'll let us know.]

Andrew Smith
(editor of this draft)

_______________________________________________
diffserv mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/diffserv
Archive: http://www2.ietf.org/mail-archive/working-groups/diffserv/current/maillist.html

---

From: Keith McCloghrie <[email-masked]>
Date: Tue, 5 Dec 2000 12:54:50 -0800 (PST)

I think the DiffServ MIB is only just use-able at the moment due to
its surfeit of complexity, and I suggest that incorporating the below
into the model and thus reflecting it into the MIB will push the MIB
over the "cliff" to become of no use to anybody.

Keith.