Subject: [Hubmib] WIS ifStack issue

From: "C. M. Heard" <[email-masked]>
Date: Mon, 3 Dec 2001 15:09:53 -0800 (PST)

On Fri, 2 Nov 2001, Ayers, Mike wrote:
> 	I have an issue, which I shall call "the ifStack issue", but I do
> not want the publication of draft-ietf-hubmib-wis-mib-01.txt to wait on it.
> The changes to the draft that may ensue due to the resolution of this issue
> are relatively minor in both a relative and an absoulute sense, and it is
> best to have the discussion in reference to the current work.
> 
> 	The only reason for this delay is my current level of activity.
> I'll get the overview of the issue out ASAP.

Mike's workload is still rather high, and he's asked me to help out.  The
issue in question was first raised in an e-mail message from Mike to the
WIS MIB design team mailing list on Wed, 17 Oct 2001:

> 	The current interface stacking model does not have a layer between
> ethernetCsmacd and sonetPath.  This implies that the current WIS is the only
> way that ethernet will be sent over SONET.  This implication is already
> wrong (EoS).  I think we need a new ifType, say ethernet64-66bWIS, to
> indicate the adaptation layer in use.

Here EoS refers to the Ethernet over SONET mappings being standardized
in T1X1.5 and similar proposals in the ITU for SDH.  The concern is not
that we need to deal with these alternative payload mappings in the
WIS MIB -- we don't -- but rather that the ETHER-WIS layering model
should not be designed to exclude such mappings.

It was my contention that alternative Ethernet over SONET payload
could be accomodated without changing the layering model by using
ifMauType/ifMauDefaultType values _other than_ dot3MauType10GigBaseW,
dot3MauType10GigBaseEW, dot3MauType10GigBaseLW, and
dot3MauType10GigBaseSW to represent them. 

The design team decided to let the WGs at large debate this issue,
and it's one of the items we hope to discuss at the joint Hubmib
and AToMMIB meeting.  Relevant e-mail messages that appeared on the
design team mailing list are attached to provide some background for
the general discussion.

Regards,

Mike H.

Subject: Re: draft-wis-design-team-etherwis-01.txt
From: John Flick <[email-masked]>
To: "C. M. Heard" <[email-masked]>
Cc: "Ayers, Mike" <[email-masked]>, "Norseth, KC" <[email-masked]>, Kerry McDonald <[email-masked]>, Kaj Tesink <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 17 Oct 2001 16:23:42 -0700

"C. M. Heard" wrote:
> 
> On Wed, 17 Oct 2001, Ayers, Mike wrote:
> 
> >       (2) sec 3.4.1:
> >
> >       The current interface stacking model does not have a layer between
> > ethernetCsmacd and sonetPath.  This implies that the current WIS is the only
> > way that ethernet will be sent over SONET.  This implication is already
> > wrong (EoS).  I think we need a new ifType, say ethernet64-66bWIS, to
> > indicate the adaptation layer in use.
> 
> I assume that by EoS you mean the Ethernet over SONET mapping(s) being
> discussed in T1X1.5 for inclusion in an update to the ANSI SONET standard
> T1.105 (and similar proposals in the ITU for SDH).
> 
> This is a good point, but the I think the place to fix it is not in
> the ifType value but rather in the ifMauType/ifMauDefaultType value.
> That, at least, is what draft-ietf-hubmib-etherif-mib-v3-00.txt
> (EthernetLike-MIB) Section 3.2.4 seems to require:
> 
>    This MIB applies to interfaces which have the ifType value
>    ethernetCsmacd(6).  It is REQUIRED that all ethernet-like interfaces
>    use an ifType of ethernetCsmacd(6) regardless of the speed that the
>    interface is running or the link-layer encapsulation in use.  Use of
>    the ifType values iso88023Csmacd(7) and starLan(11) are deprecated,
>    however some older implementations may return these values.
>    Management applications should be prepared to receive these
>    deprecated ifType values from older implementations.
> 
>    There are three other interface types defined in the IANAifType-MIB
>    for Ethernet.  They are fastEther(62), fastEtherFX(69), and
>    gigabitEthernet(117).  These interface types were registered by
>    individual vendors, not by any IETF working group.  A requirement for
>    compliance with this document is that all ethernet-like interfaces
>    MUST return ethernetCsmacd(6) for ifType, and MUST NOT return
>    fastEther(62), fastEtherFX(69), or gigabitEthernet(117).  However, as
>    there are fielded implementations that do return these obsolete
>    ifType values, management applications SHOULD be prepared to receive
>    them from older implementations.
> 
>    Information on the particular flavor of Ethernet that an interface is
>    running is available from ifSpeed in the Interfaces MIB, and
>    ifMauType in the 802.3 MAU MIB [30].  Note that implementation of the
>    802.3 MAU MIB [30] is REQUIRED for all ethernet-like interfaces.
> 
> Note that the WIS exists if, and only if, a 10GBASE-W PHY is present.  That,
> in turn, is the case if, and only if, ifMauType and ifMauDefaultType have
> one of the following values (see draft-ietf-hubmib-mau-mib-v3-00.txt):
> 
>        dot3MauType10GigBaseW
>        dot3MauType10GigBaseEW
>        dot3MauType10GigBaseLW
>        dot3MauType10GigBaseSW
> 
> and Section 3 of the ETHER-WIS draft explicitly states that it applies
> only to interfaces employing 10GBASE-W PHYs.
> 
> Now, if some end-point system has an EoS interface, then by definition
> it does not contain a 10GBASE-W PHY, it contains something else. In
> that case ifMauType/ifMauDefaultType should indicate this by returning
> a value (to be defined) other than those above .  The EoS ifMauType
> values should be assigned so that there is no ambiguity about the type
> of payload mapping being used.
> 
> If you disagree with this, and still think that a new ifType value is
> needed, then it probably needs to be discussed in the larger context
> of the Hubmib WG as a modification to the EthernetLike-MIB.  In that
> case may I suggest that we proceed with the layering model as it is
> now written, and raise the issue when the design team makes its
> submission to the WG?

