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