Telco's write best practices for packet switching networks

Wed Mar 6 19:13:47 UTC 2002

Sean,

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.

Uh huh...

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."

...to...

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 
for debate.

*Focus Group 2.A.2: Best Practices on Packet Switching. Karl Rauscher,
*Lucent Technologies
*http://www.nric.org/pubs/index.html
*
*   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
*gateway?

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 
your excerpt.

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.

-- 
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