Showing posts with label NETWORK PROTOCOLS. Show all posts
Showing posts with label NETWORK PROTOCOLS. Show all posts

Sunday, April 17, 2011

OVERVIEW OF ISDN

ISDN Concept
The concept of ISDN is best introduced by considering it from several different
viewpoints:
* Principles of ISDN
* The user interface
* Objectives
* Services
Principles of ISDN
Standards for ISDN have been defined by ITU-T (formerly CCITT), a topic that we
explore later in this section. Table A.l, which is the complete text of one of the
TABLE A.1 Recommendation 1.120 (1988).
1 Principles of ISDN
1.1 The main feature of the ISDN concept is the support of a wide range of voice and nonvoice applications
in the same network. A key element of service integration for an ISDN is the provision of
a range of services (see Part I1 of the I-Series in this Fascicle) using a limited set of connection
types and multipurpose user-network interface arrangements (see Parts 111 and IV of the I-Series
in Fascicle 111.8).
1.2 ISDNs support a variety of applications including both switched and non-switched connections.
Switched connections in an ISDN include both circuit-switched and packet-switched connections
and their concatenations.
1.3 As far as practicable, new services introduced into an ISDN should be arranged to be compatible
with 64 kbitls switched digital connections.
1.4 An ISDN will contain intelligence for the purpose of providing service features, maintenance and
network management functions. This intelligence may not be sufficient for some new services and
may have to be supplemented by either additional intelligence within the network, or possibly
compatible intelligence in the user terminals.
1.5 A layered protocol structure should be used for the specification of the access to an ISDN. Access
from a user to ISDN resources may vary depending upon the service required and upon the status
of implementation of national ISDNs.
1.6 It is recognized that ISDNs may be implemented in a variety of configurations according to specific
national situations.
2 Evolution of ISDNs
2.1 ISDNs will be based on the concepts for telephone IDNs and may evolve by progressively incorporating
additional functions and network features including those of any other dedicated networks
such as circuit-switching and packet-switching for data so as to provide for existing and
new services.
2.2 The transition from an existing network to a comprehensive ISDN may require a period of time
extending over one or more decades. During this period arrangements must be developed for the
networking of services on ISDNs and services on other networks (see Part V).
2.3 In the evolution towards an ISDN, digital end-to-end connectivity will be obtained via plant and
equipment used in existing networks, such as digital transmission, time-division multiplex switching
andlor space-division multiplex switching. Existing relevant recommendations for these constituent
elements of an ISDN are contained in the appropriate series of recommendations of CCI'M and
of CCIR.
2.4 In the early stages of the evolution of ISDNs, some interim user-network arrangements may need
to be adopted in certain countries to facilitate early penetration of digital service capabilities.
Arrangements corresponding to national variants may comply partly or wholly with I-Series Recommendations.
However, the intention is that they not be specifically included in the I-Series.
2.5 An evolving ISDN may also include at later stages switched connections at bit rates higher and
lower than 64 kbitls.
ISDN-related standards, states the principles of ISDN from the point of view of
CCITT. Let us look at each of these points in turn:
1. Support of voice and nonvoice applications using a limited set of standardized
facilities. This principle defines both the purpose of ISDN and the means
of achieving it. The ISDN supports a variety of services related to voice communications
(telephone calls) and nonvoice communications (digital data
exchange). These services are to be provided in conformance with standards
(ITU-T recommendations) that specify a small number of interfaces and data
transmission facilities.
2. Support ,for switched and nonswitched applications. ISDN supports both circuit
switching and packet switching. In addition, ISDN supports nonswitched
services in the form of dedicated lines.
3. Reliance on 64-kbps connections. ISDN provides circuit-switched and packetswitched
connections at 64 kbps; this is the fundamental building block of
ISDN. This rate was chosen because, at the time, it was the standard rate for
digitized voice, and, hence, was being introduced into the evolving integrated
digital networks (IDNs). Although this data rate is useful, it is unfortunately
restrictive to rely solely on it. Future developments in ISDN will permit
greater flexibility.
4. Intelligence in the network. An ISDN is expected to be able to provide sophisticated
services beyond the simple setup of a circuit-switched call.
5. Layered protocol architecture. The protocols for user access to ISDN exhibit a
layered architecture and can be mapped into the OSI model. This procedure
has a number of advantages:
Standards already developed for OSI-related applications may be used
on ISDN. An example is X.25 level 3 for access to packet-switching services
in ISDN.
New ISDN-related standards can be based on existing standards, reducing
the cost of new implementations. An example is LAPD, which is
based on LAPB.
Standards can be developed and implemented independently for various
layers and functions within a layer; this allows for the gradual implementation
of ISDN services at a pace appropriate for a given provider or a
given customer base.
6. Variety of configurations. More than one physical configuration is possible for
implementing ISDN; this allows for differences in national policy (singlesource
versus competition), in the states of technology, and in the needs and
existing equipment of the customer base.
The User Interface
Figure A.l is a conceptual view of the lSDN from a user, or customer, point of view.
The user has access to the ISDN by means of a local interface to a "digital pipe" of
a certain bit rate. Pipes of various sizes are available to satisfy differing needs. For
example, a residential customer may require only sufficient capacity to handle a
telephone and a videotex terminal. An office will undoubtedly wish to connect to
the ISDN via an on-premise digital PBX, and will require a much higher capacity
pipe.
At any given point in time, the pipe to the user's premises has a fixed capacity,
but the traffic on the pipe may be a variable mix up to the capacity limit. Thus,
a user may access circuit-switched and packet-switched services, as well as other services,
in a dynamic mix of signal types and bit rates. To provide these services, the
ISDN requires rather complex control signals to instruct it how to sort out the timeA.
l / OVERVIEW OF ISDN 743
Local area network
(LAN)
FIGURE A.l Conceptual view of ISDN connection features.
multiplexed data and provide the required services. These control signals are also
multiplexed onto the same digital pipe.
An important aspect of the interface is that the user may, at any time, employ
less than the maximum capacity of the pipe, and will be charged according to the
capacity used rather than "connect time." This characteristic significantly diminishes
the value of current user design efforts that are geared to optimize circuit
utilization by use of concentrators, multiplexers, packet switches, and other linesharing
arrangements.
Objectives
Activities currently under way are leading to the development of a worldwide
ISDN. This effort involves national governments, data processing and communications
companies, standards organizations, and other agencies. Certain common
objectives are, by and large, shared by this disparate group. We list here the key
objectives:
Standardization. It is essential that a single set of ISDN standards be provided
to permit universal access and to permit the development of cost-effective
equipment.
Transparency. The most important service to be provided is a transparent
transmission service, thereby permitting users to develop applications and
protocols with the confidence that they will not be affected by the underlying
ISDN.
Separation of competitive functions. It must be possible to separate out functions
that could be provided competitively as opposed to those that are fun744
APPENDIX A / ISDN AND BROADBAND ISDN
damentally part of the ISDN. In many countries, a single, government-owned
entity provides all services. Some countries desire (in the case of the United
States, require) that certain enhanced services be offered competitively (e.g.,
videotex, electronic mail).
@ Leased and switched services. The ISDN should provide dedicated point-topoint
services as well as switched services, thereby allowing the user to optimize
implementation of switching and routing techniques.
@ Cost-related tariffs. The price for ISDN service should be related to cost, and
should be independent of the type of data being carried. One type of service
should not be in the position of subsidizing others.
Smooth migration. The conversion to ISDN will be gradual, and the evolving
network must coexist with existing equipment and services. Thus, ISDN interfaces
should evolve from current interfaces, and provide a migration path
for users.
@ Multiplexed support. In addition to providing low-capacity support to individual
users, multiplexed support must be provided to accommodate userowned
PBX and local network equipment.
There are, of course, other objectives that could be named. Those listed above
are certainly among the most important and widely accepted, and each helps to
define the character of the ISDN.
Architecture
Figure A.2 is a block diagram of ISDN. ISDN supports a new physical connecter for
users, a digital subscriber loop (link from end user to central or end office), and
modifications to all central office equipment.
The area to which most attention has been paid by standards organizations is
that of user access. A common physical interface has been defined to provide, in
essence, a DTE-DCE connection. The same interface should be usable for telephone,
computer terminal, and videotex terminal. Protocols are needed for the
exchange of control information between user device and the network. Provision
must be made for high-speed interfaces to, for example, a digital PBX or a LAN.
The subscriber loop portion of today's telephone network consists of twisted
pair links between the subscriber and the central office, carrying 4-kHz analog signals.
Under the ISDN, one or two twisted pairs are used to provide a basic fullduplex
digital communications link.
The digital central office connects the numerous ISDN subscriber loop signals
to the IDN. In addition to providing access to the circuit-switched network, the central
office provides subscriber access to dedicated lines, packet-switched networks,
and time-shared, transaction-oriented computer services. Multiplexed access via
digital PBX and LAN must also be accommodated.
Standards
The development of ISDN is governed by a set of recommendations issued by
ISDN, called the I-series Recommendations. These Recommendations, or stanA.
l / OVERVIEW OF ISDN 745
Subscriber loop- I
ISDN channel structures: I
I
Basic = 64 kbps + 64 kbps + 16 kbps I
Primary = multiplexed 64 kbps channels I
I
I
-_ I! swDiticghietadl bcaircckubiot-n e
FIGURE A.2 Block diagram of ISDN functions.
Common
phys~cal
interface
dards, were first issued in 1984. A more complete set was issued in 1988. Most of the
Recommendations have been updated, at irregular intervals, since that time. The
bulk of the description of ISDN is contained in the I-series Recommendations, with
some related topics covered in other Recommendations. The characterization of
ISDN contained in these Recommendations is centered on three main areas:
- . A
ISDN I
I
central
office
1. The standardization of services offered to users, so as to enable services to be
internationally compatible.
2. The standardization of user-network interfaces, so as to enable terminal
equipment to be portable, and to assist in (1).
3. The standardization of ISDN capabilities to the degree necessary to allow
user-network and network-network interworking, and thus achieve (1)
and (2).
The I-series Recommendations are broken up into six main groupings, labeled
1.100 through 1.600.
1.100 Series-General Concepts
The 1.100 series serves as a general introduction to ISDN. The general structure of
the ISDN recommendations is presented as well as a glossary of terms. 1.120 provides
an overall description of ISDN and the expected evolution of ISDNs. 1.130
introduces terminology and concepts that are used in the 1.200 series to specify
services.
746 APPENDIX A / ISDN AND BROADBAND ISDN
1.200 Series-Service Capabilities
The 1.200 series is in a sense the most important part of the ITU-T ISDN recommendations.
Here, the services to be provided to users are specified. We may look
on this as a set of requirements that the ISDN must satisfy. In the ISDN glossary ,
(1.112), the term service is defined as
That which is offered by an Administration or recognized private operating
agency (RPOA) to its customers in order to satisfy a specific telecommunication
requirement.
Although this is a very general definition, the term "service" has come to have a very
specific meaning in ITU-T, a meaning that is somewhat different from the use of that
term in an OSI context. For ITU-T, a standardized service is characterized by
Complete, guaranteed end-to-end compatibility
ITU-T-standardized terminals, including procedures
Listing of the service subscribers in an international directory
ITU-T-standardized testing and maintenance procedures
Charging and accounting rules
There are three fully standardized ITU-T services: telegraphy, telephony, and
data. There are four additional telematic services in the process of being standardized:
teletex, facsimile, videotex, and message handling. The goal with all of these
services is to ensure high-quality international telecommunications for the end user,
regardless of the make of the terminal equipment and the type of network used
nationally to support the service.
1.300 Series-Network Aspects
Whereas the 1.200 series focuses on the user, in terms of the services provided, the
1.300 series focuses on the network, in terms of how the network goes about providing
those services. A protocol reference model is presented that, while based on
the 7-layer OSI model, attempts to account for the complexity of a connection that
may involve two or more users (e.g., a conference call) plus a related commonchannel
signaling dialogue. Issues such as numbering and addressing are covered.
There is also a discussion of ISDN connection types.
1.400 Series-User-Network Interfaces
The 1.400 series deals with the interface between the user and the network. Three
major topics are addressed:
Physical configurations. The issue of how ISDN functions are configured into
equipment. The standards specify functional groupings and define reference
points between those groupings.
Transmission rates. The data rates and combinations of data rates to be
offered to the user.
Protocol specifications. The protocols at OSI layers 1 through 3 that specify
the user-network interaction.
A.2 / ISDN CHANNELS 747
1.500 Series-Internetwork Interfaces
ISDN supports services that are also provided on older circuit-switched and packetswitched
networks. Thus, it is necessary to provide interworking between an ISDN
and other types of networks to allow communications between terminals belonging
to equivalent services offered through different networks. The 1.500 series deals
with the various network issues that arise in attempting to define interfaces between
ISDN and other types of networks.
1.600 Series-Maintenance Principles
This series provides guidance for maintenance of the ISDN subscriber installation,
the network portion of the ISDN basic access, primary access, and higher data-rate
services. Maintenance principles and functions are related to the reference configuration
and general architecture of ISDN. A key function that is identified in the
series is loopback. In general, loopback testing is used for failure localization and
verification.
A.2

