SCPS-TP Discussions

Download Report

Transcript SCPS-TP Discussions

SCPS-TP Updates
Cislunar WG Meeting
CCSDS Toulouse
November 2004
© 2004 The MITRE Corporation. All rights reserved
Agenda

Current Status

Clarifications of existing SCPS-TP capabilities
– Compressed header
– ECN support

Extending the SCPS Capabilities Option
–
–
–
–
Rationale
Xiphos’ Proposal
TLV Proposal
Discussion
© 2004 The MITRE Corporation. All rights reserved
Current Status

SCPS-Capabilities Option (TCP Option 20)
– Allows endpoints to negotiate which SCPS options they
support


Compressed SCPS Transport Protocol (IPPROTO 105)
A number of vendors using SCPS-TP
– Interoperability issues

SCPS-RI Mapping of compressed bit vector not matching spec.

What connection IDs to use

Protocol# to use in pseudo-header checksum for compressed
connections

Compressed (short-form) SNACK option

ECN

Reserved bits use
– Extended capabilities for vendor-specific
© 2004 The MITRE Corporation. All rights reserved
© 2004 The MITRE Corporation. All rights reserved
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:
5.
–
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?
Usage of reserved bits in the Compressed Header Bit-Vector
© 2004 The MITRE Corporation. All rights reserved
Which "Connection ID" do you use in
constructing compressed SCPS-TP headers?
Connection
ID you provided the peer?
Connection
ID the peer provided?
SCPS-RI
The one provided _TO_ the peer.
Global Protocols
The one provided _TO_ the peer.
Xiphos
The one provided _TO_ the peer.
© 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 pseudoheader?
Protocol
105 – Compressed SCPS-TP
Protocol
6 – TCP
SCPS-RI
SCPS-RI now uses 105, and tries
to _decode_ using 6 if 105
doesn’t work.
Global Protocols
105
Xiphos
105
© 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-RI
Does not implement
compressed SNACK (all SNACK
options uncompressed).
Global Protocols
Compresses first SNACK option.
2nd, 3rd, etc. SNACK options are
carried uncompressed.
Xiphos
SNACK bit included in
compressed header, all SNACK
options uncompressed.
© 2004 The MITRE Corporation. All rights reserved
Encoding of ECN bits in a TCP Header
Supports
Doesn’t
ECN
support ECN
SCPS-RI
No ECN support.
Global Protocols
No ECN support for compressed
connections
Xiphos
No ECN support.
© 2004 The MITRE Corporation. All rights reserved
Usage of reserved bits in the
Compressed Header Bit-Vector
SCPS-RI
None.
Global Protocols
No, but they want to
Xiphos
No, but they want to
© 2004 The MITRE Corporation. All rights reserved
Recommendations





The Connection ID used is always the one provided _to_ the
peer during the syn/syn-ack exchange
Protocol #105 shall be used in the pseudo-header when
computing the checksum for compressed headers.
Deal with compressed SNACKs in a minute
ECN (RFC3168) should be supported.
Deal with reserved bits in a minute.
© 2004 The MITRE Corporation. All rights reserved
Recommendation: Clarify the SNACK bit
in the compressed header.

Table 3-2: Compressed Header Bit Vector Contents
– Bit Name: SNACK
– Meaning when set to 1: Short form SNACK option present
– Notes: <None>

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
Spec – C2.5.2
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.
© 2004 The MITRE Corporation. All rights reserved
Recommendation: Define the SNACK bit
in the compressed header (cont’d)

Update fig. 3-5 to reflect encoding of compressed shortform SNACK option.
© 2004 The MITRE Corporation. All rights reserved
Extending the SCPS Capabilities Option




Rationale
Xiphos’ Proposal
TLV Proposal
Discussion
© 2004 The MITRE Corporation. All rights reserved
Rationale for Extending the SCPS
Capabilities Option

There are now a number of vendors implementing SCPS
PEPs
– Desire to differentiate themselves by providing ‘special’
services

Associate ‘session’ kinds of information with connections, signal
payload compression, …
– Need for additional capability signaling/negotiation. This can
be done:


As part of the SCPS Capabilities Option exchange

As a (set of) other TCP Options (would need experimental RFCs)

Other
SCPS-Capabilities Option goes from fixed-length (4 bytes)
to variable length
– Need to check with IANA

Changing SCPS Capabilities option to variable-length

Managing assignment of ‘extension types’
© 2004 The MITRE Corporation. All rights reserved
Xiphos’ Proposed Extensions

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?)
© 2004 The MITRE Corporation. All rights reserved
General TLV Extension Mechanism

General TLV extension of SCPS Capabilities
– # of bits for type, length?
SCPS Option Type (20)

6 bits of type, 2 bits of length

8 bits of type, 8 bits of length
SCPS Option Length
BETS
SN1
SN2
Com NL TS
ext
Connection ID
Type
Len
Stuff…
SCPS Option Type (20)
SCPS Option Length
BETS
SN1
SN2
Com NL TS
ext
Connection ID
Type
Length
Stuff…
© 2004 The MITRE Corporation. All rights reserved
Next Steps for SCPS-TP

Post ‘interoperability resolutions’ to the list
– Discussion
– Accept
– Mid-Dec.

More discussion of extension options on the list
– Make sure all (known) vendors are aware
– Mid-end of Dec.

Final resolutions to the list
– WG consensus
– Dec. – Revised blue book.

Generate ‘Pink Sheets’ for agency review
– Jan – (getting the pink sheets pushed out to agencies)
© 2004 The MITRE Corporation. All rights reserved
Next Steps for Cislunar Documents

Other SCPS Protocols (FP, SP, NP)
– Updated web site ($$$)

SCPS-RI Vegas modifications

Green Book
– architecture,
– Use cases

Document describing candidate protocols (solutions)
–
–
–
–
–
X
X
X
X
Scps
© 2004 The MITRE Corporation. All rights reserved