Point to Multi-Point Protocol (PMPP) Prepared by: NTCIP Steering Group

Transcription

1 Point to Multi-Point Protocol (PMPP) Prepared by: NTCIP Steering Group May 1996

2

3 Draft March 1998 Table of Contents FOREWORD...i Section 1: GENERAL SCOPE Background Purpose of Document REFERENCES Normative References Other References Contact Information DEFINITIONS ABBREVIATIONS AND ACRONYMS Section 2: NTCIP PROTOCOL OVERVIEW GENERAL ASPECTS Protocol Background Point to Multi-Point Role Section 3: POINT TO MULTI-POINT PROTOCOL GENERAL ASPECTS POINT TO MULTI-POINT PROTOCOL DEFINITION Service Definition Protocol Definition Table of Figures FIGURE 3-1. OSI STACK AND NTCIP PROTOCOLS...1 FIGURE 3-2. PMPP FRAME STRUCTURE...2 FIGURE 3-3. SINGLE BYTE ADDRESS FIELD...3 FIGURE 3-4. TWO-BYTE ADDRESS FIELD...3

4

5 Draft March 1998 Page i FOREWORD The purpose of this document is to provide a definition of Point-to-Multi-Point Protocol (PMPP), one of the component standards of the National Transportation Communications for ITS Protocol (NTCIP). It is intended as a communications protocol standard for interconnecting transportation and traffic control equipment. NTCIP represents a suite of protocols and information management standards that apply to the entire industry. The PMPP addresses the need for a specific Data Link Layer protocol that is geared to the communications requirements of field devices such as traffic controllers, variable message signs, camera controllers, and other similar devices that share a common connection to their controller. It is, by design, implementable in current, state-of-the-art field devices that are part of traffic control or traffic management systems. The original effort in the development of NTCIP began with the NEMA traffic control equipment manufacturers desire to extend the TS-2 Standard for traffic control hardware to cover the more complex issues of systems interoperability and communications standards. The initial goal was to develop a common protocol and define a minimum set of control and status messages so that end users could intermix not only different manufacturers controllers and 170-type controllers, but also all other field-related devices. Currently, it is being extended to cover intra- and inter- traffic management and control center communications. The ultimate goal is to define standard protocols for all aspects of communications for transportation and traffic control networks that are needed for ITS. The figure below depicts the current NTCIP protocol suite family; other protocol suites will be added on an as needed basis. The shaded block indicates the focus of this document. PROFILES Class B Class A Class C Class E Application STMF STMF Telnet FTP SNMP Telnet FTP SNMP Presentation Null Null Null Null Session Null Null Null Null Transport Null UDP TCP TCP Network Null IP IP IP Data Link PMPP PMPP PMPP PPP Physical EIA 232E FSK EIA 232E FSK EIA 232E FSK EIA 232E In preparation of this Standards Publication, input of users and other interested parties is being sought and evaluated. Inquiries, comments, and proposed or recommended revisions should be submitted to: Attn: Alberto J. Santiago NTCIP Information /HSR-11 Turner-Fairbank Highway Research Ctr Georgetown Pike McLean, VA fax: (703)

6