What is RMON ? Remote Monitoring

Remote Monitoring (RMON) is a standard monitoring specification that enables various network monitors and console systems to exchange network-monitoring data. RMON provides network administrators with more freedom in selecting network-monitoring probes and consoles with features that meet their particular networking needs. This chapter provides a brief overview of the RMON specification, focusing on RMON groups.
The RMON specification defines a set of statistics and functions that can be exchanged between RMON-compliant console managers and network probes. As such, RMON provides network administrators with comprehensive network-fault diagnosis, planning, and performance-tuning information.
RMON was defined by the user community with the help of the Internet Engineering Task Force (IETF). It became a proposed standard in 1992 as RFC 1271 (for Ethernet). RMON then became a draft standard in 1995 as RFC 1757, effectively obsoleting RFC 1271.
Figure 51-1 illustrates an RMON probe capable of monitoring an Ethernet segment and transmitting statistical information back to an RMON-compliant console.

Figure 51-1: An RMON probe can send statistical information to an RMON console.


RMON Groups

RMON delivers information in nine RMON groups of monitoring elements, each providing specific sets of data to meet common network-monitoring requirements. Each group is optional so that vendors do not need to support all the groups within the Management Information Base (MIB). Some RMON groups require support of other RMON groups to function properly. Table 51-1 summarizes the nine monitoring groups specified in the RFC 1757 Ethernet RMON MIB.

