AIAA S-133-2-2013 Space Plug-and-Play Architecture Standard Networking.pdf

《AIAA S-133-2-2013 Space Plug-and-Play Architecture Standard Networking.pdf》由会员分享，可在线阅读，更多相关《AIAA S-133-2-2013 Space Plug-and-Play Architecture Standard Networking.pdf（39页珍藏版）》请在麦多课文档分享上搜索。

1、 Standard AIAA S-133-2-2013 S-102.2.5-2009 Space Plug-and-Play Architecture Standard Networking AIAA standards are copyrighted by the American Institute of Aeronautics and Astronautics (AIAA), 1801 Alexander Bell Drive, Reston, VA 20191-4344 USA. All rights reserved. AIAA grants you a license as fol

2、lows: The right to download an electronic file of this AIAA standard for storage on one computer for purposes of viewing, and/or printing one copy of the AIAA standard for individual use. Neither the electronic file nor the hard copy print may be reproduced in any way. In addition, the electronic fi

3、le may not be distributed elsewhere over computer networks or otherwise. The hard copy print may only be distributed to other employees for their internal use within your organization. AIAA S-133-2-2013 Space Plug-and-Play Architecture Standard Networking Sponsored by American Institute of Aeronauti

4、cs and Astronautics Approved August 2012 Abstract This document specifies the overall SPA network methodology, the approach to abstraction of unique transport details, and methods of communicating across multiple similar and dissimilar networks. This document does not discuss details about messaging

5、 protocol families, message structure, or the format of specific SPA messages. Those specifications are expressed in the SPA Logical Interface document. AIAA S-133-2-2013 ii Published by American Institute of Aeronautics and Astronautics 1801 Alexander Bell Drive, Reston, VA 20191 Copyright 2013 Ame

6、rican Institute of Aeronautics and Astronautics All rights reserved No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America ISBN 978-1-62410-230-1 AIAA S-133-

7、2-2013 iii Contents Foreword . v Introduction. vii 1 Scope . 1 2 Applicable Documents . 1 3 Vocabulary . 1 3.1 Acronyms and Abbreviated Terms . 1 3.2 Terms and Definitions 2 4 Networking Requirements for a SPA System 2 4.1 Overview 2 4.2 Topology Discovery and Routing . 4 5 Requirement to Support Pa

8、cket Fragmentation 18 6 Specific Topology Considerations 18 6.1 Multiple SM-x on the Same Subnet . 18 6.2 Multiple Available Paths Within a Subnet 19 7 SPA Network Requirements 20 7.1 SPA Local Bus Requirements 20 7.2 Central Addressing Service (CAS) Requirements . 20 7.3 SPA Lookup Service Requirem

9、ents . 21 7.4 SPA subnet Manager (SM-x) Requirements 21 7.5 Generic Router Requirements . 22 7.6 Generic SPA Endpoint Requirements 23 7.7 SPA Checksum Generation . 23 Annex A Compliance Matrix for a SPA Network 24 Figures Figure 1 Example SPA network implementation . 3 Figure 2 SPA network phases of

10、 operation 4 Figure 3 A sample SPA network topology for discovery . 5 Figure 4 Network topology discovery . 6 Figure 5 SPA lookup Service to SPA component intercommunication . 14 Figure 6 Component registration data flow sequence 15 Figure 7 Address request sequencing diagram . 16 Figure 8 Subnet to

11、 subnet communication via SPA-L 17 Figure 9 Subnet to subnet communication without SPA-L 18 Figure 10 A subnet with two SM-x . 19 AIAA S-133-2-2013 iv Figure 11 A subnet with two routes to every component 19 Tables Table 1 SPA request address block format . 8 Table 2 SPA assign address block message

12、 format . 8 Table 3 SPA request CAS route message format 9 Table 4 SPA reply CAS route message format . 10 Table 5 SPA distribute route message format . 11 Table 6 CAS routing table example . 12 Table 7 SM-x routing table example 13 Table A1 Minimum requirements for a compliant SPA network 24 AIAA S

13、-133-2-2013 v Foreword This document was developed by the Space Plug and Play Architecture (SPA) Standards Working Group as one of a series of 10 documents describing the various components of the standard. The SPA standards were initially recorded in earlier documentation. This document set separat

14、es content along logical boundaries to better organize the volumes (so that developers or domain experts need only reference the documents applicable to their needs) and to avoid duplication of content between documents in the standard series. This 2013 AIAA standard supersedes all previous document

15、ation of the SPA standards. This particular volume of the SPA Networking standard contains information not recorded in previous documentation. It is part of a set of 10 documents describing other components of the standard: SPA Guidebook SPA Logical Interface SPA Physical Interface Standard SPA 28V

