Re: Boiling it down to the essential M
Bill,
That would be great if transmission equipment used SNMPv2. Most of the existing
equipment uses TL1. The new standard for network management protocols for
transmission equipment is Q3 which is based on the OSI G2/E1 protocol. Some low
end metro DWDM startup systems use Java/HTML as well as SNMP for network
management, but it is mostly unusable over large transmission systems.
Thank you,
Roy Bynum
MCI WorldCom
"Bill St. Arnaud" wrote:
> Roy:
>
> I agree with you management of repeaters should be out of band. BUT, in my
> opinion should still use as much as practically possible, standard IP
> addressing and SNMPv2 techniques visible through a separate communications
> channel. We do this a lot with our routers, where the management I/F is
> part of another IP domain (Bell's commercial Internet service)
>
> Bill
>
> Bill St. Arnaud
> Senior Director Network Projects
> CANARIE
> bill.st.arnaud@xxxxxxxxxx
> +1 613 785-0426
>
> > -----Original Message-----
> > From: owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx
> > [mailto:owner-stds-802-3-hssg@xxxxxxxxxxxxxxxxxx]On Behalf Of Roy Bynum
> > Sent: September 5, 1999 4:22 PM
> > To: Hon Wah Chin
> > Cc: 'stds-802-3-hssg@xxxxxxxx'
> > Subject: Re: Boiling it down to the essential M
> >
> >
> >
> > 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.
> >