Table 51-1:
RMON Monitoring Groups
 
RMON Group Function Elements
Statistics
Contains statistics measured by the probe for each monitored interface on this device.
Packets dropped, packets sent, bytes sent (octets), broadcast packets, multicast packets, CRC errors, runts, giants, fragments, jabbers, collisions, and counters for packets ranging from 64-128, 128-256, 256-512, 512-1024, and 1024-1518 bytes.
History
Records periodic statistical samples from a network and stores them for later retrieval .
Sample period, number of samples, item(s) sampled.
Alarm
Periodically takes statistical samples from variables in the probe and compares them with previously configured thresholds. If the monitored variable crosses a threshold, an event is generated.
Includes the alarm table and requires the implementation of the event group. Alarm type, interval, starting threshold, stop threshold.
Host
Contains statistics associated with each host discovered on the network.
Host address, packets, and bytes received and transmitted, as well as broadcast, multicast, and error packets.
HostTopN
Prepares tables that describe the hosts that top a list ordered by one of their statistics. The available statistics are samples of one of their base statistics over an interval specified by the management station. Thus, these statistics are rate-based.
Statistics, host(s), sample start and stop periods, rate base, duration.
Matrix
Stores statistics for conversations between sets of two addresses. As the device detects a new conversation, it creates a new entry in its table.
Source and destination address pairs and packets, bytes, and errors for each pair.
Filters
Enables packets to be matched by a filter equation. These matched packets form a data stream that might be captured or might generate events.
Bit-filter type (mask or not mask), filter expression (bit level), conditional expression (and, or, not) to other filters.
Packet Capture
Enables packets to be captured after they flow through a channel.
Size of buffer for captured packets, full status (alarm), number of captured packets.
Events
Controls the generation and notification of events from this device.
Event type, description, last time event sent.

CMIP (Common Management Information Protocol)


