IT. Expert System.

RFC (unknown status)

Network connectivity: A response to RFC 603. A.M. McKenzie. January 1974. RFC613. (Format: TXT=2557 bytes) (Updates RFC603) (Status: UNKNOWN) (DOI: 10.17487 / RFC613)


 Network Working Group                                   Alex McKenzie
RFC # 613                                               BBN-NET
NIC # 21525                                             January 21, 1974
             Network connectivity:  A response to RFC #603
Network topology is a complicated political and economic question with
obvious technical overtones.  I shall not attempt, in this note, to
cover all the possible arguments which might be made, but merely to
respond directly to the points raised in RFC #603.
    1.  The important consideration in deciding whether it is good or
    bad to have a node (AMES) be four connected is not how many circuits
    are affected by a node failure; rather one should consider how well
    the network is still connected after a node failure.  For example,
    if ALL nodes in the network were four-connected I doubt that anyone
    would argue that this was bad for reliability.  The weaknesses are
    not the three-connected and four-connected nodes but rather the
    ONE-connected (Hawaii, London) and two-connected nodes.  I must
    agree with Burchfiel's implied argument that it is better to have
    two adjacent three-connected nodes than to have a four-connected
    node adjacent to a two-connected node;  unfortunately the realities
    of installing interfaces and common carrier services cause the
    Network to expand in sub-optimal ways.
    2.  "Loops" are not good per se, they appear good because the act of
    making loops increases the connectivity and thereby reduces the
    effect of multiple failures.  Adding more circuits costs ARPA money,
    both capital cost for IMP interfaces and recurring cost for the
    circuits. The network group at BBN has suggested to ARPA several
    times that "connectivity should be increased" but it was only late
    in December 1973 that we made specific suggestions for the locations
    of additional circuits.  These recommendations were not based on
    building loops (although they may have that effect) but were based
    on breaking the long chains of IMPs which have occurred as the
    Network has grown.  ARPA and NAC are now presumably in the process
    of evaluating our suggestions, and perhaps formulating other
    possibilities.
       [ This RFC was put into machine readable form for entry ]
       [ into the online RFC archives by Alex McKenzie with    ]
       [ support from GTE, formerly BBN Corp.            10/99 ]
McKenzie                                                        [Page 1] 


Content

Android Reference

Java basics

Java Enterprise Edition (EE)

Java Standard Edition (SE)

SQL

HTML

PHP

CSS

Java Script

MYSQL

JQUERY

VBS

REGEX

C

C++

C#

Design patterns

RFC (standard status)

RFC (proposed standard status)

RFC (draft standard status)

RFC (informational status)

RFC (experimental status)

RFC (best current practice status)

RFC (historic status)

RFC (unknown status)

IT dictionary

License.
All information of this service is derived from the free sources and is provided solely in the form of quotations. This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 241 / 158767613. Delta: 0.00352 с