Using a new ifType has several problems, particularly on an interface
that is capable of either 10GigBaseR or 10GigBaseW.  Using a new ifType
would mean changing the ifType when reconfiguring between these two
MAU types.  Changing the ifType of an existing interface is not allowed
by the IF-MIB.  You would need to delete the old interface and create a
new one with a new ifIndex.  (Of course, changing between R and W on the
fly will probably not be a very common thing to do, but I still think
a new ifType is not where we want to go.)  I agree with Mike Heard that
this would be better represented as a new ifMauType.

John

Subject: RE: draft-wis-design-team-etherwis-01.txt
From: "Ayers, Mike" <[email-masked]>
To: "'John Flick'" <[email-masked]>, "C. M. Heard" <[email-masked]>
Cc: "Ayers, Mike" <[email-masked]>, "Norseth, KC" <[email-masked]>, Kerry McDonald <[email-masked]>, Kaj Tesink <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 17 Oct 2001 19:17:35 -0500

> From: John Flick [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2001 04:24 PM

> Using a new ifType has several problems, particularly on an interface
> that is capable of either 10GigBaseR or 10GigBaseW.  Using a 
> new ifType
> would mean changing the ifType when reconfiguring between these two
> MAU types.  Changing the ifType of an existing interface is 
> not allowed
> by the IF-MIB.  You would need to delete the old interface 
> and create a
> new one with a new ifIndex.  (Of course, changing between R 
> and W on the
> fly will probably not be a very common thing to do, but I still think
> a new ifType is not where we want to go.)  I agree with Mike 
> Heard that
> this would be better represented as a new ifMauType.

	I think my proposal was misunderstood.  I wanted the ifStack to
change from:

	sonet
	sonetPath
	ethernetCsmacd

in R mode to:

	sonet
	sonetPath
	ethernet64-66bWIS
	ethernetCsmacd

in W mode.  The idea is to handle this situation:

	    +-----+                      +-----+
	    |  A  |                      |  B  |
	    +-----+                      +-----+
	       ^                            ^
	       |      +---------------+     |
	       |      |               |     |
	       +----->|- +  -  -  -  -|<----+
	              |               |
	              |  |   BFR      |
	              |               |
	       +----->|- +           ?|<----+
	       |      +---------------+     |
	       V                            V
	    +-----+                      +-----+
	    |  C  |                      |  D  |
	    +-----+                      +-----+

	All links are 10Gbps.  Ports A,B, and C, using WIS, are tied
together into a virtual hub (Yeah!  Putting the SMAC back into CSMACD!
Packet carnage!) and port D wants to join in the fun.  The NMS needs to make
sure that the payload on port D is the correct format (adaptation layer?),
or else, it will kill the vhub with noise.  In this case, of course, the
point is moot: the MAU type on each interface will work fine.  But what
about:

	    +-----+                                       +-----+
	    |  A  |                                       |  B  |
	    +-----+                                       +-----+
	       ^                                             ^
	       |      +---------------+                      |
	       |      |               |        +-------+     |
	       +----->|- +  -  -  -  -|<------>|  LR1  |<----+
	              |               |        +-------+
	              |  |   BFR      |
	              |               |        +-------+
	       +----->|- +           ?|<------>|  LR2  |<----+
	       |      +---------------+        +-------+     |
	       V                                             V
	    +-----+                                       +-----+
	    |  C  |                                       |  D  |
	    +-----+                                       +-----+

	Now how do we verify D?  I am assuming that the SONET links will
retain the stack information, which is probably the flaw in my thinking.
I'm probably way ahead of things here, but I do like to think things out as
much as possible.

	The concept of a vhub does bring up an issue I haven't raised since
I have no idea what to do about it.  Simply put, it is not possible (or more
accurately, not advisable) to use the WIS in a transparent fashion (the
"dark pipe").  Consider an IP/ethernet administrator's view of two sites
connected by a 10Gbps WIS feed, which is leased from some telco giant:

	   +---+ WIS    -+-----------------------+-    WIS +---+
	   | A |<------->| Mysterious SONET pipe |<------->| B |
	   +---+        -+-----------------------+-        +---+

	Now, let's imagine a simple but drastic failure - a cable breaks in
the pipe so that no signal gets through.  The telco operator will get all
the information about this failure, but the ethernet operator will get
nothing (I am assuming that the IP/ethernet management software will not
look at the WIS MIB, which, for the time being, is not an unreasonable
assumption).  Am I missing something here, or will the failure information
not percolate through to the ethernet MIBs?

/|/|ike

Subject: RE: draft-wis-design-team-etherwis-01.txt
From: "C. M. Heard" <[email-masked]>
To: "Ayers, Mike" <[email-masked]>, "Norseth, KC" <[email-masked]>, Kerry McDonald <[email-masked]>, John Flick <[email-masked]>, Kaj Tesink <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Wed, 17 Oct 2001 20:54:43 -0700 (PDT)

On Wed, 17 Oct 2001, Mike Ayers wrote:

>       I think my proposal was misunderstood.  I wanted the ifStack to
> change from:
> 
>       sonet
>       sonetPath
>       ethernetCsmacd
> 
> in R mode
     ^^^^^^
(I think you mean W mode, there are no sublayers in R mode)

> to:
>       sonet
>       sonetPath
>       ethernet64-66bWIS
>       ethernetCsmacd
> in W mode.

I did misunderstand the scheme.  It will work, but it causes
an otherwise unneeded ifEntry to appear.  (Actually, if we
were not attempting to re-use the SONET-MIB, a W interface
could be modelled without sublayers, since multiplexing is
not used.)

> The idea is to handle this situation:
[ ... ]
> 
> 
>           +-----+                                       +-----+
>           |  A  |                                       |  B  |
>           +-----+                                       +-----+
>              ^                                             ^
>              |      +---------------+                      |
>              |      |               |        +-------+     |
>              +----->|- +  -  -  -  -|<------>|  LR1  |<----+
>                     |               |        +-------+
>                     |  |   BFR      |
>                     |               |        +-------+
>              +----->|- +           ?|<------>|  LR2  |<----+
>              |      +---------------+        +-------+     |
>              V                                             V
>           +-----+                                       +-----+
>           |  C  |                                       |  D  |
>           +-----+                                       +-----+
> 
> [Specifically, the NMS needs to make sure that the payload on port D
> is the correct format.]
>       Now how do we verify D?  I am assuming that the SONET links will
> retain the stack information, which is probably the flaw in my thinking.
> I'm probably way ahead of things here, but I do like to think things out as
> much as possible.

You lost me here ... I assume that A and C are WIS ports, as before,
but what are LR1 and LR2, and what prevents the ports connected to
them from being properly identified by a suitable MAU type?

>       The concept of a vhub does bring up an issue I haven't raised since
> I have no idea what to do about it.  Simply put, it is not possible (or more
> accurately, not advisable) to use the WIS in a transparent fashion (the
> "dark pipe").  Consider an IP/ethernet administrator's view of two sites
> connected by a 10Gbps WIS feed, which is leased from some telco giant:
> 
>          +---+ WIS    -+-----------------------+-    WIS +---+
>          | A |<------->| Mysterious SONET pipe |<------->| B |
>          +---+        -+-----------------------+-        +---+
> 
>       Now, let's imagine a simple but drastic failure - a cable breaks in
> the pipe so that no signal gets through.  The telco operator will get all
> the information about this failure, but the ethernet operator will get
> nothing (I am assuming that the IP/ethernet management software will not
> look at the WIS MIB, which, for the time being, is not an unreasonable
> assumption).  Am I missing something here, or will the failure information
> not percolate through to the ethernet MIBs?

I don't think the "dark pipe" (or a pipe with WIS-compatible transponders)
poses any problem.  Even if the network management system does not implement
the WIS MIB, the failure information should still be available in the
following variables:

IF-MIB:  ifOperStatus = lowerLayerDown(7) [which is equivalent to down(2)]

MAU-MIB: ifMauMediaAvailable = notAvailable(4)   |
                               wisFrameLoss(13)  |
                               wisSignalLoss(14)

Note that for an R-type 10Gb/s interface the indications would be

IF-MIB:  ifOperStatus = down(2)

MAU-MIB: ifMauMediaAvailable = notAvailable(4)   |
                               pcsLinkFault(15)  |
                               excessiveBER(16)

Mike Heard

Subject: RE: draft-wis-design-team-etherwis-01.txt
From: "Ayers, Mike" <[email-masked]>
To: "'C. M. Heard'" <[email-masked]>, "Ayers, Mike" <[email-masked]>, "Norseth, KC" <[email-masked]>, Kerry McDonald <[email-masked]>, John Flick <[email-masked]>, Kaj Tesink <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 18 Oct 2001 13:40:31 -0500

> From: C. M. Heard [mailto:[email-masked]] 
> Sent: Wednesday, October 17, 2001 08:55 PM

> On Wed, 17 Oct 2001, Mike Ayers wrote:
> 
> >       I think my proposal was misunderstood.  I wanted the 
> ifStack to
> > change from:
> > 
> >       sonet
> >       sonetPath
> >       ethernetCsmacd
> > 
> > in R mode
>      ^^^^^^
> (I think you mean W mode, there are no sublayers in R mode)

	I think I meant "I'm tired and making stupid mistakes".  There is no
reason for that to be there.

> > to:
> >       sonet
> >       sonetPath
> >       ethernet64-66bWIS
> >       ethernetCsmacd
> > 
> > in W mode.
> 
> I did misunderstand the scheme.  It will work, but it causes
> an otherwise unneeded ifEntry to appear.  (Actually, if we
> were not attempting to re-use the SONET-MIB, a W interface
> could be modelled without sublayers, since multiplexing is
> not used.)

	I'm not thinking of sublayers so much as payload identification.

> > The idea is to handle this situation:

Improved drawing:

          +-----+                        +-----+
          |  A  |                        |  B  |
          +-----+                        +-----+
             ^                              ^
             |      +---------------+       |
             |      |1             3|       |
             +----->|- +  -  -  -  -|<------+
                    |               |
                    |  |   BFR      |
                    |2             4|        +-------+
             +----->|- +           ?|<------>|1 LR  2|<----+
             |      +---------------+        +-------+     |
             V                                             V
          +-----+                                       +-----+
          |  C  |                                       |  D  |
          +-----+                                       +-----+

	BFR - Big Router
	LR - Little Router

> > [Specifically, the NMS needs to make sure that the payload on port D
> > is the correct format.]
> >       Now how do we verify D?  I am assuming that the SONET 
> links will
> > retain the stack information, which is probably the flaw in 
> my thinking.
> > I'm probably way ahead of things here, but I do like to 
> think things out as
> > much as possible.
> 
> You lost me here ... I assume that A and C are WIS ports, as before,
> but what are LR1 and LR2, and what prevents the ports connected to
> them from being properly identified by a suitable MAU type?

	Okay, Ports BFR-1, BFR-2, BFR-3, and LR-2 are configured as WIS
ports, but BFR-4 and LR-1 are simply OC-192c (note: I may have the wrong
type here.  I mean the type that WIS signals are compatioble with).  The
question is whether it is possible to join entity D into the vhub if BFR and
LR are not controlled by the same NMS.  If the ethernet64-66bWIS layer is
kept, then the NMS would be able to make that decision.  How would this
situation be handled for ATM/SONET?

> >       The concept of a vhub does bring up an issue I 
> haven't raised since
> > I have no idea what to do about it.  Simply put, it is not 
> possible (or more
> > accurately, not advisable) to use the WIS in a transparent 
> fashion (the
> > "dark pipe").  Consider an IP/ethernet administrator's view 
> of two sites
> > connected by a 10Gbps WIS feed, which is leased from some 
> telco giant:
> > 
> >          +---+ WIS    -+-----------------------+-    WIS +---+
> >          | A |<------->| Mysterious SONET pipe |<------->| B |
> >          +---+        -+-----------------------+-        +---+
> > 
> >       Now, let's imagine a simple but drastic failure - a 
> cable breaks in
> > the pipe so that no signal gets through.  The telco 
> operator will get all
> > the information about this failure, but the ethernet 
> operator will get
> > nothing (I am assuming that the IP/ethernet management 
> software will not
> > look at the WIS MIB, which, for the time being, is not an 
> unreasonable
> > assumption).  Am I missing something here, or will the 
> failure information
> > not percolate through to the ethernet MIBs?
> 
> I don't think the "dark pipe" (or a pipe with WIS-compatible 
> transponders)
> poses any problem.  Even if the network management system 
> does not implement
> the WIS MIB, the failure information should still be available in the
> following variables:
> 
> IF-MIB:  ifOperStatus = lowerLayerDown(7) [which is 
> equivalent to down(2)]
> 
> MAU-MIB: ifMauMediaAvailable = notAvailable(4)   |
>                                wisFrameLoss(13)  |
>                                wisSignalLoss(14)

	Hmmm - the wisFrameLoss sounds like it might do the trick.  I'll