CMIP is an OSI (Open Systems Interconnection) model that defines how to create a common network management system. While both CMIP and the Internet SNMP (Simple Network Management Protocol) define network management standards, CMIP is more complex. In fact, CMIP is really only used by some telecommunications service providers for network management. In contrast, SNMP is an Internet protocol specifically designed for TCP/IP networks that is commonly used on corporate networks.
The OSI management model defines systems that are managed, and it defines management systems. Managed systems run agents that gather information about processes and communicate with management systems.
A process runs in nodes that collect management information from processes running at each layer of the OSI protocol stack. Changes can also be applied in the layers. Each node has a MIB (management information base), which is a collection of objects that hold node information.
A SMAP (System Management Application Process) provides the interface through which MIBs share information. SMAPs talk to other SMAPs over the network. A SMAE (System Management Application Entity) supports SMAP communication, and SMAEs use CMIP to exchange data between nodes. CMIP forms a road map for designing a network management system, but the actual interface specifications are in CMIS (Common Management Information Service).
CMIP is divided into the following functions:
  • Accounting management    Monitor and charge for network usage.
  • Configuration management    View and manage system resources and management information.
  • Fault management    Detects and corrects faults in the network.
  • Performance management    Monitor and tune network performance.
  • Security    Authenticate users, detect intrusions, and transmit data securely.
CMIS (Common Management Information Service) provides a way to share management information in the CMIP environment.A relatively new protocol, CIM (Common Information Model), is bringing interoperability among management protocols in general. It has many new features that go beyond features in SNMP and CMIP, while providing backward compatibility.

What is SNMP ? Simple Network Management Protocol

The Simple Network Management Protocol(SNMP)is an application-layer protocol that facilitates the exchange of management information between network devices. It is part of the Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. SNMP enables network administrators to manage network performance, find and solve network problems, and plan for network growth.
Two versions of SNMP exist: SNMP Version 1 (SNMPv1) and SNMP Version 2 (SNMPv2). Both versions have a number of features in common, but SNMPv2 offers enhancements, such as additional protocol operations. Standardization of yet another version of SNMP---SNMP Version 3 (SNMPv3)---is pending. This chapter provides descriptions of the SNMPv1 and SNMPv2 protocol operations. Figure 52-1 illustrates a basic network managed by SNMP.

Figure 52-1: SNMP facilitates the exchange of network information between devices.


SNMP Basic Components

An SNMP managed network consists of three key components: managed devices, agents, and network-management systems (NMSs).
A managed device is a network node that contains an SNMP agent and resides on a managed network. Managed devices collect and store management information and make this information available to NMSs using SNMP. Managed devices, sometimes called network elements, can be routers and access servers, switches and bridges, hubs, computer hosts, or printers.
An agent is a network-management software module that resides in a managed device. An agent has local knowledge of management information and translates that information into a form compatible with SNMP.
An NMS executes applications that monitor and control managed devices. NMSs provide the bulk of the processing and memory resources required for network management. One or more NMSs must exist on any managed network.
Figure 52-2 illustrates the relationship between these three components.

Figure 52-2: An SNMP managed network consists of managed devices, agents, and NMSs.


SNMP Basic Commands

Managed devices are monitored and controlled using four basic SNMP commands: read, write, trap, and traversal operations.
Traversal operations are used by the NMS to determine which variables a managed device supports and to sequentially gather information in variable tables, such as a routing table.

SNMP Management Information Base (MIB)

A Management Information Base (MIB) is a collection of information that is organized hierarchically. MIBs are accessed using a network-management protocol such as SNMP. They are comprised of managed objects and are identified by object identifiers.
A managed object (sometimes called a MIB object, an object, or a MIB) is one of any number of specific characteristics of a managed device. Managed objects are comprised of one or more object instances, which are essentially variables.
Two types of managed objects exist: scalar and tabular. Scalar objects define a single object instance. Tabular objects define multiple related object instances that are grouped together in MIB tables.
An example of a managed object is at Input, which is a scalar object that contains a single object instance, the integer value that indicates the total number of input AppleTalk packets on a router interface.
An object identifier (or object ID) uniquely identifies a managed object in the MIB hierarchy. The MIB hierarchy can be depicted as a tree with a nameless root, the levels of which are assigned by different organizations. Figure 52-3 illustrates the MIB tree.

Figure 52-3: The MIB tree illustrates the various hierarchies assigned by different organizations.


The top-level MIB object IDs belong to different standards organizations, while lower-level object IDs are allocated by associated organizations.
Vendors can define private branches that include managed objects for their own products. MIBs that have not been standardized typically are positioned in the experimental branch.
The managed object at Input can be uniquely identified either by the object name--- iso.identified-organization.dod.internet.private.enterprise.cisco.temporary variables.AppleTalk.atInput---or by the equivalent object descriptor: 1.3.6.1.4.1.9.3.3.1.

SNMP and Data Representation

SNMP must account for and adjust to incompatibilities between managed devices. Different computers use different data-representation techniques, which can compromise the ability of SNMP to exchange information between managed devices. SNMP uses a subset of Abstract Syntax Notation One (ASN.1) to accommodate communication between diverse systems.

SNMP Version 1 (SNMPv1)

SNMP Version 1 (SNMPv1) is the initial implementation of the SNMP protocol. It is described in Request For Comments (RFC) 1157 and functions within the specifications of the Structure of Management Information (SMI). SNMPv1 operates over protocols such as User Datagram Protocol (UDP), Internet Protocol (IP), OSI Connectionless Network Service (CLNS), AppleTalk Datagram-Delivery Protocol (DDP), and Novell Internet Packet Exchange (IPX). SNMPv1 is widely used and is the de facto network-management protocol in the Internet community.

SNMPv1 and Structure of Management Information (SMI)

