North American Network Operators Group|
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Re: Telco's write best practices for packet switching networks
- From: Kelly J. Cooper
- Date: Wed Mar 06 14:17:52 2002
On Mar 6, 7:56am, Sean Donelan wrote:
> Subject: Telco's write best practices for packet switching networks
*After the SNMP excitement I asked if anyone had suggestions on how
*to architect or design a backbone network to be less suspectible to
*problems. It turns out the telephone industry has written a set of
*best practices for the Internet.
The report is 122 pages long and contains a review of how they took
existing Best Practices, collected mostly from the previous NRIC, and
refined them (based on criteria outlined on p.22). Then performed a
SURVEY of what people thought about the 256 BP recommendations they
had, covering Service Providers of multiple services and equipment
suppliers, all somehow related to telecommunications.
The BPs themselves range from:
5-501 "Network Operators should report problems discovered from their
testing to the Equipment Supplier whose equipment was found to be the
cause of problem."
5-758 "If 911 call completion is affected, test calls should be made
by the Server Provider to the PSAP(s) to assess the impact. Once
service is restored, the Service Provider should make multiple 911
test calls to ensure they complete properly." (See Appendix A)
I don't think they were focusing on BPs for the Internet per se so
much as believing that many BPs that work for PSTN should also work
for the Internet.
Whether or not they are correct is a (if not THE) challenging matter
*Focus Group 2.A.2: Best Practices on Packet Switching. Karl Rauscher,
* Mr. Rauscher gave an example of the kind of information to be found
* there. The best practice used in the example states that critical
* packet network elements such as control elements, access in signaling
* gateways and DNS servers, should have firewall protection such as
* screening and filtering. One hundred percent of the respondents
* indicated they were implementing this best practice.
*Cool, who has an OC-192 firewall on their control elements? What is
*a control element, is that the same as a router or is that a signaling
Damned flat internet... can't tell if you're kidding or not. I'm
guessing that you are, but just in case... Control elements are the
router-like bits or computer-like bits that actually "control"
management of the switch (i.e. you connect to that part in order to
reconfigure, upgrade, etc. the element).
Most ISPs have a comparable set-up wrt modems/terminal servers for
managing their network elements - same dealy, but ISPs can choose
between inband & OOB whereas the telcos can't. (Or couldn't, til
recently, when Net/Bell convergence started urging the market toward
big damn fiber switches with in-band mgmt tools.)
So - in the world of telco, the control elements are JUST OOB. Since
you literally can't reach them inband, the OOB element mgmt can be
done through modems or a separate network which is firewalled off
from the rest of the Internet. That's what they're talking about in
What I find interesting is that I've heard a lot of cage rattling to
take the Internet in this direction, i.e. stop managing it in-band
where all the kiddies and the terrorists can get at it and start
managing it OOB. Hide it, shut it away, don't route it, etc.
nevermind what a pain it is to manage TWO networks... nevermind how
much flexibility you lose. (Sorry, my bias is showing.)
And I'm hearing this from BOTH NetHeads AND BellHeads.
Kelly J. Cooper - Security Engineer, CISSP
GENUITY - Main # - 800-632-7638
3 Van de Graaff Drive - Fax - 781-262-2744
Burlington, MA 01803 - http://www.genuity.net