home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Standards
/
CD1.mdf
/
nist
/
oiw
/
agreemnt
/
1993
/
03w_9312.txt
< prev
next >
Wrap
Text File
|
1994-02-09
|
25KB
|
990 lines
Working Implementation
Agreements for Open Systems
Interconnection Protocols:
Part 3 - Network Layer
Output from the December 1993 Open Systems Environment
Implementors' Workshop (OIW)
SIG Chair: Fred Burg, AT&T
SIG Editor: Brenda Gray, NIST
PART 3 - NETWORK LAYER December 1993 (Working)
Foreword
This part of the Working Implementation Agreements was prepared
by the Lower Layers Special Interest Group (LLSIG) of the Open
Systems Environment Implementors' Workshop (OIW). See Part 1 -
Workshop Policies and Procedures in the "Draft Working
Implementation Agreements Document" for the workshop charter.
Text in this part has been approved by the Plenary of the
Workshop. This part replaces the previously existing part on
this subject.
Future changes and additions to this version of these Implementor
Agreements will be published as a new part. Deleted and replaced
text will be shown as struck. New and replacement text will be
shown as shaded.
ii
PART 3 - NETWORK LAYER December 1993 (Working)
Table of Contents
Part 3 - Network Layer . . . . . . . . . . . . . . . . . . . 1
0 Introduction . . . . . . . . . . . . . . . . . . . . . . 1
1 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Normative References . . . . . . . . . . . . . . . . . . 1
3 Status . . . . . . . . . . . . . . . . . . . . . . . . . 1
4 Errata . . . . . . . . . . . . . . . . . . . . . . . . . 1
5 Connectionless-Mode Network Service (CLNS) . . . . . . . 1
5.1 ISO 8473 . . . . . . . . . . . . . . . . . . . . . . 1
5.1.1 Subsets of the protocol . . . . . . . . . . 1
5.1.2 Mandatory Functions of ISO 8473 . . . . . . 1
5.1.3 Optional Functions of ISO 8473 . . . . . . 1
5.2 Provision of CLNS over Local Area Networks . . . . . 5
5.3 Provision of CLNS over X.25 Subnetworks . . . . . . 5
5.4 Provision of CLNS over ISDN . . . . . . . . . . . . 5
5.5 Provision of CLNS over Point-to-Point Links . . . . 5
6 Connection-Mode Network Service . . . . . . . . . . . . . 5
6.1 Mandatory Method of Providing CONS . . . . . . . . . 5
6.1.1 General . . . . . . . . . . . . . . . . . . 5
6.1.2 X.25 WAN . . . . . . . . . . . . . . . . . 5
6.1.3 LANs . . . . . . . . . . . . . . . . . . . 5
6.1.4 ISDN . . . . . . . . . . . . . . . . . . . 5
6.1.5 Priority . . . . . . . . . . . . . . . . . 6
6.2 Additional Option: Provision of CONS over X.25 1980
Subnetworks . . . . . . . . . . . . . . . . . . . . 6
6.3 Agreements on Protocols . . . . . . . . . . . . . . 6
6.3.1 ISO 8878 . . . . . . . . . . . . . . . . . 6
6.3.2 Subnetwork Dependent Convergence Protocol
(ISO 8878/Annex A) . . . . . . . . . . . . 6
6.4 Interworking . . . . . . . . . . . . . . . . . . . . 6
7 Addressing . . . . . . . . . . . . . . . . . . . . . . . 6
8 Routing . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1 ISO 9542 End System to Intermediate System Routing . 7
8.2 ISO 10030 End System to Intermediate System Routing 7
8.3 Intra-Domain Intermediate Systems to Intermediate
Systems Routing . . . . . . . . . . . . . . . . . . 7
8.3.1 Static Intra-Domain Routing . . . . . . . . 7
iii
PART 3 - NETWORK LAYER December 1993 (Working)
8.3.2 Dynamic Intra-Domain Routing . . . . . . . 7
8.4 Inter-Domain Intermediate Systems to Intermediate
Systems Routing . . . . . . . . . . . . . . . . . . 7
9 Procedures for OSI Network Service/Protocol
Identification . . . . . . . . . . . . . . . . . . . . . 7
9.1 General . . . . . . . . . . . . . . . . . . . . . . 7
9.2 Processing of Protocol Identifiers . . . . . . . . . 8
9.2.1 Originating NPDUs . . . . . . . . . . . . . 8
9.2.2 Destination System Processing . . . . . . . 8
9.2.3 Further Processing in Originating End
System . . . . . . . . . . . . . . . . . . 8
9.3 Applicable Protocol Identifiers . . . . . . . . . . 8
10 Migration Considerations . . . . . . . . . . . . . . . . 8
11 Use of Priority . . . . . . . . . . . . . . . . . . . . . 9
11.1 Introduction . . . . . . . . . . . . . . . . . . . . 9
11.2 Overview . . . . . . . . . . . . . . . . . . . . . . 9
12 Security . . . . . . . . . . . . . . . . . . . . . . . . 11
13 Conformance . . . . . . . . . . . . . . . . . . . . . . . 11
iv
Part 3 - Network Layer
Editor's Note - All references to Stable Agreements in this
Section are to Version 5.
0 Introduction
(Refer to Stable Implementation Agreements Document)
1 Scope
(Refer to Stable Implementation Agreements Document)
2 Normative References
3 Status
This material is current as of December 10, 1993.
4 Errata
Errata are reflected in pages of Version 7, Stable Document.
5 Connectionless-Mode Network Service (CLNS)
5.1 ISO 8473
5.1.1 Subsets of the protocol
(Refer to the Stable Implementation Agreements Document).
5.1.2 Mandatory Functions of ISO 8473
(Refer to the Stable Implementation Agreements Document).
5.1.3 Optional Functions of ISO 8473
(Refer to the Stable Implementations Agreements document).
Intermediate systems implementing priority shall do so as
described below. For End system network entities the
implementation of priority is optional, but if implemented it
1
PART 3 - NETWORK LAYER December 1993 (Working)
shall also be done as described below:
a) NPDUs shall be scheduled based on the priority functions
of ISO 8473. The scheduling algorithm for achieving this
priority function is left as a local matter. It is
required that the following constraints be met as described
below:
1) An NPDU of lower priority shall not overtake an
NPDU of higher priority in an intermediate system
(i.e., exit an IS ahead of a higher priority NPDU
arriving before it);
2) A minimum flow shall be provided for lower priority
PDUs.1;
b) According to ISO 8473, the priority level is a binary
number with a range of 0000 0000 (lowest priority) to 0000
1110 (highest priority level). Within this range, the four
abstract values corresponding to the four levels defined in
section 3.11 shall be encoded as follows:
1) "high reserved" priority will be encoded with value
14 ( 0000 1110);
2) "high" priority will be encoded with value 10 (
0000 1010);
3) "normal" priority will be encoded with value 5 (
0000 0101);
4) "low" priority will be encoded with value "zero" (
0000 0000);
5) For a receiving network entity, a value lower than
5 shall be considered as "low"; a value lower than 10
and higher than 5 shall be considered as "normal", and
a value lower than 14 and higher than 10 shall be
considered as "high";
c) Network entities supporting priority shall process PDUs
in which the priority parameter is absent as either "low",
"normal", or "high" according to a locally configurable
parameter. This is to ensure that NPDUs not containing the
1 The scheduling algorithm by which this is accomplished
is for further study.
2
PART 3 - NETWORK LAYER December 1993 (Working)
priority parameter can be processed by intermediate systems
in a defined manner with respect to those which do contain
the priority parameter;
d) IEEE 802.4 and IEEE 802.5 local area networks as well as
some X.25 networks implementations have the ability to
support subnetwork priorities. When available, a subnetwork
priority function should be utilized in support of the
priority requested of the network layer. The mapping of
network layer priority levels onto subnetwork priority
levels is a local configuration matter.
Editor's Note - To enchance the behavior of the congestion
notification function (see LLSIG/91-63), the following
changes to part 3, 5.1 of the Stable Implementation
Agreements are to be made:
Add the following after the definitions of "previous" and
"current" cycles:
c) in addition, it is recommended that when the busy period
of the current cycle comprises a single packet then the
current cycle is combined with the previous cycle.
Changes to the algorithm components defined in table 1 are as
follows:
a) the old component number 3 becomes component number 4;
b) just prior to the definition of the new algorithm
component 3, add the following definition of C:
- C=no. of packets processed during the current
cycle, initailly 0;
c) the new algorithm component number 3 is defined as
follows:
- 3. If C=1 at the end of the current cycle combine
the current cycle into the previous cycle as follows:
- area of previous cycle = area of previous
cycle + area of current cycle;
- duration of previous cycle = duration of
previous cycle + duration of current cycle.
NOTE - the corresponding changes to figure 1 are depicted
below:
3
PART 3 - NETWORK LAYER December 1993 (Working)
+---------------------------------------------------------------+
| The algorithm makes use of the following variables: |
| |
| t = Current time |
| ti = time of ith arrival or departure event |
| qi = number of packets in the system after the event |
| T0 = time at the beginning of the previous cycle |
| T1 = time at the beginning of the current cycle |
| C = number of PDUs processed during current cycle |
| initially 0 |
| |
| The algorithm consists of three components: |
| |
| 1. Queue Length Update: Beginning with q0 = 0, |
| If the ith event is an arrival event, qi = qi-1+1 |
| If the ith event is a departure event, qi = qi-1-1 |
| |
| 2. Queue Area (integral) update: |
| |
| Area of the previous cycle = qi-1(ti-ti-1) |
| ti {T0,T1) |
| |
| Area of the current cycle = qi-1(ti-ti-1) |
| ti {T1,t) |
| |
| 3. If C = 1 at the end of the current cycle, |
| then area of previous cycle = area of previous |
| cycle + area of current cycle; |
| |
| duration of previous cycle = duration of |
| previous cycle + duration of current cycle. |
| |
| 4. Average Queue Length Update: |
| |
| Average Queue length over the two cycles |
| Area of the two cycles Area of the two cycles |
| = ---------------------- = ---------------------- |
| Time of the two cycles t-T0 |
| |
+---------------------------------------------------------------+
Figure 1 - Queue length averaging algorithm
Add an additional item:
g) when providing an"echo" or "ping" function for CLNP, the
protocol mechanisms shall be as specified in ISO 8473/PDAM6.
It is strongly recommended that end and intermediate systems
support this function and provide appropriate mechanisms
through which the Echo request function may be invoked.
4
PART 3 - NETWORK LAYER December 1993 (Working)
5.2 Provision of CLNS over Local Area Networks
(Refer to the Stable Agreements Document)
5.3 Provision of CLNS over X.25 Subnetworks
(Refer to the Stable Agreements Document)
5.4 Provision of CLNS over ISDN
(Refer to the Stable Implementation Agreements document).
5.5 Provision of CLNS over Point-to-Point Links
(To be based on ISO 8880)
6 Connection-Mode Network Service
6.1 Mandatory Method of Providing CONS
6.1.1 General
(Refer to the Stable Implementation Agreements document).
6.1.2 X.25 WAN
(Refer to the Stable Implementation Agreements document).
6.1.3 LANs
(Refer to the Stable Implementation Agreements document).
6.1.4 ISDN
(Refer to the Stable Implementation Agreements document).
5
PART 3 - NETWORK LAYER December 1993 (Working)
6.1.5 Priority
Priority for CONS will be addressed with the implementation of
X.25-1988 in a future version of these agreements.
6.2 Additional Option: Provision of CONS over X.25 1980
Subnetworks
(Refer to the Stable Implementation Agreements Document)
6.3 Agreements on Protocols
(Refer to the Stable Implementation Agreements Document)
6.3.1 ISO 8878
(Refer to the Stable Implementation Agreements Document.)
6.3.2 Subnetwork Dependent Convergence Protocol (ISO 8878/Annex
A)
(Refer to the Stable Implementation Agreements Document)
6.4 Interworking
(Refer to the Stable Implementation Agreements Document.)
7 Addressing
(Refer to the Stable Implementation Agreements Document)
6
PART 3 - NETWORK LAYER December 1993 (Working)
8 Routing
8.1 ISO 9542 End System to Intermediate System Routing
(Refer to the Stable Implementation Agreements Document.)
8.2 ISO 10030 End System to Intermediate System Routing
(Refer to the Stable Implementation Agreements Document.)
8.3 Intra-Domain Intermediate Systems to Intermediate Systems
Routing
(Refer to Stable Implementation Agreements Document.)
8.3.1 Static Intra-Domain Routing
(Refer to the Stable Implementation Agreements Document.)
8.3.2 Dynamic Intra-Domain Routing
(Refer to the Stable Implementation Agreements Document.)
8.4 Inter-Domain Intermediate Systems to Intermediate Systems
Routing
(Refer to the Stable Implementation Agreements Document.)
9 Procedures for OSI Network Service/Protocol Identification
9.1 General
(Refer to the Stable Implementation Agreements document).
7
PART 3 - NETWORK LAYER December 1993 (Working)
9.2 Processing of Protocol Identifiers
(Refer to the Stable Implementation Agreements document).
9.2.1 Originating NPDUs
(Refer to the Stable Implementation Agreements document).
9.2.2 Destination System Processing
(Refer to the Stable Implementation Agreements document).
9.2.3 Further Processing in Originating End System
(Refer to the Stable Implementation Agreements document).
9.3 Applicable Protocol Identifiers
(Refer to the Stable Implementation Agreements document.)
It is proposed to add the following entries to both table 2 (IPI)
and table 3 (SPI) of the aligned clause of the Stable Document:
1 0 0 0 0 1 0 1 - ISO/IEC 10747;
10 Migration Considerations
This section considers problems arising from evolving OSI
standards and implementations based on earlier versions of OSI
standards.
8
PART 3 - NETWORK LAYER December 1993 (Working)
11 Use of Priority2
11.1 Introduction
Within the OSI environment, Quality of Service (QoS) parameters
are intended to influence the qualitative behavior of the various
OSI Layer entities. QoS is described in terms of parameters
related to performance, accuracy, and reliability (e.g. delay,
throughput, priority, error rate, security, failure probability,
and etc.).
QoS covers a broad spectrum of issues. As a first step, these
agreements address the efficient sharing of Layer 1, 2, & 3
transmission resources by making use of the priority parameter.
To accomplish this, implementation agreements and encodings are
provided for Network and Transport Layer protocols. The
implication of these agreement for upper layer protocols is
limited to the conveyance of priority information in both
directions between an application entity and the service boundary
for the Transport Layer.
The implementation of priority as defined herein is optional for
intermediate systems and end systems, but if implemented shall be
as defined in the layer specific agreements (for Network Layer
see clause 5.1; for Transport Layer see part 4, clause 5.1.2.6,
and for Upper Layers the clause will be included at a later
date).
11.2 Overview
The purpose of the priority parameter, in the context of the
lower layers, is to influence the scheduling of the transmission
of data on subnetworks, in CONS as well as CLNS environments (end
systems as well as intermediate systems). The priority parameter
as defined is to be used by OSI Applications to control the
"priority of data". Within the lower layers this translates into
a contention for transmission resources, which has a direct
2
This section provides initial proposals on the use of
priority. The proposal requires further technical review
before considering it as having support as an implementation
agreement. Refer to the following documents for further
technical information:
LLSIG 88-64 LLSIG 88-120 LLSIG 88-122
9
PART 3 - NETWORK LAYER December 1993 (Working)
impact on performance.
In order to implement practical mechanisms for scheduling the
transmission of data units while maintaining the usefulness of
priority, the specification of priority levels is limited to
four; one corresponding to each of the four service classes:
a) low priority
b) normal priority
c) high priority
d) high reserved priority
The high reserved priority level is intended primarily for OSI
network management purposes. The three lower priority levels are
intended for information exchange by users.
These four priority levels are used, from an applications point
of view, in the various communications lower layers (Transport,
Network and Data Link) to provide a consistent mapping of
"abstract priority levels" in and n-service onto the n-1 service
and when available, priority parameter values in the layer
protocol. In the upper layers (ASCE, Presentation and Session)
local mechanisms are expected to be provided to application layer
ASEs with a means for conveying priority information in both
directions through the communication upper layers.
For example, this implies that an application request for a high
priority service will be conveyed through
association/presentation/session and will result in a high
priority data transport connection and either high priority data
CLNP PDUs (CLNS case) or a high priority data network
connection/X.25 virtual call (CONS case).
10
PART 3 - NETWORK LAYER December 1993 (Working)
12 Security
(Refer to Stable Implementation Agreements Document.)
13 Conformance
(Agreements to be added at a later date)
11
