ANSI INCITS 218-2000 Information Technology C High-Performance Parallel Interface C Encapsulation of ISO IEC 8802-2 (IEEE Std 802.2) Logical Link Control Protocol Data Units (HIPPI.pdf

《ANSI INCITS 218-2000 Information Technology C High-Performance Parallel Interface C Encapsulation of ISO IEC 8802-2 (IEEE Std 802.2) Logical Link Control Protocol Data Units (HIPPI.pdf》由会员分享，可在线阅读，更多相关《ANSI INCITS 218-2000 Information Technology C High-Performance Parallel Interface C Encapsulation of ISO IEC 8802-2 (IEEE Std 802.2) Logical Link Control Protocol Data Units (HIPPI.pdf（22页珍藏版）》请在麦多课文档分享上搜索。

1、ANSI INCITS 218-2000 (R2005)for Information Technology High-Performance Parallel Interface Encapsulation of ISO/IEC 8802-2 (IEEE Std 802.2)Logical Link Control Protocol Data Units(HIPPI-LE)Stabilized as INCITS 218-2000 S2015ANSINCITS 218-2000Revision and redesignation ofANSI X3.218-1993American Nati

2、onal Standardfor Information Technology High-Performance Parallel Interface Encapsulation of ISO/IEC 8802-2 (IEEE Std 802.2)Logical Link Control Protocol Data Units (HIPPI-LE)SecretariatInformation Technology Industry Council (ITI)Approved November 14, 2000 American National Standards Institute, Inc

3、.AbstractThe described Specification provides an encapsulation of ISO/IEC 8802-2 (IEEE Std 802.2) Logical LinkControl Protocol Data Units over the High-Performance Parallel Interface (HIPPI).Approval of an American National Standard requires review by ANSI that therequirements for due process, conse

4、nsus, and other criteria for approval havebeen met by the standards developer.Consensus is established when, in the judgement of the ANSI Board ofStandards Review, substantial agreement has been reached by directly andmaterially affected interests. Substantial agreement means much more thana simple

5、majority, but not necessarily unanimity. Consensus requires that allviews and objections be considered, and that a concerted effort be madetowards their resolution.The use of American National Standards is completely voluntary; theirexistence does not in any respect preclude anyone, whether he has a

6、pprovedthe standards or not, from manufacturing, marketing, purchasing, or usingproducts, processes, or procedures not conforming to the standards.The American National Standards Institute does not develop standards andwill in no circumstances give an interpretation of any American NationalStandard.

7、 Moreover, no person shall have the right or authority to issue aninterpretation of an American National Standard in the name of the AmericanNational Standards Institute. Requests for interpretations should beaddressed to the secretariat or sponsor whose name appears on the titlepage of this standar

8、d.CAUTION NOTICE: This American National Standard may be revised orwithdrawn at any time. The procedures of the American National StandardsInstitute require that action be taken periodically to reaffirm, revise, orwithdraw this standard. Purchasers of American National Standards mayreceive current i

9、nformation on all standards by calling or writing the AmericanNational Standards Institute.American National StandardPublished byAmerican National Standards Institute, Inc.11 West 42nd Street, New York, NY 10036Copyright 2000 by Information Technology Industry Council (ITI)All rights reserved.No par

10、t of this publication may be reproduced in anyform, in an electronic retrieval system or otherwise,without prior written permission of ITI, 1250 Eye Street NW, Washington, DC 20005. Printed in the United States of AmericaCAUTION: The developers of this standard have requested that holders of patents

11、 that may berequired for the implementation of the standard disclose such patents to the publisher. However,neither the developers nor the publisher have undertaken a patent search in order to identifywhich, if any, patents may apply to this standard. As of the date of publication of this standardan

12、d following calls for the identification of patents that may be required for the implementation ofthe standard, no such claims have been made. No further patent search is conducted by the de-veloper or publisher in respect to any standard it processes. No representation is made or impliedthat licens

13、es are not required to avoid infringement in the use of this standard.iContentsPageForeword ii1 Scope . 12 Normative references . 13 Definitions and conventions 23.1 Definitions. 23.2 Editorial conventions 23.3 Acronyms and other abbreviations . 24 HIPPI-LE services to 802.2 LLC. 34.1 Service primit

14、ives types 34.2 Sequences of primitives . 34.3 HIPPI-LE service primitive summary 44.4 HIPPI-LE transfer service primitives. 44.5 HIPPI-LE station management service primitives 55 HIPPI-FP data framing services used by HIPPI-LE 66 HIPPI-LE data formats 76.1 HIPPI-LE PDU format. 76.2 IEEE 48-bit addr

15、ess format 8Figures1 HIPPI-LE service relationship. 32 Data transfer service primitive 43 Station management service primitives 54 HIPPI-LE header format . 85 Mapping of 6-byte IEEE universal LAN MAC address to two 32-bit HIPPI words in LE_Header. 8A.1 Example IEEE 802.2 LLC PDU as an ordered hex by

16、te stream withinformation field = DOD IP data set as specified by the Internet Engineering Task Force in RFC 1042 and RFC 1700 9A.2 Example encapsulation of figure A.1 LLC PDU within a HIPPI packet with suggested fills and alignment, i.e., D1_Fill = 0 bytes and D2_Offset = 0 10A.3 Example encapsulat

17、ion of figure A.1 LLC PDU within a HIPPI packetwith D2_Offset = 7 and a possibly non-empty D1_Fill 11A.4 Example encapsulation of ISO IP PDU within a HIPPI packet withD1_Fill = 0 bytes and D2_Offset = 0 12AnnexA Example HIPPI packets containing HIPPI-LE PDUs 9iiForeword (This foreword is not part of

18、 American National Standard NCITS 218-2000.)This High-Performance Parallel Interface, Encapsulation of ISO/IEC 8802-2 (IEEEStd 802.2) Logical Link Control Protocol Data Units (HIPPI-LE) standard defines theHIPPI-LE Protocol Data Unit (PDU) format and interface for transporting (via HIPPI)PDUs confor

19、ming to ISO/IEC 8802-2 (IEEE Std 802.2) Logical Link Control.This standard was originally developed by Task Group X3T9.3 of Accredited Stan-dards Committee X3 during 1990. This standard was revised by Task Group T11.1 in1998-1999, mainly by removing the address resolution protocol.This document incl

20、udes an annex, which is informative and is not considered part ofthe standard.Requests for interpretation, suggestions for improvement or addenda, or defect re-ports are welcome. They should be sent to the National Committee for InformationTechnology Standards, ITI, 1250 Eye Street, NW, Suite 200, W

21、ashington, DC 20005.This standard was processed and approved for submittal to ANSI by NCITS. Com-mittee approval of the standard does not necessarily imply that all committee mem-bers voted for approval. At the time it approved this standard, NCITS had thefollowing members:Karen Higginbottom, ChairD

22、avid Michael, Vice-ChairMonica Vago, SecretaryOrganization Represented Name of RepresentativeApple Computer, Inc. David MichaelWanda Cox (Alt.)Bull HN Information Systems, Inc. Randall KilmartinCompaq Computer Corporation . Scott JamesonStephen Heil (Alt.)John Hurd (Alt.)Hewlett-Packard Company. Kar

23、en HigginbottomWendy Fong (Alt.)Hitachi John NeumannIBM Corporation . Ronald F. SillettiChuck Adams (Alt.)Institute for Certification of Computer Professionals Kenneth M. ZemrowskiThomas Kurihara (Alt.)Lucent Technologies, Inc. Herbert BertineTom Rutt (Alt.)Microsoft Corporation . Mike DeeseGeorge W

24、illingmyre (Alt.)Joseph Zajaczkowski (Alt.)National Institute of Standards Provision for 48-bit source and destination addresses conforming to IEEE 802.1a; Provision for eight forwarding classes to dis-tinguish, for example, among ordinary data PDUs, PDUs for services that require bandwidth guarante

25、es such as packet video, etc. 2 Normative references The following standards contain provisions which, through reference in the text, constitute provisions of this standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreement

26、s based on this standard are encouraged to investi-gate the possibility of applying the most recent editions of the standards listed below. Copies of the following documents can be ob-tained from ANSI: Approved ANSI standards, approved and draft international and regional standards (ISO, IEC, CEN/CE

27、NELEC, ITUT) and approved foreign standards (including BSI, JIS, and DIN). For further information, contact ANSI Customer Service Department at 212-642-4900 (phone), 212-302-1286 (fax), or via the World Wide Web at http:/www.ansi.org. Additional availability contact information is provided below as

28、needed. ANSI X3.210-1992 (and supplement ANSI X3.210-1992/AM 1-1996), High-Performance Par-allel Interface - Framing Protocol (HIPPI-FP) ANSI X3.222-1997, High-Performance Parallel Interface - Physical Switch Control (HIPPI-SC) ANSI/IEEE 802.1a-1990, Local Area Network and Metropolitan Area Network:

29、 Overview and archi-tecture ISO/IEC 8802-2:1998 (ANSI/IEEE 802.2-1998), Information Processing Systems - Local Area Networks - Part 2: Logical Link Control ANSI NCITS 218-2000 2 3 Definitions and conventions 3.1 Definitions For the purposes of this standard, the following definitions apply. 3.1.1 80

30、2.2 LLC PDU: A PDU formatted accord-ing to ISO/IEC 8802-2 (IEEE Std 802.2) Logical Link Control. 3.1.2 HIPPI-LE PDU: A PDU that includes a HIPPI-LE header and an 802.2 LLC PDU and is formatted according to clause 6. 3.1.3 optional: A term referring to features that are not required by the standard.

31、However, if any optional feature defined by the standard is imple-mented, it shall be implemented according to the standard. 3.1.4 protocol data unit (PDU): A formatted data set that is a logical unit of interchange be-tween entities. 3.1.5 service data unit (SDU): A formatted data set that includes

32、 a PDU and optional infoRmation for the convenience of an implementer. 3.1.6 station management (SMT): The supervi-sory entity that monitors and controls HIPPI. 3.1.7 Switch Address: A value in the switch hardware domain which selects the route or end point of a HIPPI connection. The range and forma

33、t depend on switch hardware. HIPPI-SC specifies two formats: Logical Address (12 bits) and Source Route (24 bits). 3.2 Editorial conventions In this standard, certain terms that are proper names of service primitives, or similar terms are printed in uppercase to avoid possible confusion with other u

34、ses of the same words (e.g., TRANS-FER). Any lowercase uses of these words have the normal technical English meaning. The first letter of each word of service parame-ters, service primitive types, and similar terms is capitalized (e.g., Destination_Address, Status, Request). Any lowercase uses of th

35、ese words have the normal technical English meaning. 3.3 Acronyms and other abbreviations ARP Address Resolution Protocol CCI connection control information FP Framing Protocol HIPPI High-Performance Parallel Interface IEEE Institute of Electrical and Electronic Engi-neers IP Internet Protocol LE Li

36、nk Encapsulation LESM Link Encapsulation - Station Management LLC Logical Link Control PDU protocol data unit RFC Request For Comment SMT station management SDU service data unit ULP upper layer protocol ANSI NCITS 218-2000 3 4 HIPPI-LE services to 802.2 LLC This clause specifies the services provid

37、ed by HIPPI-LE. The intent is to allow 802.2 LLC to op-erate correctly with HIPPI-LE. How many of the services described in this clause are chosen for a given implementation is up to the implementer; however, the set of HIPPI-LE services supplied shall be sufficient to satisfy the higher level proto

38、-col(s) being used. Service parameters are also optional and additional parameters not shown may be used as necessary. The services as de-fined in this standard do not imply any particular implementation, or any interface. In this standard the 802.2 LLC and station man-agement protocol (SMT) are ser

39、vice users, and the HIPPI-LE is the service provider to the 802.2 LLC and SMT. The primitives to 802.2 LLC are prefixed with LE_ and the SMT primitives are pre-fixed with LESM_. The HIPPI-LE is also the service user of HIPPI-FP services, which are prefixed with FP_. Figure 1 shows the relationship o

40、f the services provided by and used by HIPPI-LE. 4.1 Service primitives types HIPPI service primitives are of four types: Request primitives are issued by a service user to initiate a service from the service pro-vider; Confirm primitives are issued by the service provider to acknowledge a Request;

41、Indicate primitives are issued by the service provider to notify the service user of a local event. This primitive is similar in nature to an unsolicited interrupt. Note that the local event may have been caused by a service Request; Response primitives are issued by a service user to acknowledge an

42、 Indicate. Upper LevelProtocols802.2 LLCHIPPI-LEHIPPI-FPLower LevelProtocolsStationManagement(SMT)(LESM_. )(FP_. )(LE_. )Figure 1 HIPPI-LE service relationship 4.2 Sequences of primitives The order of execution of service primitives is not arbitrary. Logical and time sequence relationships exist for

43、 all described service primitives. Time sequence diagrams are used to illustrate a valid sequence. Other valid sequences may exist. The sequence of events between peer users across the user/provider interface is illustrated. In the time sequence diagrams, the HIPPI-LE users are depicted on either si

44、de of the vertical bars while the service provider is in the center. ANSI NCITS 218-2000 4 4.3 HIPPI-LE service primitive summary 802.2 LLC Data Transfer: LE_TRANSFER.Request ( Destination_Address, LE_SDU) LE_TRANSFER.Confirm (Transmission_Status) LE_TRANSFER.Indicate ( Destination_Address, Source_A

45、ddress, LE_SDU, Reception_Status) LE_TRANSFER.Response Local Station Management: LESM_STATUS_CTRL.Request (Control) LESM_STATUS_CTRL.Confirm (Status) LESM_STATUS_CTRL.Indicate (Status) LESM_STATUS_CTRL.Response 4.4 HIPPI-LE transfer service primitives These primitives, as illustrated in figure 2, ar

46、e used to transfer an 802.2 LLC PDU from source 802.2 LLC to destination 802.2 LLC. Source 802.2 LLCHIPPI-LE Destination 802.2 LLCLE_TRANSFER.RequestLE_TRANSFER.ConfirmLE_TRANSFER.IndicateLE_TRANSFER.ResponseFigure 2 Data transfer service primitive 4.4.1 LE_TRANSFER.Request This primitive is issued

47、by the source 802.2 LLC to request a data transfer to the destination 802.2 LLC. The HIPPI-LE PDU format is defined in 6.1. LE_TRANSFER.Request ( Destination_Address, LE_SDU) Destination_Address is the information neces-sary to forward the HIPPI-LE PDU to its desired destination. LE_SDU is the servi

48、ce data unit which includes the 802.2 LLC PDU that is to be sent. NOTE 1 The Requested_Service_Class parame-ter of 802.2 LLC is not used by HIPPI-LE. Issued The source 802.2 LLC issues this primi-tive to request a transfer of an 802.2 LLC PDU to a destination 802.2 LLC. Effect The Source HIPPI-LE sh

49、all accept the 802.2 LLC PDU for transmission. The HIPPI-LE shall build an LE_Header and D2_Area, as speci-fied in 6.1, and invoke FP_TRANSFER.Request to send the HIPPI-LE PDU to the destination. NOTE 2 Significant performance loss may occur if the D2_Offset in the HIPPI-FP header is non zero, although receivers must be prepared to accept any D2_Offset allowed by HIPPI-FP. 4.4.2 LE_TRANSFER.Confirm This primitive acknowledges the LE_TRANSFER.Request from the Source ULP. LE_TRANSFER.Confirm (Transmission_Status) Transmission_Status is used to pass status in-f