7 Draft March 1998 Page SCOPE Section 1 GENERAL The National Transportation Communications for ITS Protocol (NTCIP) establishes a common method of interconnecting Intelligent Transportation Systems (ITS) and traffic control equipment, establishes the protocol and procedures for establishing communications between ITS related components, defines procedures to develop and register a common set of messages related to controlling and managing an ITS, and defines a set of messages specifically related to current traffic control systems Background As transportation control equipment becomes more sophisticated, planners, users, and equipment manufacturers have recognized the need to establish system inter-operability and integration standards. Different agencies have defined protocols to work with their specific hardware but a problem arises when attempting to integrate additional or other existing hardware into a system. There is no common protocol with which the equipment can communicate. The various systems utilize different synchronizing techniques, data formats, and error-recovery schemes. If a national ITS program is to be implemented then communications standards and protocols must be established. The problem is exemplified by considering just the integration issues related to traffic signal controllers. Currently there is no standardized method to communicate with either National Electrical Manufacturers Association (NEMA) -type controllers or 170-type controllers. In systems that use a remote communications unit to interface with the input/output backpanel signals of the controllers, severe limitations are imposed on the capabilities of the system. Alternately, when systems from different manufacturers are integrated into the same central control system, the communications protocol to each system is different and manufacturer specific. Local controller units operating within the system normally have to be from the same manufacturer of the system. The integration problem is compounded when existing systems are tied into transportation management systems. Not only do these systems have to deal with traffic controllers, but they must also handle such devices as surveillance cameras, variable message signs, and other ITS-related hardware. Ideally, all of this equipment should be able to share the same communications channel. Industry-wide communications standards are needed not just for connectivity and interoperability reasons, but also to accommodate future technology growth. As the needs of ITS become clearer, the ability to transfer data throughout the system will become crucial. A communications standard must accommodate the presently recognized needs as well as the yet undefined needs of the future Purpose of Document The purpose of this document is to provide the information necessary to establish the Point to Multi- Point Protocol (PMPP). The PMPP is used in NTCIP systems at the Data Link Layer to manage the NTCIP protocol classes that can coexist on a common channel. The PMPP accomplishes this by accepting data received from the upper and lower layer protocols, resolving the protocol class and passing the data to the next appropriate protocol for further processing.

8 Page 1-2 Draft March REFERENCES Normative References The following standards contain provisions that, through reference in this text, constitute provisions of this Standard. While end users of NTCIP do not need to obtain these documents, they do provide a complete understanding of the protocol. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibility of applying the most recent editions of the standards listed below. Contact information regarding the referenced standards is given at the end of this section. ISO/IEC 3309:1994, Information technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures Frame structure. ISO/IEC 4335:1994, Information technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures Elements of procedures. ISO/IEC 7809:1994, Information technology Telecommunications and information exchange between systems High-level data link control (HDLC) procedures Classes of procedures. ISO/IEC 11575, Information technology Telecommunications and information exchange between systems Protocol mapping for the OSI Data Link service Other References The following list of documents may also be helpful to the reader in gaining a full understanding of the NTCIP. ITU-T Recommendation X.210 ISO/IEC 10731, Information technology Open Systems Interconnection Conventions for the definition of OSI services. CCITT Recommendation X.213 (1992) ISO/IEC 8348:1992, Information technology Network service definition for Open Systems Interconnection. CCITT Recommendation X.200 (1988), Reference model of Open Systems Interconnection for CCITT Applications. ISO 7498:1984, Information processing systems Open Systems Interconnection Basic Reference Model. (The above pair of documents are basically the same in content and text. They will be superseded by a new edition to be published by end of the Summer At that time, there will only be one version in "identical text" format and the reference will then appear in above.) CCITT Recommendation X.212 (1988), Data Link service definition for Open Systems Interconnection for CCITT applications. ISO/IEC 8886:1992, Information technology Telecommunications and information exchange between systems Data link service definition for Open Systems Interconnection.

9 Draft March 1998 Page Contact Information ISO/IEC Standards Members of the ISO maintain registers of currently valid ISO/IEC International Standards. For the United States of America, the member of ISO is the American National Standards Institute (ANSI), which may be contacted as follows: ANSI 11 West 42nd Street, 13th Floor New York, New York (212) ITU-T Recommendations The ITU-T Secretariat Bureau (ITU-TSB), formerly CCITT, maintains a list of the currently valid ITU- T Recommendations. The ITU-TSB may be contacted as follows: International Telecommunications Union Place des Nations CH-1211 Geneva 20 Switzerland DEFINITIONS These definitions define the nomenclature frequently used in regard to the RS-232 interfaces and modems. ASCII: American Standard Code for Information Interchange. A 7-bit binary code representation of letters, numbers and special characters. It is universally supported in computer data transfer. authentication: The process whereby a message is associated with a particular originating entity. Basic Encoding Rules: The OSI language for describing transfer syntax. baud rate: The number of discrete signal events per second occurring on a communications channel. It is often referred to as bits per second (BPS), which is technically inaccurate but widely accepted. bit: Binary Digit. A single basic computer signal consisting of a value of 0 or 1, off or on. byte: A group of bits acted upon as a group, which may have a readable ASCII value as a letter or number or some other coded meaning to the computer. It is commonly used to refer to 8-bit groups. data: Information before it is interpreted. data link layer: That portion of an OSI system responsible for transmission, framing, and error control over a single communications link. datagram: A self-contained unit of data transmitted independently of other datagrams.