peek in and see what conditions activate it.

> Note that for an R-type 10Gb/s interface the indications would be

	This would not be an issue for R-type operation, which would have
full ethernet stats all the way.

/|/|ike

Subject: RE: draft-wis-design-team-etherwis-01.txt
From: "C. M. Heard" <[email-masked]>
To: "Ayers, Mike" <[email-masked]>, "Norseth, KC" <[email-masked]>, Kerry McDonald <[email-masked]>, John Flick <[email-masked]>, Kaj Tesink <[email-masked]>, "Lam, Hing-Kam (Kam)" <[email-masked]>
Date: Thu, 18 Oct 2001 20:54:47 -0700 (PDT)

[ note: some quoted lines below re-wrapped for readability ]

On Thu, 18 Oct 2001, Mike Ayers wrote, regarding his proposal
to change the WIS ifStack from:
      ethernetCsmacd
      sonetPath
      sonet
to:
      ethernetCsmacd
      ethernet64-66bWIS
      sonetPath
      sonet

> > > The idea is to handle this situation:
> 
> Improved drawing:
> 
> 
>           +-----+                        +-----+
>           |  A  |                        |  B  |
>           +-----+                        +-----+
>              ^                              ^
>              |      +---------------+       |
>              |      |1             3|       |
>              +----->|- +  -  -  -  -|<------+
>                     |               |
>                     |  |   BFR      |
>                     |2             4|        +-------+
>              +----->|- +           ?|<------>|1 LR  2|<----+
>              |      +---------------+        +-------+     |
>              V                                             V
>           +-----+                                       +-----+
>           |  C  |                                       |  D  |
>           +-----+                                       +-----+
> 
> 	BFR - Big Router
> 	LR - Little Router
> 
> > > [Specifically, the NMS needs to make sure that the payload
> > >  on port D is the correct format.]
> > >       Now how do we verify D?  I am assuming that the SONET
> > > links will retain the stack information, which is probably
> > > the flaw in my thinking.  I'm probably way ahead of things
> > > here, but I do like to think things out as much as possible.
[ ... ]
> 	Okay, Ports BFR-1, BFR-2, BFR-3, and LR-2 are configured as
> WIS ports, but BFR-4 and LR-1 are simply OC-192c (note: I may have
> the wrong type here.  I mean the type that WIS signals are [compatible]
> with).  The question is whether it is possible to join entity D into
> the vhub if BFR and LR are not controlled by the same NMS.  If the
> ethernet64-66bWIS layer is kept, then the NMS would be able to make
> that decision.  How would this situation be handled for ATM/SONET?