16、Power Service Standard SPA System Timing Standard SPA Ontology Standard SPA Test Bypass Standard SPA SpaceWire Subnet Adaptation Standard SPA System Capability Guide At the time of approval, the members of the AIAA SPA Committee on Standards were: Fred Slane, Chair Space Infrastructure Foundation Je

17、anette Arrigo Sierra Nevada Corporation Scott Cannon Utah State University Ken Center PnP Innovations Don Fronterhouse* PnP Innovations Rod Green Design Group Jane Hansen HRP Systems Doug Harris Operationally Responsive Space Office Paul Jaffe Naval Research Laboratory Stanley Kennedy* Comtech Aero-

18、Astro Ronald Kohl R.J. Kohl those are considerations addressed in the SPA Logical Interface Standard (AIAA S-133-3-2013) and the various subnet standards (of which SPA SpaceWire, AIAA S-133-9-2013, is the only currently approved subnet standard). This standard describes the minimum requirements for

19、the components in a SPA network and for the functions of network topology discovery, routing table construction and distribution, packet routing, and dynamic reconfiguration. 1 1 Scope This document specifies the overall SPA network methodology, the approach to abstraction of unique transport detail

20、s, and methods of communicating across multiple similar and dissimilar networks. This document does not discuss details about messaging protocol families, message structure, or the format of specific SPA messages. Those specifications are expressed in the SPA Logical Interface Standard (AIAA S-133-3

21、-2013). 2 Applicable Documents The following standards documents contain provisions which, through reference in this text, constitute provisions of this standard. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. However, parties to agreements b

22、ased on this standard are encouraged to investigate the possibility of applying the most recent editions of the normative documents indicated below. For undated references, the latest edition of the normative document referred to applies. AIAA G-133-1-2013 Space Plug-and-Play Architecture Guidebook

23、AIAA S-133-3-2013 Space Plug-and-Play Architecture Standard Logical Interface AIAA S-133-9-2013 Space Plug-and-Play Architecture Standard SpaceWire Subnet Adaptation 3 Vocabulary 3.1 Acronyms and Abbreviated Terms AIAA American Institute of Aeronautics and Astronautics ASME American Society of Mecha

24、nical Engineers ASTM American Society of Testing and Materials CAS central addressing service EOP end of packet EP MTU endpoint maximum transmission unit SM-L SPA manager for the SPA local interconnects SM-s SPA manager for SpaceWire protocol subnet SM-x SPA subnet manager, where x represents a give

25、n technology protocol SPA Space Plug-and-Play Architecture SPA-L SPA local interconnect UUID universally unique identifier xTEDS extensible transducer electronic data sheet AIAA S-133-2-2013 2 3.2 Terms and Definitions For the purposes of this Standard, the following terms and definitions shall appl

26、y. Central Addressing Service responsible for providing logical address blocks to be assigned to each hardware or software component registered with the system during component registration. It stores the logical address block, UUID, and physical address for each core component. Component an endpoin

27、t whose interface conforms to the SPA Interface standard and does not connect to another SPA object via a different port. NOTE A SPA hardware component is indistinguishable from a SPA software component for the purposes of this document. Plug and play ability to connect a device to the larger system

28、 and have the two work together with little or no set-up required (e.g., automated system recognition and data exchange) Router a device with multiple ports that may be attached to another SPA router, a SPA manager, gateway, or SPA component endpoint SPA lookup service responsible for accepting comp

29、onent registration and providing data source route information for components requesting a particular type of service (or returning a negative acknowledgment if the service is not available) SPA manager responsible for performing discovery for a particular subnet. It maps incoming packets to the cor

30、rect SPA endpoint on the subnet, encapsulating the SPA packet with the correct protocol header. In the reverse direction it removes the protocol header and possibly adds a new header conforming to the subnet the packet is about to enter. It is also responsible for topology discovery and reporting wi

31、thin the subnet. 4 Networking Requirements for a SPA System 4.1 Overview An example network topology implemented with SPA components is shown in Figure 1 below. The major components of the network are as follows: a. Component Addressing Service (CAS). A process that provides a fixed-size logical add

32、ress block (65536 bytes or 216 addresses) unique to the SPA network upon request from a subnet manager. The addresses in that block shall only be assigned to components (not SPA Managers, e.g. SM-L, SM-x) residing on that subnet. Only one CAS shall be active in a particular SPA network at any time;