10 Page 1-4 Draft March 1998 Intelligent Transportation Systems: A major national initiative to improve information, communication and control technologies in order to improve the efficiency of surface transportation. International Organization for Standardization: An international standards organization. ANSI is the primary interface to ISO within the United States. Often thought to be International Standards Organization because of the usage ISO for short. Internet: A large collection of connected networks, primarily in the United States, running the Internet suite of protocols. Sometimes referred to as the DARPA Internet, NSF/DARPA, Internet, or the Federal Research Internet. network: A collection of subnetworks connected by intermediate systems and populated by end systems. network layer: That portion of an OSI system responsible for data transfer across the network, independent of both the media comprising the underlying subnetworks and the topology of those subnetworks. network management: The technology used to manage in a network, usually referring to the management of networking specific devices such as routers. In the context of this document, refers to all devices including end systems that are present on the network or inter-network. Open Systems Interconnection: An international effort to facilitate communications among computers of different manufacture and technology. physical layer: That portion of an OSI system responsible for the electro-mechanical interface to the communications media. port number: Identifies an application-entity to a transport service in the Internet suite of protocols. The concept of port numbers is often present in OSI literature; however, post numbers are not inter-network standard, but exist as local network conventions only. protocol: A system of rules and procedures governing communications between two devices. File transfer protocols in your communications program refer to a set of rules governing how error checking will be performed on blocks of data. router: A level-3 (network layer) relay. subnet: A physical network within a network. transportation management: Short for the management of networks of transportation devices and the network itself. user data: Conceptually, the part of the protocol data unit used to transparently communicate information between the users of the protocol. Prefixed by the protocol control information.

11 Draft March 1998 Page ABBREVIATIONS AND ACRONYMS ANSI American National Standards Institute ITU-T International Telecommunications Union, Telecommunications Sector BPS Bits per Second NEMA National Electrical Manufacturers Association CCITT International Telegraph and Telephone NSF National Science Foundation Consultative Committee DARPA Defense Advanced Research Projects Agency NTCIP National Transportation Communications for ITS Protocol DLSDU Data Link Service Data Unit OSI Open Systems Interconnection EIA Electronic Industries Association PMPP Point to Mulit-Point Protocol FCS Frame Check Sequence PPP Point-to-Point Protocol FHWA Federal Highway Administration SDU Service Data Unit FSK Frequency Shift Keying SNMP Simple Network Management Protocol HDLC High-level Data Link Control STMF Simple Transportation Management Framework IANA Internet Assigned Number Authority STMP Simple Transportation Management Protocol IEC International Electro-technical TCP Transmission Control Protocol Commission IETF International Engineering Task Force UCC Unbalanced Connectionless Class IP Internet Protocol UDP User Datagram Protocol IPI Initial Protocol Identifier UI Unnumbered Information ISO International Organization for UP Unnumbered Poll Standardization ITS Intelligent Transportation Systems

12