OC-192c is the right type of SONET interface to match the WIS payload
rate, provided that the payload in the STS-192c path is compatible.
However, there is more than one way for the payloads to be compatible.

Let us stipulate that the BFR terminates the path layer and extracts
some kind of packet- or frame-oriented payload from the STS-192c path
-- in other words, it does _not_ process the STS-192c path as a raw
bit stream, as a SONET Add-Drop Mux would.  It follows that one or
more interface layers will be needed on top of the STS-192c sonetPath(50)
ifTable entry to represent the type of payload mapping and the type
of frames or packets that are being carried. 

Now, if the STS-192c payload consists of Ethernet MAC frames, then
the ifTable entry stacked on top of the sonetPath(50) should be
ethernetCsmacd(6).  Period.  There is no need for a separate sublayer
to represent the specific payload mapping, because (a) that can be
represented equally well by ifMauType and (b) it does not really
matter anyway!  Why do I say that?  Well, if the BFR is actually a
MAC layer bridge -- a vhub, if you wish -- all it needs to be able to
do to switch traffic is to extract Ethernet MAC frames from one 10Gb/s
interface and forward them on one or more others.  The MAC frame format
is the same irrespective of the MAU type, and so it does not matter
whether port 4 uses direct-mapped 64B/66B encoding or some other
Ethernet-over-SONET mapping.  The same is true if the BFR is a
traditional router and forwards traffic on the basis of layer 3
addresses;  in that case it will strip off the MAC layer header and
CRC, and port 4 could even use a non-Ethernet layer 2 frame format.

