Re: Boiling it down to the essential M
Roy,
Hon Wah has made an excellent attempt at a complete proposal for getting management
information out of an Ethernet/802.3/IP WAN which includes devices such as
regenerators, amplifiers, etc. In your note I don't sense a counter proposal of the
same extent as Hon Wah's so I'll just address your comments individually:
1) Processing of each and every data packet to determine if the management traffic
is from the regenerator:
All management information is identified by address (special or otherwise), as SNMP
data. All of this is well defined for Ethernet today. Network Management and
Ethernet are almost synonymous today. Extending Network Management to the WAN
according to Hon Wah's proposal seems almost too simple.
2) The regenerator insert data traffic in band into what could already be a fully
saturated data stream:
This is not how Ethernet has historically worked for both data transfer and network
management. Most reliable Ethernet networks are over configured to ensure that
there is sufficient bandwidth to handle all network traffic patterns. Ethernet is
not a TDM network as is SONET. Therefore, this is a non issue.
3) Security risk:
This point is not applicable since there is no inherent difference in management
information being transported as overhead bytes through the WAN or via frames
through the WAN. Regardless of how the management data is transported through WAN
devices, the management information will be eventually be forwarded to higher
layers for transport and eventual processing by a Network Management application. I
see absolutely no difference in how an individual can covertly tap into an Ethernet
or SONET stream.
I welcome you to submit a counter proposal to Hon Wah's proposal which is as
complete in order to make a fair comparison. Remember that 802.3 generally votes on
proposals when developing a standard, without a proposal, there's not much chance
that your comments will ever get into the standard.
Best Regards,
Rich
--
Roy Bynum wrote:
> Hon,
>
> The problem with the architecture of using in band TCP/IP network management at
> the regenerator sites is that it requires the processing of each and every data
> packet to determine if it is for the regenerator. It also requires that
> regenerator insert data traffic in band into what could already be a fully
> saturated data stream. It also provides a security breach entry point for
> someone who got access to regenerator to now have full access to the data
> stream. Since most regenerator sites are somewhere in the country side and
> unmanned, this is a major security risk. I don't think that very many
> companies will buy this when they understand the risks.
>
> Thank you,
> Roy Bynum
> MCI WorldCom
>
> Hon Wah Chin wrote:
>
> > Just as a discussion point for evaluating the complexity of getting
> > maintenance information into and out of an Ethernet/802.3/IP
> > infrastructure, here is a strawman.
> >
> > Use SNMP with some new MIBs, reporting performance as previously
> > suggested. Likely objections to this approach would be on the basis
> > of the implementation expense of the IP/UDP/SNMP stack, and the
> > management issues of assigning IP addresses to isolated and remote
> > equipment.
> >
> > The cost of digital logic and the memory required to buffer
> > packets and store code is dropping very fast. The management and
> > assignment of IP addresses for switching and routing devices is not
> > an issue because managing those devices already requires IP address
> > assignment, and that infrastructure works. The remaining problem is
> > to communicate with regenerators, which might be required for long
> > haul links,
> >
> > Since we're talking about two port devices with point-to-point
> > links, some simplifications can be used.
> >
> > 1. Special MAC address or MAC control frame encapsulation
> > instead of IP over Ethernet encapsulation.
> > 2. No real need for an actual unique IP address. Some
> > dummy would do. (say -1 for the destination address)
> > 3. For the purpose of looking further down the regen chain,
> > subtract 1 from the destination address for each expected hop.
> > Each regen can increment and foward, processing the frame itself
> > when it gets to -1 or zero.
> > 4. For directing the response, use the "source IP address" which is
> > the number of hops away. It doesn't change during forwarding
> > and is inverted and used to generated the response "dest IP addr".
> > 5. Non cooperating stations at the end of the chain cause timeouts.
> > 6. Cooperating ending stations can respond with some error code saying that
> > the end of the regen chain has been reached.
> > 7. 802.3 could define the MIBs and MAC addressing/type code for this
> > type of function, leaving the other IP/SNMP formats, addressing and
> > forwarding functions to another group.
> > 8. Quick notification to upper layers of a span failure can be achieved
> > by assigning some IDLE_2 code which is used by regens seeing
> > a loss of signal or which see IDLE_2 codes come in. Layer 3
> > can redirect traffic while the MAC maintenance layer can probe
> > the chain for fault isolation.
> >
> > Advantages:
> > 1. SNMP/IP is already defined.
> > 2. No IP address configuration.
> > 3. No explicit topology discovery required.
> > 4. Backward compatibility with older equipment
> > 5. Everything works even without this
> > 6. Minimum effort at 802.3 - Variables and MIB; Address and Type Code;
> > extra IDLE_2 code for span failure notification.
> >
> > This kind of approach depends on store and forward. Standard
> > regeneration forwards bits without parsing the packet, so this either
> > causes delays or has to modify/invalidate packets on the fly as they
> > pass through. However, this amount of store and forward is
> > comparable to that required by proposed FEC schemes.
> >
> > There might still be an issue about making sure there's enough
> > bandwidth to interpolate the response into the traffic stream. I
> > thought about using PAUSE frames, but if the endstations at the two
> > ends are using the also, there would be interference. We can, of
> > course, use the previously discussed HOLD mechanisms and restrict the
> > stations at the end of regenerator chains to only 95.8% of the link's
> > available throughput, always leaving some bandwidth for this
> > kind of response traffic.
> >
> > I present this gedanken to show the possibility of retrieving THE key piece
> > of Maintenance information -- WHICH span has a problem. SONET carries
> > other additional information, and I look forward to understanding
> > their applicability to the transport of Ethernet packets at 10 Gb/s.
-------------------------------------------------------------
Richard Taborek Sr. Tel: 650 210 8800 x101 or 408 370 9233
Principal Architect Fax: 650 940 1898 or 408 374 3645
Transcendata, Inc. Email: rtaborek@xxxxxxxxxxxxxxxx
1029 Corporation Way http://www.transcendata.com
Palo Alto, CA 94303-4305 Alt email: rtaborek@xxxxxxxxxxxxx