The Structure of Management Information (SMI) defines the rules for describing management information, using Abstract Syntax Notation One (ASN.1). The SNMPv1 SMI is defined in Request For Comments (RFC) 1155. The SMI makes three key specifications: ASN.1 data types, SMI-specific data types, and SNMP MIB tables.
SNMPv1 and ASN1 Data Types
The SNMPv1 SMI specifies that all managed objects have a certain subset of Abstract Syntax Notation One (ASN.1) data types associated with them. Three ASN.1 data types are required: name, syntax, and encoding. The name serves as the object identifier (object ID). The syntax defines the data type of the object (for example, integer or string). The SMI uses a subset of the ASN.1 syntax definitions. The encoding data describes how information associated with a managed object is formatted as a series of data items for transmission over the network.
SNMPv1 and SMI-Specific Data Types
The SNMPv1 SMI specifies the use of a number of SMI-specific data types, which are divided into two categories: simple data types and application-wide data types.
Three simple data types are defined in the SNMPv1 SMI, all of which are unique values: integers, octet strings, and object IDs. The integer data type is a signed integer in the range of -2,147,483,648 to 2,147,483,647. Octet strings are ordered sequences of zero to 65,535 octets. Object IDs come from the set of all object identifiers allocated according to the rules specified in ASN.1.
Seven application-wide data types exist in the SNMPv1 SMI: network addresses, counters, gauges, time ticks, opaques, integers, and unsigned integers. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses. Counters are nonnegative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. Gauges are nonnegative integers that can increase or decrease but retain the maximum value reached. A time tick represents a hundredth of a second since some event. An opaque represents an arbitrary encoding that is used to pass arbitrary information strings that do not conform to the strict data typing used by the SMI. An integer represents signed integer-valued information. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI. An unsigned integer represents unsigned integer-valued information and is useful when values are always nonnegative. This data type redefines the integer data type, which has arbitrary precision in ASN.1 but bounded precision in the SMI.

SNMP MIB Tables

The SNMPv1 SMI defines highly structured tables that are used to group the instances of a tabular object (that is, an object that contains multiple variables). Tables are composed of zero or more rows, which are indexed in a way that allows SNMP to retrieve or alter an entire row with a single Get, GetNext, or Set command.

SNMPv1 Protocol Operations

SNMP is a simple request-response protocol. The network-management system issues a request, and managed devices return responses. This behavior is implemented by using one of four protocol operations: Get, GetNext, Set, and Trap. The Get operation is used by the NMS to retrieve the value of one or more object instances from an agent. If the agent responding to the Get operation cannot provide values for all the object instances in a list, it does not provide any values. The GetNext operation is used by the NMS to retrieve the value of the next object instance in a table or list within an agent. The Set operation is used by the NMS to set the values of object instances within an agent. The Trap operation is used by agents to asynchronously inform the NMS of a significant event.

SNMP Version 2 (SNMPv2)

SNMP Version 2 (SNMPv2) is an evolution of the initial version, SNMPv1. Originally, SNMPv2 was published as a set of proposed Internet standards in 1993; currently, it is a Draft Standard. As with SNMPv1, SNMPv2 functions within the specifications of the Structure of Management Information (SMI). In theory, SNMPv2 offers a number of improvements to SNMPv1, including additional protocol operations.

SNMPv2 and Structure of Management Information (SMI)

The Structure of Management Information (SMI) defines the rules for describing management information, using Abstract Syntax Notation One (ASN.1).
The SNMPv2 SMI is described in RFC 1902. It makes certain additions and enhancements to the SNMPv1 SMI-specific data types, such as including bit strings, network addresses, and counters. Bit strings are defined only in SNMPv2 and comprise zero or more named bits that specify a value. Network addresses represent an address from a particular protocol family. SNMPv1 supports only 32-bit IP addresses, but SNMPv2 can support other types of addresses as well. Counters are non-negative integers that increase until they reach a maximum value and then return to zero. In SNMPv1, a 32-bit counter size is specified. In SNMPv2, 32-bit and 64-bit counters are defined.

SMI Information Modules

The SNMPv2 SMI also specifies information modules, which specify a group of related definitions. Three types of SMI information modules exist: MIB modules, compliance statements, and capability statements. MIB modules contain definitions of interrelated managed objects. Compliance statements provide a systematic way to describe a group of managed objects that must be implemented for conformance to a standard. Capability statements are used to indicate the precise level of support that an agent claims with respect to a MIB group. An NMS can adjust its behavior toward agents according to the capabilities statements associated with each agent.

SNMPv2 Protocol Operations

The Get, GetNext, and Set operations used in SNMPv1 are exactly the same as those used in SNMPv2. SNMPv2, however, adds and enhances some protocol operations. The SNMPv2 Trap operation, for example, serves the same function as that used in SNMPv1. It, however, uses a different message format and is designed to replace the SNMPv1 Trap.
SNMPv2 also defines two new protocol operations: GetBulk and Inform. The GetBulk operation is used by the NMS to efficiently retrieve large blocks of data, such as multiple rows in a table. GetBulk fills a response message with as much of the requested data as will fit. The Inform operation allows one NMS to send trap information to another NMS and receive a response. In SNMPv2, if the agent responding to GetBulk operations cannot provide values for all the variables in a list, it provides partial results.

SNMP Management

SNMP is a distributed-management protocol. A system can operate exclusively as either an NMS or an agent, or it can perform the functions of both. When a system operates as both an NMS and an agent, another NMS might require that the system query managed devices and provide a summary of the information learned, or that it report locally stored management information.

SNMP Security

SNMP lacks any authentication capabilities, which results in vulnerability to a variety of security threats. These include masquerading, modification of information, message sequence and timing modifications, and disclosure. Masquerading consists of an unauthorized entity attempting to perform management operations by assuming the identity of an authorized management entity. Modification of information involves an unauthorized entity attempting to alter a message generated by an authorized entity so that the message results in unauthorized accounting management or configuration management operations. Message sequence and timing modifications occur when an unauthorized entity reorders, delays, or copies and later replays a message generated by an authorized entity. Disclosure results when an unauthorized entity extracts values stored in managed objects, or learns of notifiable events by monitoring exchanges between managers and agents. Because SNMP does not implement authentication, many vendors do not implement Set operations, thereby reducing SNMP to a monitoring facility.