If port 4 uses PPP over SONET, then the ifTable entry stacked on top
of the sonetPath(50) should be ppp(23).  The router interprets the
PPP protocol ID and the encapsulation header, if one is present;
it then routes packets or bridges frames depending on what's encapsulated.

If port 4 uses ATM over SONET, then ifTable entry stacked on top
of the sonetPath(50) would be atm(37).  Since the BFR is not an ATM
switch, it will probably habe an aal5(49) ifTable entry stacked on
top of the atm(37) ifTable entry.  Note that the aal5(49) ifTable
entry is for collection of per-link rather than per-connection
statistics.  The standard way to determine the encapsulation type
(there are many!) is to look in RFC 2515's atmVclTable (which is
indexed by the atm interface's ifIndex and the vpi/vci values);
per-connection aals statistics are available in the aal5VccTable
(it is indexed by the aal5 entity's ifIndex and the vpi/vci 
values).  As always, the ifStackTable and/or ifInvStackTable serve
to tie corresponding aal5 and atm ifIndex values together.

The important part to pick out of the previous paragraph is that
the encapsulation type is available in the atmVclTable.  As for
PPP over SONET, the router interprets the encapsulation header and
routes packets or bridges frames depending on what's encapsulated.

I still don't see where an ifTable sublayer that specifies what
PCS and/or payload mapping is in use is helpful.  There are other
ways to determine the required information.

Mike

---

From: "C. M. Heard" <[email-masked]>
Date: Mon, 3 Dec 2001 15:09:53 -0800 (PST)

Regards,

Mike H.

John

	sonet
	sonetPath
	ethernetCsmacd

in R mode to:

	sonet
	sonetPath
	ethernet64-66bWIS
	ethernetCsmacd

	    +-----+                      +-----+
	    |  A  |                      |  B  |
	    +-----+                      +-----+
	       ^                            ^
	       |      +---------------+     |
	       |      |               |     |

	    +-----+                                       +-----+
	    |  A  |                                       |  B  |
	    +-----+                                       +-----+
	       ^                                             ^
	       |      +---------------+                      |
	       |      |               |        +-------+     |

/|/|ike

     ^^^^^^

[ ... ]

Mike Heard

Improved drawing:

          +-----+                        +-----+
          |  A  |                        |  B  |
          +-----+                        +-----+
             ^                              ^
             |      +---------------+       |
             |      |1             3|       |

	BFR - Big Router
	LR - Little Router

/|/|ike

[ ... ]

Mike