13 Draft March 1998 Page 2-Error! Main Document Only.1 Section 2 NTCIP PROTOCOL OVERVIEW (Authorized Engineering Information) 2.1 GENERAL ASPECTS Protocol Background The effort to develop NTCIP began with the NEMA traffic control equipment manufacturers recognition for the need to extend the TS-2 Standard for traffic control hardware interchangeability to cover the more complex issues of systems interoperability and communications standards. As the discussions proceeded, the FHWA sponsored a Signal Manufacturers Symposium in May of The participants, who represented manufacturers and users, suggested that the NEMA Committee broaden the scope of its work to define a truly "open" system that includes not just NEMA-type controllers but 170- type controllers and other control-related equipment as well. They also wanted the NEMA Committee to consider how the protocol would tie into a transportation information network and be adaptable to different communications architectures. A subsequent NEMA Technical Committee meeting sought input from all interested parties and a number of suggestions were made to extend the NEMA protocol standard into a national, industry-wide "open" protocol standard. Subsequent meetings evolved into general industry forums with representatives from the user community, consultants, and 170-type equipment suppliers. Recognizing the industry-wide importance of this standard, the FHWA has lent support in developing standards for the ITS. To be "open", NTCIP had to meet existing traffic control functional requirements, support traffic management communications, and lend itself to other, as yet undefined, application requirements of ITS. For a protocol to be open, the first axiom is that communications aspects must be distinctly separate from the application. Since none of the existing traffic control protocols met this criteria, it was felt that other industry standards had to be examined to see if they could serve as a model. To that end, NTCIP embraces features of several existing worldwide communications standards established by the International Organization for Standardization (ISO), the International Telecommunications Union, Telecommunications Sector (ITU-T; formerly CCITT), and the Internet Engineering Task Force (IETF). These standards map into the ISO Open Systems Interconnect Reference Model (OSI Model), which deals with how information can be passed in open systems. The above mentioned goals are realized by establishing a reference model and defining standards that can be used within this framework to support NTCIP requirements. These standards provide the mechanisms to transport information between traffic-control and/or ITS devices. In traffic signal systems they allow information to be passed from an arterial master directly connected to a traffic controller or from a central computer through several devices to a traffic controller. The information and associated procedures for transportation control purposes, on the other hand, is not the subject of any existing international standards. The openness of the protocol should not preclude the possibility of upgrading existing hardware to the standard. A significant, productive, installed base of signal systems is deployed, and a cost-effective evolution from these systems must be addressed in NTCIP. Specifically a class of operation shall be specified that will be implementable in current state-of-the-art hardware. This class of operation will operate with a reduced set of application messages. With its simplified protocol and functionality, it reduces overhead to a level compatible with the capabilities of current hardware. The functional complexity and therefore code size is on par with existing protocols. A device supporting this class of operation will be able to coexist in a system that implements the full NTCIP specification.

14 Page 2-2 Draft March Point to Multi-Point Role The PMPP provides the functionality necessary to integrate different protocol classes over the existing Physical and Data Link layers, and provides access to the higher protocol layers for devices that support them. PMPP will be used to direct Class B traffic to either the Simple Transportation Management Protocol (STMP) or Simple Network Management Protocol (SNMP) in the application layer and directs Class A and Class C traffic to the appropriate Network Layer (IP) for processing. Going down in the stack, the PMPP will accept the user data from the STMP, SNMP and IP layer protocols, construct an appropriate HDLC frame including the proper initial protocol indicator (IPI) value, and pass the frame to the physical layer for transmission over the link. The IPI is directly analogous to the Protocol Identifier employed in the PPP and IP protocols, and follows the same rules as specified in PPP. It provides a mechanism to permit multiplexing messages generated by multiple protocols using a single physical channel. The IPI is an assigned number, which has been coordinated with IANA. 1 1 Pending.

15 Draft March 1998 Page GENERAL ASPECTS Section 3 POINT TO MULTI-POINT PROTOCOL The Point to Multi-Point Protocol fits into the NTCIP suite of protocols as depicted in Figure 3-1. PROFILES Class B Class A Class C Class E Application STMF STMF Telnet FTP SNMP Telnet FTP SNMP Presentation Null Null Null Null Session Null Null Null Null Transport Null UDP TCP TCP Network Null IP IP IP Data Link PMPP PMPP PMPP PPP Physical EIA 232E FSK EIA 232E FSK EIA 232E FSK EIA 232E Figure 3-1. OSI Stack and NTCIP Protocols The PMPP is essentially equivalent to HDLC with an additional field of protocol information imbedded in the information portion of the HDLC frame. This field, known as the Initial Protocol Identifier (IPI), is used to determine which higher level protocol sends or is to receive the data. This was done to allow devices using a Class B application to coexist with Class A and Class C applications on the same physical channel. The end device reads the IPI byte and can determine which next layer the data should be passed to; in effect, to determine whether it can process the data packet. 3.2 POINT TO MULTI-POINT PROTOCOL DEFINITION This Clause defines the service (abstract set of capabilities) provided to the user of the Data Link layer, as well as the associated protocol encoding (syntax) and procedures Service Definition The service provided by the NTCIP PMPP shall be the connectionless-mode service as defined in CCITT Rec. X.212, sections 1-7 (general) and Within these sections, those aspects dealing with Quality of Service shall not apply (this includes all of section 17 and applicable parts of the other sections). In particular, the following aspects of these sections are noted. a) Section 15, describing the features of the Data Link Layer service, shall apply in that all implementations shall support a DLSDU length as specified in b) Section 16, dealing with the model of the Data Link Layer service, shall apply with the additional assumptions that the service shall not duplicate SDUs nor exchange the order of SDUs.