SNMP Interoperability

As presently specified, SNMPv2 is incompatible with SNMPv1 in two key areas: message formats and protocol operations. SNMPv2 messages use different header and protocol data-unit (PDU) formats than SNMPv1 messages. SNMPv2 also uses two protocol operations that are not specified in SNMPv1. Furthermore, RFC 1908 defines two possible SNMPv1/v2 coexistence strategies: proxy agents and "bilingual" network-management systems.

Proxy Agents

An SNMPv2 agent can act as a proxy agent on behalf of SNMPv1 managed devices, as follows:
     
  • An SNMPv2 NMS issues a command intended for an SNMPv1 agent.
  • The NMS sends the SNMP message to the SNMPv2 proxy agent.
  • The proxy agent forwards Get, GetNext, and Set messages to the SNMPv1 agent unchanged.
  • GetBulk messages are converted by the proxy agent to GetNext messages and then are forwarded to the SNMPv1 agent.
  • The proxy agent maps SNMPv1 trap messages to SNMPv2 trap messages and then forwards them to the NMS.

Bilingual Network-Management System

Bilingual SNMPv2 network-management systems support both SNMPv1 and SNMPv2. To support this dual-management environment, a management application in the bilingual NMS must contact an agent. The NMS then examines information stored in a local database to determine whether the agent supports SNMPv1 or SNMPv2. Based on the information in the database, the NMS communicates with the agent using the appropriate version of SNMP.

SNMP Reference: SNMPv1 Message Formats

SNMPv1 messages contain two parts: a message header and a protocol data unit. Figure 52-4 illustrates the basic format of an SNMPv1 message.

Figure 52-4: An SNVPv1 message consists of a header and a PDU.


SNMPv1 Message Header

SNMPv1 message headers contain two fields: Version Number and Community Name. The following descriptions summarize these fields:

SNMPv1 Protocol Data Unit (PDU)

SNMPv1 PDUs contain a specific command (Get, Set, and so on) and operands that indicate the object instances involved in the transaction. SNMPv1 PDU fields are variable in length, as prescribed by Abstract Syntax Notation One (ASN.1). Figure 52-5 illustrates the fields of the SNMPv1 Get, GetNext, Response, and Set PDUs transactions.

Figure 52-5: SNMPv1 Get, GetNext, Response, and Set PDUs contain the same fields.


The following descriptions summarize the fields illustrated in Figure 52-5:

Trap PDU Format

Figure 52-6 illustrates the fields of the SNMPv1 Trap PDU.

Figure 52-6:
The SNMPv1 Trap PDU consists of eight fields.

The following descriptions summarize the fields illustrated in Figure 52-6:

SNMP Reference: SNMPv2 Message Format

SNMPv2 messages consist of a header and a PDU. Figure 52-7 illustrates the basic format of an SNMPv2 message.

Figure 52-7: SNMPv2 messages also consist of a header and a PDU.


SNMPv2 Message Header

SNMPv2 message headers contain two fields: Version Number and Community Name. The following descriptions summarize these fields:

SNMPv2 Protocol Data Unit (PDU)

SNMPv2 specifies two PDU formats, depending on the SNMP protocol operation. SNMPv2 PDU fields are variable in length, as prescribed by Abstract Syntax Notation One (ASN.1).
Figure 52-8 illustrates the fields of the SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs.

Figure 52-8: SNMPv2 Get, GetNext, Inform, Response, Set, and Trap PDUs contain the same fields.


The following descriptions summarize the fields illustrated in Figure 52-8:

GetBulk PDU Format

Figure 52-9 illustrates the fields of the SNMPv2 GetBulk PDU.

Figure 52-9:
The SNMPv2 GetBulk PDU consists of seven fields.

The following descriptions summarize the fields illustrated in Figure 52-9:

ATM - Concepts and Architecture


ATM - Concepts and Architecture


Cell-Relay provides a compromise between fixed synchronous allocation mechanisms and bursty, routable packet interfaces.

The Asynchronous Transfer Mode (ATM) protocols and architecture have managed to gather an impressive amount of market and media attention over the last several years. Intended as a technique to achieve a working compromise between the rigidity of the telecommunication synchronous architecture and packet network's unpredictable load behavior, ATM products are appearing for everything from high-speed switching to local area networking. ATM has caught the interest of both the telecommunications community as a broadband carrier for Integrated Services Digital Network (ISDN) networks as well as the computer industry, who view ATM as a strong candidate for high-speed Local Area Networking. This article covers the basic concepts involved in the ATM architecture.

At the core of the ATM architecture is a fixed length "cell." An ATM cell is a short, fixed length block of data that contains a short header with addressing information, followed by the upper layer traffic, or "payload." The cell structure, shown in Figure 1, is 53 octets long, with a 5 octet header, followed by 48 bytes of payload. While the short packet may seem to be somewhat inefficient in its ratio of overhead to actual data, it does have some distinct advantages over the alternatives. By fixing the length of each cell, the timing characteristics of the links and the corresponding network are regular and relatively easy to predict; predicting the dynamics of variable length packet switched networks isn't always easy. By using short cells, hardware based switching can be accomplished. Finally, the use of short cells provides an ability to transfer isochronous information with a short delay.

Figure 1 - ATM Cell Structure (UNI Format)



