1. © 2004 The MITRE Corporation. All rights reserved SCPS-TP Updates Cislunar WG Meeting CCSDS Toulouse November 2004

2. © 2004 The MITRE Corporation. All rights reserved Agenda n Current Status n Clarifications of existing SCPS-TP capabilities –Compressed header –ECN support n Extending the SCPS Capabilities Option –Rationale –Xiphos’ Proposal –TLV Proposal –Discussion

3. © 2004 The MITRE Corporation. All rights reserved Current Status n SCPS-Capabilities Option (TCP Option 20) –Allows endpoints to negotiate which SCPS options they support n Compressed SCPS Transport Protocol (IPPROTO 105) n A number of vendors using SCPS-TP –Interoperability issues n SCPS-RI Mapping of compressed bit vector not matching spec. n What connection IDs to use n Protocol# to use in pseudo-header checksum for compressed connections n Compressed (short-form) SNACK option n ECN n Reserved bits use –Extended capabilities for vendor-specific

4. © 2004 The MITRE Corporation. All rights reserved

5. Clarification issues wrt compressed header 1. Which "Connection ID" do you use in constructing compressed SCPS-TP headers? 2. When computing the checksum for the compressed SCPS-TP headers, what protocol number do you use for populating the pseudo-header? 3. Encoding of SNACK options: Do you treat any/all SNACK options on a TCP header as incompressible options or do you make use of the SNACK bit in the Compressed Header Bit-Vector for encoding the first SNACK option on a segment? 4. Encoding of ECN bits in a TCP Header: RFC 3168 defines two of the previously Reserved 6 bits in a TCP header: –Bit 8 CWR (Congestion Window Reduced) –Bit 9 ECE (ECN-Echo) –Do any other implementors handle these with respect to compressed SCPS-TP Headers, and if so how? –How could we support ECN? 5. Usage of reserved bits in the Compressed Header Bit-Vector

6. © 2004 The MITRE Corporation. All rights reserved Which "Connection ID" do you use in constructing compressed SCPS-TP headers? n Connection ID you provided the peer? n Connection ID the peer provided? SCPS-RI The one provided _TO_ the peer. Global ProtocolsThe one provided _TO_ the peer. XiphosThe one provided _TO_ the peer.

7. © 2004 The MITRE Corporation. All rights reserved When computing the header checksum for the compressed SCPS-TP headers, what protocol number do you use for populating the pseudo- header? n Protocol 105 – Compressed SCPS-TP n Protocol 6 – TCP SCPS-RISCPS-RI now uses 105, and tries to _decode_ using 6 if 105 doesn’t work. Global Protocols105 Xiphos105

8. © 2004 The MITRE Corporation. All rights reserved Do you treat any/all SNACK options on a TCP header as incompressible options or do you make use of the SNACK bit in the Compressed Header Bit-Vector for encoding the first SNACK option on a segment? SCPS-RIDoes not implement compressed SNACK (all SNACK options uncompressed). Global ProtocolsCompresses first SNACK option. 2 nd, 3 rd, etc. SNACK options are carried uncompressed. XiphosSNACK bit included in compressed header, all SNACK options uncompressed.

9. © 2004 The MITRE Corporation. All rights reserved Encoding of ECN bits in a TCP Header n Supports ECN n Doesn’t support ECN SCPS-RINo ECN support. Global ProtocolsNo ECN support for compressed connections XiphosNo ECN support.

10. © 2004 The MITRE Corporation. All rights reserved Usage of reserved bits in the Compressed Header Bit-Vector SCPS-RINone. Global ProtocolsNo, but they want to XiphosNo, but they want to

11. © 2004 The MITRE Corporation. All rights reserved Recommendations n The Connection ID used is always the one provided _to_ the peer during the syn/syn-ack exchange n Protocol #105 shall be used in the pseudo-header when computing the checksum for compressed headers. n Deal with compressed SNACKs in a minute n ECN (RFC3168) should be supported. n Deal with reserved bits in a minute.

12. © 2004 The MITRE Corporation. All rights reserved Recommendation: Clarify the SNACK bit in the compressed header. n Table 3-2: Compressed Header Bit Vector Contents –Bit Name: SNACK –Meaning when set to 1: Short form SNACK option present –Notes: n Insert between 3.6.2.8 and 3.6.2.9 in current spec: –3.6.2.9 Compressed Short-form SNACK Option –The compressed short-form SNACK bit shall be set whenever a short-form (i.e. NOT including a SNACK bit-vector) SNACK option is present, and shall occupy 4 octets immediately following the Sequence Number field. –The first two bytes of the compressed short-form SNACK option shall contain the hole1 offset (see yyy). The next two bytes shall contain the hole1 size (see yyy2). –Other SNACK options, including _all_ long-form options (those with uncompressed option lengths greater than 6 bytes) must be carried in the UNCOMPRESSED TCP Options portion of the compressed header. Spec – C2.5.2

13. © 2004 The MITRE Corporation. All rights reserved Recommendation: Define the SNACK bit in the compressed header (cont’d) n Update fig. 3-5 to reflect encoding of compressed short- form SNACK option.

14. © 2004 The MITRE Corporation. All rights reserved Extending the SCPS Capabilities Option n Rationale n Xiphos’ Proposal n TLV Proposal n Discussion

15. © 2004 The MITRE Corporation. All rights reserved Rationale for Extending the SCPS Capabilities Option n There are now a number of vendors implementing SCPS PEPs –Desire to differentiate themselves by providing ‘special’ services n Associate ‘session’ kinds of information with connections, signal payload compression, … –Need for additional capability signaling/negotiation. This can be done: n As part of the SCPS Capabilities Option exchange n As a (set of) other TCP Options (would need experimental RFCs) n Other n SCPS-Capabilities Option goes from fixed-length (4 bytes) to variable length –Need to check with IANA n Changing SCPS Capabilities option to variable-length n Managing assignment of ‘extension types’

16. © 2004 The MITRE Corporation. All rights reserved Xiphos’ Proposed Extensions n Xiphos’ extension proposal –Define a number of vendor types –Each vendor can define vendor-specific stuff –One vendor type per implementation (all SCPS-RI derived PEPs would share one vendor space?)

17. © 2004 The MITRE Corporation. All rights reserved General TLV Extension Mechanism n General TLV extension of SCPS Capabilities –# of bits for type, length? SCPS Option Type (20) SCPS Option Length BETSSN1SN2ComNL TSext Connection ID TypeLen Stuff… SCPS Option Type (20) SCPS Option Length BETSSN1SN2ComNL TSext Connection ID Type Stuff… Length n 6 bits of type, 2 bits of length n 8 bits of type, 8 bits of length

18. © 2004 The MITRE Corporation. All rights reserved Next Steps for SCPS-TP n Post ‘interoperability resolutions’ to the list –Discussion –Accept –Mid-Dec. n More discussion of extension options on the list –Make sure all (known) vendors are aware –Mid-end of Dec. n Final resolutions to the list –WG consensus –Dec. – Revised blue book. n Generate ‘Pink Sheets’ for agency review –Jan – (getting the pink sheets pushed out to agencies)

19. © 2004 The MITRE Corporation. All rights reserved Next Steps for Cislunar Documents n Other SCPS Protocols (FP, SP, NP) –Updated web site ($$$) n SCPS-RI Vegas modifications n Green Book –architecture, –Use cases n Document describing candidate protocols (solutions) –X –Scps