16 Page 3-2 Draft March 1998 c) Section 18, dealing with the sequence of primitives, shall apply. d) Section 18, dealing with data transfer by the Data Link Layer, shall apply. The mapping between this service definition and the protocol elements specified in section is given in section Protocol Definition The PMPP shall be the HDLC Unbalanced Connectionless Class (UCC) of procedures defined in ISO/IEC 7809 with HDLC optional functions number 7 applied for multi-octet addressing and number 15.1 for start/stop transmission with basic transparency. This is designated as UCC-7,15.1. Those sections of ISO/IEC 3309,4335, and 7809 dealing with the following shall not apply to NTCIP: a) synchronous transmission b) classes and associated modes other than UCC: and c) HDLC optional functions other than 7 and Frame Structure The frame structure shall be as shown in ISO/IEC 3309, with the exception that one or two octets of the information portion of the frame shall be used as the Initial Protocol Identifier as described in The PMPP frame structure is shown in Figure st Octet Transmitted Last Octet Transmitted Normal HDLC Frame Structure FLAG ADDRESS CONTROL FCS FLAG IPI INFORMATION Figure 3-2. PMPP Frame Structure Transmission shall be in start/stop mode with basic transparency applied. The other transparency modes shall not apply. The address field of PMPP frames shall use single or extended byte addressing, as provided for in Section 5.1 of ISO/IEC 3309, except that a maximum of two bytes shall be allowed for addressing, and shall incorporate support for group addressing. Address 0 shall be never assigned and address 63 is reserved for the Primary station. Figures 3-3 and 3-4 illustrate how the address field are used.

17 Draft March 1998 Page 3-3 msb 1sb X X X X X X G E = 1 G = 1 if Group Address E = 1 for Non-Extended Address Figure 3-3. Single Byte Address Field Figure 3-3 illustrates a single byte address field. With bit 0 and bit 1 set to 1 and 0 respectively, the upper 6 bits can be used to address stations 1 to 63. If the second low order bit is set to 1, the upper 6 bits shall indicate that the frame is intended for a group of Secondary addresses. Group address 63 (0xff) is reserved for the all stations address and this shall always be transmitted as a single byte. 1st Byte b 7 b 0 b 7 b 0 X X X X X X G E = 0 Address MSB X X X X X X X E = 1 Address LSB 6 7 G = 1 if Group Address Figure 3-4. Two-Byte Address Field Figure 3-4 indicates the structure of a two-byte address field. The low order bit of the first byte shall be set to 0 to indicate an extended field, and the low order bit of the second byte shall be set to 1 to indicate the last byte of address field. The second low order bit of the first byte is still used to indicate a group address. Support for single byte addressing is mandatory. Recognition of extended addressing is mandatory. Support for two-byte addressing shall be provisional. If a single byte address is received, the high order bits of the equivalent two-byte address are assumed to be 0 s. The exception to this rule is the all stations address, which shall always use a single byte address. The control field shall be one octet in length; it shall not be extended. The IPI field is one or two octets, and its value identifies the type of Protocol Data Unit encapsulated in the Information field of the packet. The field is transmitted and received most significant octet first.

