RFC 795: Service mappings (original) (raw)

[RFC Home] [TEXT|PDF|HTML] [Tracker] [IPR] [Info page]

HISTORIC

Network Working Group J. Postel Request for Comments: 795 ISI September 1981 SERVICE MAPPINGS ----------------

This memo describes the relationship between the Internet Protocol (IP) [[1](#ref-1 ""Internet Protocol - DARPA Internet Program Protocol Specification,"")] Type of Service and the service parameters of specific networks.

The IP Type of Service has the following fields:

Bits 0-2: Precedence. Bit 3: 0 = Normal Delay, 1 = Low Delay. Bits 4: 0 = Normal Throughput, 1 = High Throughput. Bits 5: 0 = Normal Relibility, 1 = High Relibility. Bit 6-7: Reserved for Future Use.

  0     1     2     3     4     5     6     7

+-----+-----+-----+-----+-----+-----+-----+-----+ | | | | | | | | PRECEDENCE | D | T | R | 0 | 0 | | | | | | | | +-----+-----+-----+-----+-----+-----+-----+-----+

111 - Network Control 110 - Internetwork Control 101 - CRITIC/ECP 100 - Flash Override 011 - Flash 010 - Immediate 001 - Priority 000 - Routine

The individual networks listed here have very different and specific service choices.

Postel [Page 1]


                                                      September 1981

RFC 795 Service Mappings

AUTODIN II

The service choices are in two parts: Traffic Acceptance Catagories, and Application Type. The Traffic Acceptance Catagories can be mapped into and out of the IP TOS precedence reasonably directly. The Application types can be mapped into the remaining IP TOS fields as follows.

  TA    DELAY    THROUGHPUT    RELIABILITY
  ---   -----    ----------    -----------
  I/A     1           0             0
  Q/R     0           0             0
  B1      0           1             0
  B2      0           1             1

  DTR    TA
  ---   ---
  000   Q/R
  001   Q/R
  010    B1
  011    B2
  100   I/A
  101   I/A
  110   I/A
  111   error

Postel [Page 2]


                                                      September 1981

RFC 795 Service Mappings

ARPANET

The service choices are in quite limited. There is one priority bit that can be mapped to the high order bit of the IP TOS precedence. The other choices are to use the regular ("Type 0") messages vs. the uncontrolled ("Type 3") messages, or to use single packet vs. multipacket messages. The mapping of ARPANET parameters into IP TOS parameters can be as follows.

  Type   Size   DELAY    THROUGHPUT    RELIABILITY
  ----   ----   -----    ----------    -----------
    0      S      1           0             0
    0      M      0           0             0
    3      S      1           0             0
    3      M      not allowed

  DTR   Type   Size
  ---   ----   ----
  000     0      M
  001     0      M
  010     0      M
  011     0      M
  100     3      S
  101     0      S
  110     3      S
  111       error

Postel [Page 3]


                                                      September 1981

RFC 795 Service Mappings

PRNET

There is no priority indication. The two choices are to use the station routing vs. point-to-point routing, or to require acknowledgments vs. having no acknowledgments. The mapping of PRNET parameters into IP TOS parameters can be as follows.

  Routing   Acks    DELAY    THROUGHPUT    RELIABILITY
  -------   ----    -----    ----------    -----------
    ptp      no       1           0             0
    ptp      yes      1           0             1
  station    no       0           0             0
  station    yes      0           0             1

  DTR   Routing   Acks
  ---   -------   ----
  000   station    no
  001   station    yes
  010   station    no
  011   station    yes
  100     ptp      no
  101     ptp      yes
  110     ptp      no
  111     ptp      yes

SATNET

There is no priority indication. The four choices are to use the block vs. stream type, to select one of four delay catagories, to select one of two holding time strategies, or to request one of three reliability levels. The mapping of SATNET parameters into IP TOS parameters can thus quite complex there being 242*3=48 distinct possibilities.

References

[1] Postel, J. (ed.), "Internet Protocol - DARPA Internet Program Protocol Specification," RFC 791, USC/Information Sciences Institute, September 1981.

Postel [Page 4]