The information contained in the header of each cell is used to identify the circuit (in the context) of the local link, carries local flow control information, and includes error detection to prevent cells from being mis-routed. The remaining 48 octets are routed through the network to the destination using the circuit.

ATM has evolved over the last 5-10 years to include a wide range of support protocols. Routing and congestion management, have been particular areas of research. The early concepts of cell transfer networks revolved around the thought that users could "reserve" a pre-specified amount of traffic through a circuit on the network. Some amount of guaranteed throughput would be provided with an additional amount only as needed. Then, through this contract, traffic in excess of the pre-allocated bandwidth could be arbitrarily dropped if congestion problems occurred. However, the complexities of implementation have proven these techniques to be far too difficult. Several vendors have proposed flow control architectures that involve more active windowing protocols between the switches for data traffic.

ATM Architecture

As in the case of many large systems, there are a range of components and connections involved in the ATM networks. Figure 2 shows an example network architecture. All connections in the ATM network are point-to-point, with traffic being switched through the network by the switching nodes. Two types of networks are included in the ATM architecture, Public Networks and Private Networks. Private Networks, often referred to as Customer Premises Networks, are typically concerned with end-user connections, or bridging services to other types of networks including circuit switched services, frame relay, and voice subsystems. The interface between the components in the Private Networks is referred to as the Private User Network Interface (UNI). ATM also extends into the wider area Public Networks.

Interfaces between the Public and Private network switches conform to the Public UNI. Interfaces between the switches within the Public network are the Network Node Interface (NNI). Specifications for both the Public and Private UNI can be found in the ATM Forum's publication "ATM User-Network Interface (UNI) Specification." The private networks often permit the use of lower speed short haul interconnects that are useful in LAN environments, but not of great use in wider area public networks. Three types of NNI have been developed, NNI-ISSI that connects switches in the same Local Area Transport Area (LATA), the NNI-ICI, that connects ATM networks of different carriers (InterCarrier), and finally, a Private NNI that permits the connection of different switches in a private network.

Figure 2 - ATM Sample Network Architecture


Protocol Reference Model

There is more to the ATM standards than the ATM cell format alone. Specifications exist to describe acceptable physical signaling, call control, and upper layer payload formats. Figure 3 shows the hierarchy of protocols involved in ATM. Mapping roughly to layers 1 and 2 of the OSI model, ATM is broken into 3 distinct layers. At the bottom, several classes of physical layers have been adapted to support the different types of ATM applications. The ATM layer provides the cell-switching and routing services. Application services rely on the ATM Adaptation Layer (AAL) that serves two purposes, to provide a common framework for the segmentation and reassembly of larger data sets into the ATM cells and to provide service specific mechanisms for the transport of different types of data. Four different classes of traffic are supported by the AAL ranging from straight circuit switched data through packet mode applications. Many of the early implementations of ATM have been focused on the packet mode services, often as a backbone for Frame Relay services. Typically, the AAL should be viewed as an internal, software interface to bridge end-user services over ATM. There is typically a good bit of work required to bind other protocols to the ATM stack.

Figure 3 - ATM Protocol Architecture


Traffic Flow Through The Network

A two tiered addressing scheme is used with the following elements being involved in the addressing assignments:
  • Virtual Channel: A virtual channel represents the flow of a single network connection data flow between 2 ATM end users. The ATM standards define this as a unidirectional connection between 2 end-points on the network
  • Virtual Path: A virtual path is used to carry one or more virtual channels through the network. It is represented as a bundle of channels between the two end-points.
This logical grouping of paths and channels provides some flexibility in managing the addressing of the flow of information through an ATM network. Figure 4 shows a sample configuration of a network with an assortment of Virtual Paths and Virtual Channels. As can be seen in the figure, each virtual path contains one or more virtual channels. It is important to note that the actual numbers assigned to each of the paths and channels are used only to represent a Virtual Path or Channel segment that exists between two adjacent nodes of the network. These values are established when the actual Virtual Channel Connections (VCC) are established. The number of Paths and Channels over a single link are limited by the ATM cell format. This limitation helps to explain why there are differences between the UNI and NNI formats. The NNI format replaces the 4 bits of the Generic Flow Control indication with additional VPI bits, extending the number of possible paths over the NNI from 256 to 4096.

Figure 4 - Example ATM Circuit and Path Connections



Figure 5 shows the formats for the UNI and NNI cells. The fields in the ATM Cells are:
  • GFC - (Generic Flow Control) used only in the UNI format. No general purpose services have been assigned to this field, and it is significant for only the local site. This flow control information is not carried from end-to-end. Two modes have been used for GFC based flow control, "uncontrolled access" and "controlled access." in uncontrolled access, this field is set to all zeroes. In controlled access mode, this field is set when congestion has occurred. The receiving equipment will report instances in which the GFC has been set a significant number of times to Layer Management.
  • VPI/VCI - (Virtual Path Identifier/Virtual Channel Identifier). The distribution of bits between these two fields can be negotiated between the user and network equipment. Referring back to Figure 4, these identifiers are used to tag only the portion of the path/circuit connection over a single link. It is the combination of all of the individual paths and circuits that comprise the connection.
  • PT - (Payload Type) Indicates whether or not the cell contains use information or Layer Management Information. It also carries implicit congestion information.
  • CLP - (Cell Loss Priority). Indicates the cell's priority in the ATM selective loss algorithm. Set by the initiating equipment, when this set to 0, the cell is given preference over cells with CLP set to 1.
  • HEC - (Header Error Control). Provides a capability to correct all single bit errors in the cell header as well as the detection of the majority of multiple-bit errors. The use of this field is up to interpretation of the equipment designers. If most errors are likely to be single bit errors, it can be used for error correction. Using the field for error correction does carry some level of risk of introducing unwanted errant traffic on the network should a mistake be made in the correction process.
