AIAA S-133-9-2013 Space Plug-and-Play Architecture Standard SpaceWire Subnet Adaptation.pdf

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

1、Standard AIAA S-133-9-2013 S-102.2.5-2009 Space Plug-and-Play Architecture Standard SpaceWire Subnet Adaptation 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

2、a license as follows: 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, t

3、he electronic file 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-9-2013 Space Plug-and-Play Architecture Standard SpaceWire Subnet Adaptation Sponsored b

4、y American Institute of Aeronautics and Astronautics Approved November 2012 Abstract This document specifies the means by which the SPA features of networked component registration, and message routing to endpoints on a SpaceWire network are facilitated. Accomplishing this requires low-level messagi

5、ng on the SpaceWire network to provide the convergence functions to allow the common SPA messages to be transported. This document does not discuss physical details of SpaceWire related to signal levels, harnessing, and so forth. Those Specifications are expressed in the SpaceWire standard document

6、ECSS-E-50-12C. AIAA S-133-9-2013 ii Published by American Institute of Aeronautics and Astronautics 1801 Alexander Bell Drive, Reston, VA 20191 Copyright 2013 American Institute of Aeronautics and Astronautics All rights reserved No part of this publication may be reproduced in any form, in an elect

7、ronic retrieval system or otherwise, without prior written permission of the publisher. Printed in the United States of America ISBN 978-1-62410-237-0 AIAA S-133-9-2013 iii Contents Foreword v Introduction vii 1 Scope. 1 2 Applicable Documents . 1 3 Vocabulary . 2 3.1 Acronyms and Abbreviated Terms

8、. 2 3.2 Terms and Definitions 2 4 Overview 3 5 SPA SpaceWire Subnet . 3 5.1 Normative SpaceWire Header . 4 6 Topology Discovery . 5 6.1 Routing Table Format in the SM-s . 6 6.2 Routing Table Formats in the SPA Endpoints 8 6.3 Topology Dependent Issues 9 7 SPA Packet Routing Over SpaceWire Following

9、Discovery 12 7.1 Routing From the SM-s to a SPA Component . 12 7.2 Routing a SPA Packet From a SPA Endpoint to the SM-s . 13 7.3 Routing a SPA Packet From a Subnet Component to Another Local Subnet Component. 13 7.4 SM-s to SM-s Racket Routing 13 8 Differentiation of Traffic 13 9 Dynamic Reconfigura

10、tion . 14 9.1 Detecting a New Process on a Known Endpoint 14 9.2 Detecting Changes in the Subnet Topology. 14 10 SPA SpaceWire Specific Message Formats 14 10.1 SPASpWRouterProbe 14 10.2 SpaSpWEndpointPing . 16 10.3 SpaSpWEndpointPingReply 18 10.4 SpaSpWConfigureTopologyDiscovery . 20 11 Requirements

11、 List 22 11.1 SM-s Requirements . 22 11.2 SpaceWire Router Requirements 23 11.3 SpaceWire SPA Component Requirements 23 Annex A Topology Discovery Example . 24 A.1 SM-s Identifies Its Link Partner and Return Port 24 A.2 The SM-s Identifies the Endpoints Attached to Router 0 25 AIAA S-133-9-2013 iv A

12、.3 Identifying Routers Attached to Router 0. 26 A.4 Finishing Topology Discovery 28 Annex B SPA SpaceWire Minimum Functionality . 28 Figures Figure 1 A SPA SpaceWire subnet . 4 Figure 2 SpaceWire packet format 5 Figure 3 SPA spaceWire network topology example 7 Figure 4 A SpaceWire subnet with multi

13、ple managers 10 Figure 5 A SpaceWire ring subnet 10 Figure 6 SPA-s subnet in a mesh topology . 11 Figure 7 SM-s to subnet target routing example . 12 Figure 8 SpaceWire packet . 13 Figure A.1 Example SPA SpaceWire subnet 24 Figure A.2 Identifying the SM-s return port . 25 Figure A.3 Endpoint identif