33、redundancy is encouraged but not required. The CAS process shall exist on a SPA-L interconnect, and shall be directly accessible by all SM-x in the SPA network after the SM-L has delivered its address. b. SPA Lookup Service: A process that accepts component registrations of SPA components providing

34、services and provides the ID for that service to other components which request them. Only one SPA Lookup Service shall be active in a particular SPA network at any time; redundancy is encouraged but not required. The SPA Lookup Service process must be instantiated on a SPA-L interconnect, and can b

35、e directly accessed by SM-x nodes after it has been discovered and its address has been distributed. AIAA S-133-2-2013 3 c. SPA Manager (SM-x): SM-x is a protocol specific SPA process on a SPA-L that acts as a translation device for a particular protocol. A SPA-S Manager (SM-s, for the specific Spac

36、eWire protocol set), for example, accepts packets received from SPA-L, and removes the protocol specific header. Then it performs a lookup of the SPA destination address in its local lookup table, and encapsulates the packet in a SpaceWire header/end of packet (EOP), with the correct destination or

37、logical SpaceWire route to reach that endpoint, or adjacent manager if the endpoint is distant. In the outgoing direction it removes the SpaceWire header from the outgoing packet and adds a protocol header as indicated in its outgoing lookup table. d. In a hardware implementation, an SM-x might act

38、as a simple bridging device to move packets from one protocol subnet to another. In this case the SM-x shall be required to request addresses from the CAS for items in both subnet, and translate packet moving from one domain to another. e. It is important to note that it is normal practice for multi

39、ple SM-x to coexist on the same subnet, independently performing topology discovery. Each SM-x shall construct a table of physical routes to each component on the subnet. An SM-x shall subsequently request and distribute an address block from the CAS for SM-x existing on its sub-net. Those SM-x shal

40、l then request an address block in turn from the CAS for SM-x on their subnet. Note that the CAS shall always distribute the same block for a SM-x with a particular SM-x if it has been previously assigned. f. SPA-L: SPA-L is the interconnect protocol used to connect applications on a processing node

41、 of the SPA network. A SPA-L interconnect is controlled by a SM-L process, just as a physical subnet would be controlled by a SM-x process or device. The SM-L process receives an address block for each process on the node, just as the SM-s receives an address block for each endpoint on a SpaceWire n

42、etwork. g. The CAS must exist on a SPA-L interconnect, but it will exist on only one SPA-L in a single SPA network. There would be one SPA-L interconnect for each processing node in the system. h. SPA Gateway: A SPA Gateway is a bridge to another, non-SPA network on the spacecraft. As such, a SPA Ga

43、teway shall provide a fully compliant SPA interface (e.g., a SPA endpoint) on the SPA side of the Gateway recognized, identified, and registered during the topology discovery process. CAS SM-sSM-sSpacew ireSubne tSpacew ireSubne tEPEP EPEPEP EPSM-LSPA-LSM- LSM- sSPA- LSM- LSM- sSPA- LSPA Lookup Serv

44、iceSM- iSM- sI2 CSubnetEPEP EPSpacew ireSubne tEPEP EPGatewayFigure 1 Example SPA network implementation AIAA S-133-2-2013 4 4.2 Topology Discovery and Routing This section discusses the method by which the topology of the SPA network with associated subnets is discovered and how packets are routed

45、during and following topology discovery. The four main stages of operation are shown below in Figure 2. Figure 2 SPA network phases of operation 4.2.1 Topology Discovery Topology discovery should assign to each component a logical address in the SPA network. A logical address is unique across the SP

46、A network, whereas the Universally Unique ID (UUID) is unique for each specific SPA component (UUIDs are further described in the SPA Logical Interface Standard (AIAA S-133-3-2013). The smaller address space created by using SPA logical addresses makes message er, whi aiini inti ovi UUID. T pi om UU

47、ID to ogical address shall be one-to-one. The logical addresses assigned to each component shall remain constant from the time of first assembly of the network (e.g., initial system integration). The CAS and SPA managers (SM-L, SM-x) shall assign the same logical addresses to components with the sam

48、e UUID requesting addresses multiple times, as might occur in the event of a power cycle or reset of a subnetwork or component. The routing information shall allow for any component to establish a consumer-provider relationship with any other component. Such relationships are described in Section 4.

49、2.3 and Section 4.2.5 below. The discovery process shall notify the single active SPA Lookup Service function of each SPA component using a SPARqstDmProbe message. AIAA S-133-2-2013 5 During this phase the CAS assigns a logical address block to each SPA Manager in the SPA network. Each SM-x is informed of the route to the other mangers, and the CAS and SPA Lookup Service processes. This step may optionally be skipped on power-up if the network has a stored conf