Note that the circuit and path identification fields are used to indicate the path that each cell is to take through the network. The identifiers carried in the cells carry only the information required to identify the cell's route to the receiving switch or end-point, they are not network addresses as is found in the case of IP or OSI networks.

Figure 5 - ATM Cell Formats



This article covers some of the important general concepts in the ATM architecture, but scratches just the surface. Other important areas of the ATM architecture include how it is mapped to the various physical interfaces, the ATM Adaptation Layer, signaling protocols, layer management, along with switching strategies.

Friday, April 15, 2011

USER DATA TRANSFER

USER DATA TRANSFER
The operation of frame relay for user data transfer is best explained by beginning
with the frame format, illustrated in Figure 10.7a. This is the format defined for the
minimum-function LAPF protocol (known as LAPF core protocol). The format is
similar to that of LAPD and LAPB with one obvious omission: There is no control
field.
0
0
9
This has the following implications:
There is only one frame type, used for carrying user data. There are no control
frames.
It is not possible to use inband signaling; a logical connection can only carry
user data.
It is not possible to perform flow control and error control, as there are no
sequence numbers.
The flag and frame check sequence (FCS) fields function as in LAPD and
LAPB. The information field carries higher-layer data. If the user selects to implement
additional data link control functions end-to-end, then a data link frame can
Flag [ Address I Information I FCS I Flag
(a) Frame format
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Uo~eDr LCI I C/R I E A O I
(b) Address field-2 octets (default)
. L I -
DLCI IFECN~BECN~ DE I EA o
Upper DLCI
Lower DLCI or DL-Core control I DIC I EA 1 I
Upper DLCI
DLCI IFECN~BECN I I I I
(c) Address field-3 octets
Lower DLCI ~FECN~BECND~E I EA 1
CIR
DLCI
LEGEND
EA Address field extension bit
CIR Commandlresponse bit
EA 0 CIR
DE
EA 0
BECN
DLCI
EAO
EAO
Lower DLCI or DL-Core control I DIC I EA 1
FECN Forward explicit congestion notification DIC
DE
(d) Address field& octets
Backward explit congestion notification
Data link congestion identifier
DLCI or CORE control indicator
Data link congestion identifier
FIGURE 10.7 LAPF-core formats.
3 14 CHAPTER 10 / FRAME RELAY
be carried in this field. Specifically, a common selection will be to use the full LAPF
protocol (known as LAPF control protocol) in order to perform functions above
the LAPF core functions. Note that the protocol implemented in this fashion is
strictly between the end subscribers and is transparent to ISDN.
The address field has a default length of 2 octets and may be extended to 3 or
4 octets. It carries a data link connection identifier (DLCI) of 10, 17, or 24 bits. The
DLCI serves the same function as the virtual circuit number in X.25: It allows multiple
logical frame relay connections to be multiplexed over a single channel. As in
X.25, the connection identifier has only local significance; each end of the logical
connection assigns its own DLCI from the pool of locally unused numbers: and the
network must map from one to the other. The alternative, using the same DLCI on
both ends, would require some sort of global management of DLCI values.
The length of the address field, and hence of the DLCI, is determined by the
address field extension (EA) bits. The C/R bit is application-specific and is not used
by the standard frame relay protocol. The remaining bits in the address field have
to do with congestion control, and are discussed in Section 10.6.
Figure 10.8 is another view of the protocols involved in frame relay, this time
from the point of view of the individual frame relay connections. There is a common
physical layer and frame relay sublayer. An optional layer-2 data link control
protocol may be included above the frame relay sublayer. This selection is application-
dependent and may differ for different frame relay connections (DLC-i). If
frame relay call control messages are carried in frame relay frames, they are carried
on DLCI 0, which provides a frame relay connection between the user and the
frame handler. DLCI 8191 is dedicated to management procedures.
DLCI 0
DLCI k
Higher
layers
DLC-k
DLCI m DLCI n
Higher . . . layers
DLC-m
I
Frame relay sublayer
Physical layer
Higher
layers
DLCI 8191
procs
!DLC-n Q.922 i Layer 2
FIGURE 10.8 Multiplexing at the frame relay sublayer.
10.5 / NETWORK FUNCTION 315
The frame relaying function performed by ISDN, or any network that supports
frame relaying, consists of the routing of frames with the format of Figure 10.7a,
based on their DLCI values.
Figure 10.9 suggests the operation of a frame handler in a situation in which a
number of users are directly connected to the same frame handler over different
physical channels. The operation could just as well involve relaying a frame through
two or more frame handlers. In this figure, the decision-making logic is shown conceptually
as a separate module: the frame relay control point. This module is
responsible for making routing decisions.
Typically, routing is controlled by entries in a connection table based on DLCI
that map incoming frames from one channel to another. The frame handler switches
a frame from an incoming channel to an outgoing channel, based on the appropriate
entry in the connection table, and translates the DLCI in the frame before transmission.
For example, incoming frames from TE B on logical connection 306 are
retransmitted to TE D on logical connection 342. The figure also shows the multiplexing
function: Multiple logical connections to TE D are multiplexed over the
same physical channel.
Note also that all of the TEs have a logical connection to the frame relay control
point with a value of DLCI = 0. These connections are reserved for in-channel
call control, to be used when 1.451lQ.931 on the D-channel is not used for frame
relay call control.
Frame relay m
Frame handle1
FIGURE 10.9 Frame handler operation.
As part of the frame relay function, the FCS of each incoming frame is
checked. When an error is detected, the frame is simply discarded. It is the responsibility
of the end users to institute error recovery above the frame relay protocol.