| Final Draft Copy
DECbrouter 90 Software Product Description
The DECbrouter 90 is a multiprotocol internetworking solution for linking
small and medium sized Ehternet networks. The DECbrouter 90 provides full-
featured remote routing of the industrys most widely-implemented
communication protocols. The DECbrouter 90 also supports concurrent
bridging and bidirectional protocol translation between TCP/IP,X.25 and
Local Area Transport environments.
The DECbrouter 90 software supports leased-line, circuit-swithched or packet
-swithched networks, such as X.25, Switched Multimegabit Data Service (SMDS)
or Frame Relay. The DECbrouter 90 is well suited for remote applications
between branch offices and district or regional offices.
The DECbrouter 90 provides priority output queuing for use with slower speed
serial lines. One of four priorities can be assigned to a packet based on
packet/protocol type or source target host or workstation address.
The DECbrouter 90 is designed int he DEChub 90 product form factor and
can be configured as a standalone unit or in the hub. The DECbrouter 90 also
can be configured in the DEChub 900.
Bridging:
.The DECbrouter 90 supports both IEEE 802.1D, DEC LAN Bridge Spanning
Tree for backward compatibility. The DECbrouter 90 also supports the
recent IEE standard implementation that provides for multiple domains
for Spaning Tree. You can place any number of router/bridges within
the domain. The devices in the domain, and only those devices, will
share spanning-tree information
.Allows configuration of filters to effectively block the passing
of frames based on Ethernet addresses, protocol type and vendor
code. The bridging software can also be configured to selectively
include or exclude LAT multicast service anouncements.
.Provides load balancing and redundancy by assigning a set of serial
lines between two bridges to a circuit group.
.Provides the ability to bridge over X.25 and frame-relay networks.
.Provides for the compression of LAT frames to reduce LAT traffic
through the network.
DECnet:
The DECbrouter 90 Software Microcode implements both the DECnet Phase IV
routing algorithm (routing vector) and the DECnet/OSI Phase V routing
algorithm (link-state routing). The DECbrouter 90 Software Microcode
supports both intra-area routing (Level 1) and inter-area routing (Level 2).
The DECbrouter Software can run either the Phas IV or Phase V routing
algorithm in either combination at each level. When running the Phase V
algorithms at either level 1 or level 2, the routing software is still able to
handle traffic generated by DECnet Phase IV end systems and performs any
necessary address and header conversions.
Communication with DECnet end or intermediate systems over synchronous
connections can use HDLC,PPP, or X.25 data link protocols.
The DECbrouter 90 software supports path splitting over up to four routing
circuits. If the cost between the router and the destination node is
the same on multiple synchronous circuits, then the DECbrouter 90 software
splits the traffic across all the circuits. The DECbrouter 90 can
communicate with other routers which support DECnet routing over PPP data links
in accordance with RFC1376.
TCP/IP:
The DECbrouter 90 implementation of TCP/IP provides all major services contained
in the various protocol specifications. The DECbrouter 90 also provides
TCP and UDP litlle services called Echo and Discard. These services are
descirbed in RFC 862.
The DECbrouter 90 supports TCP and UDP at the transport layer, for maximum
flexibility in services.
The DECbrouter 90 supports the following RFCs
RFC 862 - TCP & UDP Echo Serivce and Discard
RFC 863 - TCP & UD Echo Service and Discard
RFC 1166 - Internet Numbers
RFC 1020 - Internet Addresses
RFC 988 - Class D Internet Addresses Multi Cast Groups
RFC 950
RFC 826 - ARP, Proxy ARP and RARP
RFC 1027 - ARP,Proxy ARP and RARP
RFC 903 - ARP,Proxy ARP and RARP
RFC 1042 - ARP
RFC 919 - Broadcasting Datagrams
951
RFC 922 - Broadcasting Internet Datagrams in the Presence of Subnets
RFC 768 -
RFC 1191 - IP MTU Path Discovery
RFC 1108 - IP Security Option
RFC 1144 - Compressing TCP Headers
RCC 1084 - SLIP Extended BootP Requests
RFC 868 - IP Addresses
RFC 865
RFC 887 - Resource Location Protocol
. IP Routing Protocols:
The DECbrouter 90 Software Microcode supports the following IP Routing
Protocols; RIP, NSF, IGRP,OSPF,EGP,BGP, OSPF, and Integrated IS-to-IS. The
routing protocols are broqadly divided into two classes: interior gateway
protocols (IGPs) and exterior gateway protocls (EGPs). Supported interor
routing Protocols include:
(RIP) Routing Informatin Protocol is the routing protocol used by the
routed process on Berkeley-derived UNIX systems. Many networks use RIP;
it works well for small isolated, and topologically simple networks.
Supports (RFC 1058)
(HELLO) is an older interior routing protocol used in the early National
Science Foundation (NSF) backbone network. Supports (RFC 891)
(IGRP) the Interior Gateway Routing Protocol developed by Cisco Systems,
focuses on large networks with complex topology and segments having
different bandwidth and delay characteristics.
(OSPF) Open Shortest Path First Routing Protocol distributes routing
information between routers belonging to a single AS. OSPF is based on
shortest-path-first, or link state, technology. OSPF was desinged expressy for
Internet environment and includes explicit support for IP subnetting. OSPF
also privides for packet autheniticatin and uses IP multicast when sending/
receiving packets. (OSPF V2 RFC 1247)
The Exterior routing protocols include the Exterior Gatway Protocol (EGP)
and the Border Gateway Protocol (BGP). Exterior protocols are used
to exchange routing informatin between networks that do not shae a common
administration.
(EGP) is the original exterior protocol and is stillused primarily in the DDN
(Defense Data Network) and NSFnet. Supports (RFC 888,904)
(BGP) is a more recent exterior routing protocol that solves some of
EGPs failings. Supports (RFC 1276)
Switching ISO CLNS:
The DECbrouter 90 software supports packet forwarding and routing for
ISO CLNS on networks using a variety of data link layers. You can use
CLNS routers on serial interfaces with HDLC,LAPB,X.25,SMDS or Frame
Relay encapsulation. To use HDLC encapsulation you must have a DECbrouter
90 at both ends or a Cisco router at the other ends of the link. If you
use X.25 encapsulation, you must manually enter the NSAP-to-X.121 mapping.
The LAPB,SMDS,Frame Relay, and X.25 encapsulation will interoperate with
other vendors.
. The DECbrouter 90 CLNS implementation is compliant with the
Government open Systems Interconnection Profile (GOSIP) Version 2.
. As a part of CLNS support, the DECbrouter 90 fully the following
ISO and ANSI standards:
- ISO 9542-Documents the End System-Intermediate System (ES-IS)
routing exchange protocol
- ISO 8473-Documents the ISO Connectionless Network Protocol (CLNP)
- ISO 8348/Ad2-Documents Network Service Acxcess Points (NSAPs)
- ISO 10589-Documents Intermediate System-Intermediate System (IS-IS)
Intra-domain Routingt Exchange Protocol.
. The DECbrouter 90 supports both the ISO-developed IS-IS and Cisco's ISO
Interior Gateway Routing Protocol (ISO-IGRP) dynamic routing protocols for
dynamic routing of ISO CLNS.
Novell IPX:
The DECbrouter 90 implementation of NovellOs IPX protocol provides all of
the functionality of a Novell External Bridge (Novell refers to its routing
functinality as bridging). As a Novell External Bridge the DECbrouter 90
can connect through high speed serial lines (56kbps to T1 speeds) or X.25.
At this time the DECbrouter 90 implementation is not compatible with Novell
file server interfaces on the wide area, so you must have a DECbrouter 90
on both ends of the T1 and X.25 circuits.
The DECbrouters 90 implementation of Novell IPX software provides three types
of filtering:
. Access lists, or packket filtering, controls whether or not packets are
sent out the filtered interface.
. Routing update filtering controls to which Novell IPX networks the router
advertises routes to, depending on the type used.
.SAP filtering controls the services the router kowns about and which
services the router advertises.
The DECbrouter 90 also supports Novell fast switching which allows higher
throughput by switching the packet using a cashe created by previous
transit packets. Fast switching also provides laod sharing on a per packet
basis.
Appletalk:
The DECbrouter 90 supports Appletalk which ws designed as a client-server,
or distributed, network system. AppleTalk identifies several network entities,
of which the most elemental is a node. A node is simply a device connected
to an AppleTalk network. A router is considered a node on each connected
network. The DECbrouter 90 supports Appletalk over synchronous serial,
and X.25 interfaces.
The DECbrouter 90 provides implementation of the following standard services,
in addition to route any standard Appletalk packet.
. (AARP) Appletalk Address Resolution Protocol
. (DDP) Datagram Delivery Protocol
. (RTMP) Routing Table Maintenance Protocol
. (NBP) Name Binding Protocol
. (AEP) Appletalk Echo Protocol
. (ATP) Appletalk Transaction Protocol
. (ZIP) Zone Information Protocol
. Support for Ethertalk 1.2 and Ethertalk 2.0 without the requirement for
translation or transition routers
. Support for serial protocols, including SMDS, Frame Relay, X.25 and HDLC
. Configurable protocol constants
. NBP proxy service providing compatibility between the two Appletalk
standars
. IP encapsulation of Appletalk, IPTalk, and Columbia Appletalk Package
(CAP) support.
. Access control support to allow filtering of zones, routing data and
packets
. Integrated node name support to simplify Appletalk management
. Interactive access to AEP and NBP provided via ping router command
. Support for both configured (aka seed) and discovered port configuration
. Responder support used by InterY Poll and other network monitoring
packages
. SNMP over AppleTalk support
The DDP,RTMP and AARP protocols provide end-to-end connectivity between
internetworked nodes. NBP maps network names to Appletalk internet addresses.
The DECbrouter 90 also supports the extended Appletalk architecture which
increases the number of nodes per Appletalk internetwork to over 16 million
and an unlimited number of zones per cable. Apple has also enhanced
AppletalkOs routing capabilites and reduced the amount of network traffic
generated by Appletalk routers. The DECbrouter 90 also supports
Appletalk extended and nonextended architecture. Nonextended architecture
is sometimes called Phase I and extended architecture is sometimes called
Phase II.
Apollo Domain:
The DECbrouter 90 implements the Apollo Domain routing protocol which is the
native-mode networking protocol for Apollo workstations. The DECbrouter 90
implementation supports packet forwarding and routing for the Apollo Domain
network protocols on Ethernet and serial interfaces using HDLC or X.25
encapsulation.
Banyan VINES
The DECbrouter 90 supports the Baynan VINES (Virtual Network Systems) protocol.
Although, software automatically determines a metric value that it uses in
routing updates based on the delay set for the interface, the DECbrouter 90
implemenation allows you to customize the metric.
The DECbrouter 90 software offers address resolution to respond to
address requests, and propagation of broadcast addresses. MAC-level
encapsulation as well as name-to-address binding for VINES host names is
also supported, as are access lists to filter packets to or from a specific
network. The DECbrouter 90 implementation also includes EXEC-level
commands for maintaining, monitoring, and debugging the VINES network.
XNS:
The DECbrouter 90 supports a subset of the XNS protocol stack to support
XNS routing. The DECbrouter 90 supports routing XNS traffic over point to
point serial lines runnig HDLC, LAPB, X.25 Frame Relay or SMDS networks.
When XNS routing is enabled, the address used is either the IEEE-compliant
address specified in the XNS routing configuration command, or the first
IEEE-compliant address in the system. The address is also used as the node
address for non-LAN media, notable serial links. The DECbrouter 90
implementation of XNS provides you several options for managing throughput
while dynamically routing; you can set up multiple paths and send packets
over these paths in a round-robin fashion, you can also enable or disable
fast switching. you can even adjust how often your router uses RIP to
send routing table updates to its neighboring routers.
. Fast switching - XNS fast switching achieves higher thoughput by
using cache created by previous transit packets. Fast switching
for XNS provides load sharing on a per-packet basis. When
you enable XNS routing, fast switching is automatically enabled.
. Multiple paths - by default the router will pick one best path
and send all traffic on this path, but you can configure it to
remember two or more paths that have equal costs and balance the
traffic load across all the available paths.
Ungermann-Bass Net/One products use XNS as the network layer. However, Net/One
as a whole is not equivalent to standard XNS. When using the DECbrouter 90
in Net/One environments you must consider a few factors.
. Net/One routers use Ungermann-Bass proprietary routing protocol instead
of standard XNS RIP. The DECbrouter 90 supports both reception and
generation of Ungermann-Bass routing packets, and can interoperate
with Ungermann-Bass routers.
. Net/One routers send periodic Hello packets, which are used by end
nodes in discovering routers to be used in sending packets to
destinations that are not on the local cable. Ordinary XNS end
hosts use RIP for this purpose. The DECbrouter 90 can be configured
to generate Ungermann-Bass Hello packets.
CHAOSnet:
The DECbrouter 90 supports full CHAOSnet routing and a small subset of
CHAOSnet host functions, including status ,uptime, and dump routing table
services. The DECbrouter 90 supports routing CHAOSnet packets over
synchronous serial lines.
CHAOSnet routing does not replace internet routing, and Internet routing
protocol, such as RIP, must run concurrently with CHAOSnet routing on the
router.
X.25:
X.25 support can be used in two different ways: As a transport for datagram
traffic - This entails encapsulating data grams of IP, DECnet, Appletalk, and
so forth inside on an X.25 virtual circuit. Mappings between X.25 addresses
and protocol addresses allow these datagrams to be routed through an X.25
network. An X.25 Public Data Network (PDN) is used to transport LAN Protocols.
This is accomplished by first establishing a mapping between protocol addresses
and the X.121 addresses of the X.25 network.
Switched Virtual Circuits only exits for the duration of the session. Their
are three phases associated with Switched Virtual Circuits, call set-up,
information transfer, and call clear.
X.25 switch - X.25 callls can be routed based on their X.25 addresses either
between serial interfaces on the same router (local switching) or accross
an IP network to anouther router (remote switching, also callled tunneling).
Protocol to Virtual Circuit Mapping - The Call Request packet that sets up
a virtual circuit contains a field called the Call User Data (CUD) field.
Typically, the software uses the first byte of call user data to distinguish
which high-leve protocol will be carried by a particular virtual circuit.
Permanent Virtual Circuits (PVCs) are the X.25 equivalent of leased lines;
they are never disconnected. The X.25 protocol maintains multiple connections
over one physical link between a DTE and a DCE. These connections are called
virtual circuits (VCs) or logical channels (LCs). X.25 can maintain up to
4095 Virtual Circuits numbered 1 through 4095; and individual VC is identified
by giving its logical channel identifer (LCI) or virtual circuit number (VCN).
The argument count is a circuit count from 1 to 8; the default is 1. A
maximum of eith Virtual Circuits can be configured for each protocl/host pair.
This value should not be set greater than 1 for use with protocols that do not
tolerate out-of-order delivery such as switched as switch X.25 and encapsulated
TCP header compression.
X.25 TCP Header Compression - TCP header compression is supported over
X.25 links through the use of the X.25 map compressdtcp interface subcommand.
The implementation of compressed TCP over X.25 uses a virtual circuit to
pass the compressed packets. The non compressed packets us another
Virtual Circuit.
X.25 Level 2, or LAPB (link Access Procedure, Balanced), is a data
encapsulation protocol that operates at Level 2 (the Data Link Level) of the
OSI reference model. LAPB specifies methods for exchanging data (in units
called frames, detecting out-of sequence or missing frames, retansmitting
frames, and acknowledging frames.
It is possible to only use LAPB as a serial encapsulation method. This can
be done using a leased serial line. You must use one of the X.25 packet-level
encapsulations when attacheng to an X.25 network. A router using LAPB
encapsulation can act as a DTE or DCE device at the protocl level.
Retransmission Timer - The retransmission timer determines how long a
transmitted frame can remin unacknowledged before the router polls for an
acknowledgement. For X.25 networks, the router retransmission timer setting
should match that of the network. Mismatched retransmission timers can
cause excessive retransmissons and an effective loss of bandwidth.
DDN Protocols, as used with the DDN X.25 Standard, 1822-LH/DH, and HDH
(1822-J)
Frame Relay Serial Encapsulation:
The DECbrouter 90 Software Microcode supports Frame Relay is an encapsulation
method and is directd mainly to users withlarge T1 network instalations.
The DECbrouter 90 supports the two generally implementd specifications for
frame relay Logical Management Interfaces:
. The Frame Relay Intgerface specification produced by Northern Telecom,
Digital Equipment Corporation, Stratacom and Cisco Systems.
. The ANSI- adopted frame relay specification T1.617 Annex D.
The DECbrouter 90 Software Microcode implementation also conforms to the
Link Access Procedure (LAP-D) defined by the CCITT under its I-series
(ISDN) recommendatin as I122, "Framework for Additional Packet Model
Bearer Services," and IETF encapsulation in accordance with RFC 1294.
The DECbrouter 90 Frame Relay implementation currently supports routing
on Appletalk, DECnet,IP, ISO CLNS, Novell IPX, VINES and transparent
bridging.
Serial Tunneling and SDLC Transport:
The DECbrouter 90 Serial Tunnel (STUN) function allows two devices using
SDLC or HDLC compliant protocols that are normally connected by a direct
serial link to be connected through one or more routers. The SDLC
Transport function, which is a variation of STUN, allows sessions that are
using SDLC protocols and TCP/IP enclapsulation to be localy terminated.
SDLC Transport replaces proxy polling, a method that was used to limit traffic
transmitted across a network backbone. As an SDLC function, STUN fully
supports the IBM Systems Network Architeture (SNA), and allows IBM
Synchchronous Data Link Control (SDLC) frames to be transmitted across the
network media an/or shared serial links. The STUN functin also provides for
configuration of redundant links to provide transport paths in the event
part of the network goes down.
. Switched Multimegabit Data Service (SMDS)
The DECbrouter 90 provides an interface to an SMDS network using DS1
transmission facilities at the rate of 1.544 Mbps. Connection to the network
is made through a device called an SDSU - an SMDS CSU/DSU (Channel Service
Unit/Digital Service Unit). The SDSU attaches to the DECbrouter 90 through
an TS-449 connection. On the other side, the SDSU terminates a DS1 line.
The DECbrouter 90 implementation of SMDS supports the IP,DECnet, Appletalk,
XNS, Novell IPX, Ungermann-Bass Net/One, and OSI internetworking protocols.
IP routing is fully dynamic; that is , the routing tables are determined and
updated dynamically. Routing of the other supported protocols requires
that you establish a static routing table of SMDS neighbors in a user
group. Once this is set up, all interconnected routers provide dynamic
routing.
. Interior Gateway Routing Protocol (IGRP)
The Interior Gateway Routing Protocol (IGRP) developed by Digital Systems
for TCP/IP and ISO CLNS monitors the network to determine the status of each
route and selects the best route for each data packet. Network traffice, path
reliability and path speed all infulence route selections.
While runing IGRP or ISO-IGRP, routers can concurrently receive and understand
messages from other network segments sent using different routing protocols.
. Intergrated IS-to-IS
Integrated IS to IS is based on OSI IS-IS Intra-Domain routing with additions
to support IP routing as defined in RFC 1195. An IS-IS routing circuit is
required in order to handle IP traffic either within a level 1 area or
between areas over a level 2 link. When using Integrated IS-IS, the
software supports equal-cost path splitting of IP data over up to four
equal paths. Variable, but contiguous, IP subnet masks are also supported.
Serial Tunneling and SDLC Transport:
The DECbrouter 90 Serial Tunnel (STUN) function allows two devices using
SDLC or HDLC compliant protocols that are normally connected by a direct serial
link to be connected through one or more routers.
The SDLC transport function, which is a variation of STUN, allows session
that are usins SDLC protocols and TCP/IP encapsulation to be locally
terminated. SDLC Transport replaces proxy polling, a method which was
used to limit traffic transmitted acros a network backbone.
By replacing direct serial links with routers, serial frames can be propagated
over arbitrary media and topologies to another DECbrouter with STUN link
to an appropriate end point. The intervening network is not restricted
to STUN traffic, but rather, is multiprotocol. The DECbrouter Microcode
Software encapsulates SDLC frame traffic into IP packets and routes them
over any of the IP supported network media. Because TCP/IP encapsulation
is used you can use any of the routing protocols to route the packets.
STUN copies frames to destinations based on address, but does not modify
the frames in any way or participate in SDLC windowing or retransmission.
SDLC was designed to ensure reliable data transmission across serial media
having minimal or predictable time delays.
The DECbrouter also implements SDLC Local Acknowledgement, which is also
known as local termination. SDLC local acknowledgement capability applies only
to SDLC tunneling across TCP/IP networks, the current release of SDLC
Local Acknowledgement does not apply to HDLC tunneling or to transfer SDLC
across HDLC serial links. With Local Acknowledgement turned on, the SDLC
session between the two IBM end nodes is not end-to-end but instead terminates
at the two local routers. Benefits of the Local Acknowledgement feature
are that it solves the session keepalive timer problem without having to
change configuration end nodes, and that the host's resource definition
(such as sysgen) does not have to change.
Protocol Translator:
The DECbrouter 90 supports protocol translations which are high-performance
application-level gateways that can provide connectivity among systems
running differing protocols over a variety of communication media.
As a part of the protocol thranslation software capability in the DECbrouter
90, the protocol translation software provide distributed network management
facilities to assist in performance monitoring, runtime error logging, and
Simple Network Management Protocol (SNMP) These features allow the network
manager to examine and adjust the protocol translators for optimum performance.
Remote configuration is also available through Telnet and MOP connections
to virtual ports on the terminal servers.
Security features in the DECbrouter 90 software allow restrictions
to resources on the network. The network manager can specify access lists
to establish which users have access to which computers. A username-and-
password-pair authentication scheme is also supported.
The DECbrouter 90 also supports the application gatway function which
translates virtual terminal protocols to allow devices running dissimilar
protocols to communicate. The DECbrouter 90 software supports Telnet (TCP),
LAT, and X.25. One-step protocol translation software performs
bidirectional translation between any of the following protocols:
The protocol translator software supports connectivity over the following
WAN services; SMDS,Frame Relay and X.25.
. Telnet <-> Lat
. Telnet <-> X.25
. Lat <-> X.25
. X.25 PAD protocols, which permit cost-effective, as needed us of major
public networks in the Unites States and Europe. The DECbrouter
protocol translator supports X.25 protocol and X.3/X.28/X.29 specifications.
SNMP Management: (Jeff needs to fill in)
The DECbrouter 90 is managed by (SNMP) Simple Network Protocol. The DECbrouter
90s implementation of SNMP is compatible with RFCs 115, 1157, and 1213 and
this provides Cisco-specific varialbles.
The Management Information Base (MIB) supports all of the RFCs 1155 and 1213.
A seperate document, avaialbe in RFC 1212-type format (consie MIB) describes
all the specific SNMP variables in the MIB. It also describes what is
required to get minimum configuration.
Dial On Demand Routing - ISDN Connectivity
The DECbrouter 90 supports Dial-on-demand routing (DDR) connections
in an environment using the public switched telephone network (PSTN).
Traditionally, networks have been interconneted using dedicated lines
for WAN connections. When used with modems, ISDN terminal adaptors or
integrated ISDN capibilites, DDR provides low volume periodic network
conections over a PTN.
DDR allows attachement to modems and ISDN terminal adaptors that support
V.25 bis dialing. V.25 bis is a CCITT recommendation for initiating
calls using an automatic calling unit (ACU).
Dial Backup:
The DECbrouter 90 supports dial backup service which provides protection
against WAN downtime by allowing you to configure a backup serial line
via a circuit switched connection.
To conifgure dial backup, associate a secondary serial interface as a
backup to a primary serial interface. This feature reqires that an
external modem, CSU/DSU device, or ISDN terminal adaptor attached to a circuit
switched service be connected on the secondary serial interface. The
external device must be capable of responding to a DTR signal (DTR active)
by auto-dialing a connection to a preconfigured remote sit.
|