18 Page 3-4 Draft March 1998 The structure of this field is consistent with the ISO 3309 extension mechanism for address fields. All Protocols MUST be odd; the least significant bit of the least significant octet MUST equal 1. Also, all Protocols MUST be assigned such that the least significant bit of the most significant octet equals 0 (for two octet IPIs). Frames received that do not comply with these rules MUST be treated as having an unrecognized Protocol. As a practical matter, the PMPP IPI can be sent as a single byte. The ISO 3309 rules stipulate that the least significant bit of the low order byte is 1, that is to be interpreted as the last byte of the field. Hence, by using IPI 0x C1, this will be interpreted as 0x 00C1. (Authorized Engineering Information). The 16-bit FCS procedure defined in section of ISO/IEC 3309 shall be used to determine the FCS Supported Frame Types NTCIP PMPP shall make use of the HDLC frame types shown in Table 3-1, as defined in ISO/IEC 4335 and in ISO/IEC 7809 for use with the UCC procedures: Table 3-1. Allowed HDLC Frame Types Command Response Unnumbered Information (UI) Unnumbered Information (UI) Unnumbered Poll (UP) Unnumbered Information (UI) The encoding for the control field of the above frames is given in ISO/IEC The Poll/Final bit of the control field shall be used as described in the referenced standards except that the Poll bit shall always be set in an unnumbered poll. An unnumbered poll shall never be used with a broadcast or group address. An unnumbered poll shall never contain a data field and shall not include the IPI Procedures Transmission of frames on the link shall be in Unbalanced mode as described in the Introduction of ISO/IEC 4335 and section 6 of ISO/IEC That is, transmission shall be controlled by the Data Link layer (i.e., PMPP) of the station designated as the Primary station (referred to as the control station in ISO/IEC 7809) on that link and shall be responded to by the addressed Secondary station (referred to as the tributary station in ISO/IEC 7809). Transmission by the Primary station to a group address shall have no response. All group communication shall be sent in a UI with P=0. Provisionally, the Data Link layer of a Primary station may support a scheduler that periodically sends a polling message in the next available frame. An unnumbered poll frame type shall be used for this purpose. The T4 timer shall determine the interval. A Secondary station shall transmit only one UI response frame per respond opportunity. The response of the Secondary shall contain its address in the address field, not the address of the Primary. Section of ISO/IEC 7809, which states that the last UI response frame (F-bit=1) must have an information field length of zero, shall be ignored. When a switched connection (e.g. a telephone connection) is used to establish the link, the roles of the Primary and Secondary stations shall be based upon which station initiated the connection; the calling station assumes the role of Primary, while the called station assumes the role of the Secondary.

19 Draft March 1998 Page 3-5 The procedures for establishing a switched connection and identifying the calling station are beyond the scope of the PMPP. The application layer should provide a means of access and authentication of the parties participating in the exchange. This protocol shall take the contents in the NS-User-Data parameter on an N-UNITDATA request primitive, and embed it in the first octet of the higher layer information field of the PMPP Frame. On receipt of a PMPP Frame, the opposite mapping shall be performed. The protocol identification function shall examine the IPI value. It will pass the DLS-User-Data parameter (excluding the IPI) in a DL-UNITDATA indication primitive to the corresponding protocol as identified in Table 3-2 below. Current PMPP IPI values are defined in Table 3-2. If the receiving station does not recognize the IPI, the DLS-User-Data shall be discarded and no further action taken (i.e., the PMPP Frame shall be discarded) Protocol Parameters Table 3-2. IPI Values IPI Value Protocol Decimal Hex IP per STMF 193 C1 There shall be four timers associated with the PMPP: T1 through T4. They shall be setable in the range of 1 to milliseconds, by increments of 1. Their context only applies to the PMPP, not to other layers. T1 - T2 - T3 - T4 - This specifies the maximum time to wait for acknowledgment of a frame. T1 is only activated for a command frame with the poll bit set. The recommended value is 20 ms. This specifies the maximum time to wait before sending an acknowledgment of a sequenced frame. A value of 0 means that there will be no delay in acknowledgment generation. This timer insures that Secondary starts a response so that it is received by a Primary before T1 times out (T2 < T1). T2 is only activated when the receiving station accepts a frame with the poll bit set. The recommended value is 10 ms. This specifies the time to wait before considering a link disconnected. The recommended value is 30 ms. This no-activity timer specifies the maximum time to allow without frames being exchanged on the data link. A value of 0x7FFFFFFH indicates that no idle timer is being kept.