20 - 26;
These non-RFC
option types are not considered in this document. This only means that their
behavior is not described in detail, as a compression scheme is not expected to
be optimized for these options. However,
any unrecognized option must be carried by a TCP compression scheme
transparently, in order to work efficiently in the presence of new or rare
options.
이들 비-RFC 옵션 값은 이 문서에서는 고려되지 않습니다. 이것은 단지 압축
틀에서 이들 옵션 값을 최적화를 고려하지 않아도 되기 때문에 자세히 이야기하지 않는 것입니다. 하지만, 새롭거나 잘 쓰이지 않는 옵션에서 효율적으로 작동하기 위해서 어떠한 알지 못하는 옵션 값이라도 TCP 압축 틀이 투명(명확)하게
보내어 져야 합니다.
The above list
covers options known at the time of writing.
Other options are expected to be defined. It is important that any future options can
be handled by a header compression scheme.
The processing of as-yet undefined options cannot be optimised but, at
the very least, unknown options should be carried transparently.
상위에서 다루는 옵션들은 글을
쓸 때 알려진 것들입니다. 다른 옵션들은 정의 되길 기대되는 것들입니다. 이는 이후 어떤 옵션 값들이 헤더 압축 틀에 의해 다루어 질 수 있다는 것을 의미합니다. 알려지지 않은 옵션 값들은 최적화할 수는 없지만, 적어도 알 수
없는 옵션 값은 투명성을 지니고 전송이 되어야 합니다.
The current model
for TCP options is that an option is negotiated in the SYN exchange and used
thereafter, if the negotiation succeeds. This leads to some assumptions about
the presence of options (being only on packets with the SYN flag set, or
appearing on every packet, for example).
Where such assumptions hold true, it may be possible to optimise
compression of options slightly.
However, it is seen as undesirable to be so constrained, as there is no
guarantee that option handling and negotiation will remain the same in the
future. Also note that a compressor may not process the SYN packets of a flow
and cannot, therefore, be assumed to know which options have been negotiated.
현재 TCP 옵션 모델은 SYN 교환 시에 교섭(니고시에이션)이 완성되며 만약 교섭이 성공했다면 이는 다른 옵션의
존재에 대한 가정을 이끌 수 있습니다. (예. SYN 플래그가
설정되어 있는 패킷에 한정 또는 어떤 패킷) 그런 가정이 사실인 곳에,
옵션 핸들링(다루기)과 교환이 이후에도 계속
남아 있으므로, 가볍게 옵션 압축을 최적화 하는 것이 가능합니다. 또한, 압축기는 흐름 속에 있는 SYN 패킷을 바꾸어서는 안 되며 따라서
어떤 옵션이 교환되는지 가정할 수 없습니다..
(RFC 문서에 다루지 않으므로 따로 조사하여
추가했습니다.)
20: SCPS Capabilities
20: SCPS 기능
참고
http://en.wikipedia.org/wiki/Space_Communications_Protocol_Specifications"
http://nost.gsfc.nasa.gov/wwwclassic/documents/pdf/CCSDS-714.0-B-1.pdf
The Space Communications
Protocol Specifications (SCPS) are a set of extensions to existing protocols
and new protocols developed by the Consultative Committee for Space Data
Systems (CCSDS) to improve performance of Internet protocols in space
environments. The SCPS protocol stack consists of:
우주 통신 프로토콜 규정(SCPS)는 기존의 프로토콜의 확장이면서 우주 환경 속에서 향상된 통신을 위해 우주 자료 시스템 자문회(SCPS)에 의해 규정된 새로운 인터넷 프토토콜 입니다. SCPS 는
다음의 스택으로 프로토콜 구성되어 있습니다.
SCPS-FP -- A set of extensions to FTP to make it more bit
efficient and to add advanced features such as record update within a file and
integrity checking on file transfers.
SCPS-FP
– 기존 FTP 의 확장으로 좀 더 비트에 효율적이고 파일 전송에 무결성 검사 내 레코드 업데이트(갱신) 같은 추가 전문적인 기능이 담겨 있는 프로토콜입니다.
SCPS-TP -- A set of TCP options and sender-side modifications
to improve TCP performance in stressed environments including long delays, high
bit error rates, and significant assymetries. The SCPS-TP options are TCP
options registered with the Internet Assigned Numbers Authority (IANA) and
hence SCPS-TP is compatible with other well-behaved TCP implementations.
SCPS-TP
– 송신자가
높은 오류 수정비, 그리고 방대한 비대칭, 오래된 지연을
포함하는 악조건의 환경에서 수행할 수 있게 TCP를 수정한 TCP 옵션입니다. SCPS-TP 옵션들은 TCP 옵션으로 인터넷 번호 할당 기관(IANA, 아이아나)에 등록되어 있으므로 다른 TCP 구현과 잘 호환이 됩니다.
SCPS-SP -- A security protocol comparable to IPsec
SCPS-SP – IPSEC 과 호환이 되는 보안 프로토콜입니다.
SCPS-NP -- A
bit-efficient network protocol analogous to but not interoperable with IP The
SCPS protocol that has seen the most use commercially is SCPS-TP, usually
deployed as a Performance Enhancing Proxy (PEP) to improve TCP performance over
satellite links.
IP와 내부 호환되지는 않지만 비트-효율성을 지닌 네트워크 프로토콜입니다. 상업적으로 잘 쓰는 것은 SCPS-TP 이고 보통, 위성 링크를 통한 TCP 성능을 개선하기 위한 성능 개선 프록시를 쓰는데 시용 됩니다.