14、ication 26 Tables Table 1 SM-s (UUID 45345) routing table example . 8 Table 2 SPA component (UUID 23474) routing table example . 9 Table 3 SM-s routing example 12 Table A.1 SM-s partial routing table 28 Table B.1 Minimum requirements for a compliant SPA SpaceWire subnet . 28 AIAA S-133-9-2013 v Fore

15、word This document was developed by the Space Plug-and-Play Architecture (SPA) Standards Working Group as one of a series describing the various components of the standard. The SPA standards were recorded in earlier documentation. This document set separates content along logical boundaries to bette

16、r 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 documentation of the SPA standards. This particular

17、volume of the SPA SpaceWire (SPA-S) Subnet Adaptation 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 Networking Standard SPA Logical Interface Standard SPA Physical Interface Sta

18、ndard SPA 28V Power Service Standard SPA System Timing Standard SPA Ontology Standard SPA Test Bypass 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 Jeanette Arrigo Sierra Nevada

19、 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-Astro Ronald Kohl R.J. Kohl

20、 it stores the logical address block, UUID, and physical address for each core component Component an endpoint whose interface conforms to the SPA Interface standard and does not connect to another SPA object via a different port; note that a SPA hardware component is indistinguishable from a SPA so

21、ftware component for the purposes of this document. Plug-and-play ability to connect a device to the larger system 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 anoth

22、er SPA router, a SPA manager, gateway, or SPA component endpoint AIAA S-133-9-2013 3 SPA lookup service responsible for accepting component registration and providing data source route information for components requesting a particular type of service (or returning an acknowledgment if the service i

23、s not available). SPA manager responsible for performing discovery for a particular subnet. It maps incoming packets to the correct 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 n

24、ew header conforming to the subnet the packet is about to enter. It is also responsible for topology discovery and reporting within the subnet. 4 Overview In SPA, a subnetwork manager is a construct that bridges to a protocol other than that natively supported by SPA messaging. SPA supports a native

25、 packet format and addressing protocol which is independent of the low level networks on which it is transported. In order for the SPA addressing services, data manager, and other subnet managers to access a SpaceWire subnet, there must be a broker that allows the component discovery and messaging c

26、ommunication functions to occur despite the fact that they are not natively supportedthis is the role of a SpaceWire subnetwork manager (SM-s). The fundamental roles of an SM-s are described briefly in the following bullets and in greater detail within this standard document. Discovering all nodes o

27、n the network and their associated SPA components Performing any work required to configure the network infrastructure to support addressing Requesting to register the components of the subnet with the SPA Lookup Service on the SPA Network Requesting address blocks for other SM-s on the subnet, and

28、storing assigned logical addresses for SPA components on the subnet. Distributing information (if necessary) to allow all endpoints on the subnet to route to any other endpoint on the subnet Mapping a SPA message received at the SM-s from the SPA-L side to an endpoint on the subnet Releasing message

29、s arriving from the subnet onto the SPA-L in the proper form for local routing Providing bridging capability when two or more adapters are installed on a host. This is the ability to pass messages from one subnet to another, regardless of the type of transport. 5 SPA SpaceWire Subnet SpaceWire is a

30、point to point switch fabric transport consisting of routers and nodes. For the SPA application, a path routing addressing scheme (one of two supported approaches in the SpaceWire standard) to pass packets between nodes on the network was utilized. Figure 1 shows a typical SPA system consisting of S

31、paceWire routers, SpaceWire subnet managers, and connected SPA-Local interconnects with associated services. In order for a SPA endpoint in a SpaceWire subnet to be addressable by the system, the SM-s must be able to identify the position of the endpoint and its associated SPA components during topo

32、logy discovery, request a logical address block for the components and request registration for the component from the SPA Lookup Service. Once the component has delivered its xTEDs to the SPA Lookup Service, the component may be used for services by other SPA components in the network. AIAA S-133-9

33、-2013 4 SPA- LSPA-LSpWRou t erSPAEPSpWRou t erSPAEPSPAEPSPAEPSPAEPSPAEPSPAEPSPAEPSM- s SM- sCASSPA Looku p ServiceSM-LFigure 1 A SPA SpaceWire subnet A SpaceWire network has only two classes of devices definedrouters and nodes. Routers facilitate the direction of data within the network, accepting a

