ISO 20206 pdf download – Space data and information transfer systems —IPover ccSDs space links

ISO 20206 pdf download – Space data and information transfer systems —IPover ccSDs space links.
2.4.2 IPE HEADER ENLiMERATIOS A%I) MAPPINGS
There often are many IP data types that require encapsulation. The exact number of protocols depends on the mission and its requirements. These protocols are fully defined in other data standards. Thus the intent here is to identify only auxiliary Pifli formats that are often used in support of IP. As a comparison, serial links between routers often carry the 16-bit Point- to-Point Protocol (PPP) proocol field, and the Ethernet PDUs carry a 16-bit Ethernet type field. In these cases, the enumerations of the protocols arc defined by the Internet Assigned Numbers Authority (lANA) and the Institute of Elcetrical and Electronics Engineers (IEEE). respectively. The tables containing the enumerations then point to the standards that define the protocols themselves.
The alternative approach would have been to encapsulate a conventional link layer, such as Multiprotocol over Frame Relay, and use its methods for identifying the auxiliary PDU formats.
Auxiliary protocols nominally identified at the Data Link Layer in support of IP include lP4, lPv6, IP compressed header formats, the address resolution protocol for multi-access link layers, link layer control protocols including link metrics exchange and link health monitoring, various Data Link and Network Layer configuration protocols, and authentication protocols.
Addressing and routing protocols often tie into these protocols via initial configuration exchanges and link state up’down infonnation. It should be noted, however, that routing protocols such as Open Shortest Path First (OSPF), Protocol-Independent Multicast (PIM), and Border Gateway Protocol (BGP) also maintain their own adjacency or state via hello exchanges or refreshes ut the Network Layer.
Most of these protocols arc built around bidirectional links and require bidirectional exchanges. Since in the space environment it is expected that Network Layer protocols will have to be able to use one-way links, it is not recommended that these protocols be required. It is believed that if fairly simple networks are involved, and they are monitored in a transparent manner, it is possible to use prearranged static settings rather than dynamic exchanges to verify and maintain correct configuration. Ilowever. ifappropriate for the mission. use of these protocols is not prohibited.
4.1.8 The IPE header value shall be the decimal value of the contcnts of the entire IPE header.
NoTE – Only the odd IPE header values are valid, since the LSH of the least signiticant octet must hae a value nfl’.
If the I PE header consists of a single octet, then only odd IPE header values from I to 255 are alid.
If the IPE header consists of two or more octets, then
— odd IPE header values from I to 255 are valid:
— no IPE header values from 256 to 511 are valid (since the value of the LSI3 in the second least signiticant octet must have a value of ‘0’):
— odd IPE header values from 513 to 767 are valid:
— no IPE header values from 76X to 1023 are valid (since the value of the LSH in the second least significant octet must have a value of’O’).
This pattern continues across the entire IPE header space.
4.2 PROTOCOL PROCEDURES AT THE SENDING END
The IPoC entity at the sending end shall:
— build the IPE Header relevant to the given IP P013 received from the user, as defined by the IPE_Hcadcr_Value parameter:
— prepend the IPE Header to the IP PDU:
— pass this result to the Encapsulation Service as the SDU.
4.3 PROTOCOL PRoCEDURES AT THE RECEIVING END
The IPoC entity at the receiving end shall:
— receive the SDU from the Encapsulation Service:
— extract and decode the IPE I leader:
deliver the IP P013 to the user.