34、 datagram on one port and routing it out a designated port. This steering of data is governed by a path routing addressing scheme that simply looks at the first byte of the datagram to determine which outgoing port is to be taken. An endpoint in a SPA SpaceWire subnet must be a SPA compliant device.

35、 In order to comply with the SPA standard the device must conform to the data, power, timing, grounding, and test bypass specification called out in the SPA standard documentation. The endpoint must also be capable of supporting the discovery protocol defined within this document if it is to be usab

36、le on a SPA-S network. Processors must similarly comply with the described protocols and may also host a software application responsible for performing the discovery function on the SPA-S network. These applications (there may be many on the network accomplishing the same discovery activity and neg

37、otiating a master) are the originators of the message set described in this document. 5.1 Normative SpaceWire Header SpaceWire messaging in SPA follows the packet composition specification (ECSS-E-50-12C Section 9.2). A SPA SpaceWire packet consists of three parts (see Figure 2). Destination Address

38、 Field: This field consists of one or more address fields to be used to route the packet internally to the SpaceWire subnet. A SpaceWire address may either use logical addressing, or path routing. Path routing specifies the route as a series of port numbers, on which the packet is transmitted at eac

39、h hop in the fabric. As a path route is used, it is deleted. The path addressing routing bytes are stripped off by the router(s), and are not present in the packet at the destination. Each byte of the Path Routing refers to the SpaceWire port on which the packet should exit the router. Note that if

40、a router receives a message whose first byte is 0x0, the router understands this to be a message destined for the router internal logic, as specified in the SpaceWire standard. In this case the packet will not be forwarded but will be consumed locally by the router. In order to distinguish the Space

41、Wire address field from the body of the packet, a 0xFE character is appended at the end of the routing field. In the SpaceWire standard, 0xFE is a legal logical address. In the SpaceWire Subnet adaptation standard of SPA, an address of 0xFE is not a legal AIAA S-133-9-2013 5 path route or logical ad

42、dress and may not be used. This will cause the packet to be dropped by a SpaceWire router if a packet is received with that route for the current hop. This property is useful for topology discovery, when the manager does not know how many hops exist in the fabric, as it ensures that a router will no

43、t process the encapsulated SPA message body as a routing field, if the true path routing field has been deleted. A logical address is used in a lookup table within the fabric to select an output port number for packet transmission. The logical address used would be the same at each hop in the fabric

44、. Although the SPA SpaceWire subnet standard requires path routing for topology discovery and inter-subnet communication, an implementer may optionally use logical addressing for local communication within a subnet. Cargo: The cargo is the body of the SpaceWire packet, and contains the encapsulated

45、SPA packet. End of Packet Marker: The end-of-packet marker is a special SpaceWire symbol marking the boundary of the packet during transmission. In the SPA adaptation layer it would follow the last byte of the SPA packet. D E S T I N A T I O N A D D R E S S C A R G O E N D O F P A C K E TM A R K E R

46、 Figure 2 SpaceWire packet format 6 Topology Discovery Topology discovery is the process by which an SM-s identifies the positions of the routers and endpoints within the SpaceWire subnet. Although the SM-s is optionally permitted to store and load a set configuration without undergoing topology dis

47、covery, it is assumed that all designs will need to perform discovery at least once, and must be capable of performing topology discovery on demand. An example of topology discovery is discussed in Annex A. An implementer is free to use this approach or their own, as long as their implementation con

48、forms to the requirements listed in Section 11 for SPA SpaceWire Subnet components (see Annex B). At the end of topology discovery throughout the SPA network, the following should be true for each endpoint and SM-s in the subnet: An SM-s should Know the path route to each endpoint in the subnet Know

49、 the processes currently active in each endpoint, have requested a logical address block from the CAS for them per SPA Networking Specification, and have applied an address to each process Know the path route to each SM-s residing within the subnet Know the logical address of all other core components (SM-x, CAS, SPA Lookup Service) in the SPA network; the procedure for obtaining logical addresses is outlined in the SPA networking specification and will not be addressed here Notify the