rfc814.txt

RFC 相关的技术文档

Finally, additional IP options have been proposed to identify particular

routes  within  the internet that are unacceptable.  The difficulty with

implementing these new features  is  that  the  mechanisms  do  not  lie

                                   8


entirely within the bounds of IP.  All the mechanisms above are designed

to apply to a particular connection, so that their use must be specified

at  the  TCP level.  Thus, the interface between IP and the layers above

it must include mechanisms to allow passing this  information  back  and

forth,  and TCP (or any other protocol at this level, such as UDP), must

be prepared to store this  information.    The  passing  of  information

between IP and TCP is made more complicated by the fact that some of the

information,  in  particular  ICMP packets, may arrive at any time.  The

normal interface envisioned between TCP  and  IP  is  one  across  which

packets  can  be  sent  or received.  The existence of asynchronous ICMP

messages implies that there must be an additional  channel  between  the

two,  unrelated  to the actual sending and receiving of data.  (In fact,

there are many other ICMP messages which arrive asynchronously and which

must be passed from IP  up  to  higher  layers.    See  RFC  816,  Fault

Isolation and Recovery.)


     Source  routes  are  already  in  use  in  the  internet,  and many

implementations will wish to be able to take advantage  of  them.    The

following  sorts  of  usages  should  be permitted.  First, a user, when

initiating a TCP connection, should be able to hand a source route  into

TCP,  which in turn must hand the source route to IP with every outgoing

datagram.  The user might initially obtain the source route by  querying

a  different  sort  of  name  server,  which would return a source route

instead of an address, or the user may have fabricated the source  route

manually.    A  TCP  which  is  listening  for a connection, rather than

attempting to open one, must be prepared to  receive  a  datagram  which

contains  a  IP return route, in which case it must remember this return

route, and use it as a source route on all returning datagrams.

                                   9


     6.  Ports and Service Identifiers


     The  IP  layer of the architecture contains the address information

which specifies the destination host to  which  the  datagram  is  being

sent.    In  fact, datagrams are not intended just for particular hosts,

but for particular agents within a host,  processes  or  other  entities

that  are  the  actual  source and sink of the data.  IP performs only a

very simple dispatching once the datagram  has  arrived  at  the  target

host,   it   dispatches  it  to  a  particular  protocol.    It  is  the

responsibility of that protocol handler,  for  example  TCP,  to  finish

dispatching  the  datagram  to the particular connection for which it is

destined.    This  next  layer  of  dispatching  is  done  using   "port

identifiers",  which  are  a  part  of  the  header  of the higher level

protocol, and not the IP layer.


     This two-layer dispatching architecture has caused  a  problem  for

certain  implementations.    In  particular,  some  implementations have

wished to put the IP layer within the kernel of  the  operating  system,

and  the  TCP  layer  as  a  user  domain  application  program.  Strict

adherence to this partitioning can lead to grave  performance  problems,

for  the  datagram  must  first  be  dispatched from the kernel to a TCP

process, which then dispatches the datagram  to  its  final  destination

process.   The overhead of scheduling this dispatch process can severely

limit the achievable throughput of the implementation.


     As is discussed in RFC 817, Modularity and Efficiency  in  Protocol

Implementations,  this  particular  separation  between  kernel and user

leads to other performance problems, even ignoring  the  issue  of  port

                                   10


level  dispatching.   However, there is an acceptable shortcut which can

be taken to move the higher  level  dispatching  function  into  the  IP

layer, if this makes the implementation substantially easier.


     In  principle,  every  higher level protocol could have a different

dispatching  algorithm.    The  reason  for  this  is  discussed  below.

However,  for  the  protocols  involved  in  the  service offering being

implemented today, TCP and UDP, the dispatching algorithm is exactly the

same, and the port field is located in precisely the same place  in  the

header.  Therefore, unless one is interested in participating in further

protocol  research,  there  is only one higher level dispatch algorithm.

This algorithm takes into account the internet  level  foreign  address,

the protocol number, and the local port and foreign port from the higher

level  protocol  header.  This algorithm can be implemented as a sort of

adjunct to the IP layer implementation, as long as no other higher level

protocols are to be implemented.  (Actually, the above statement is only

partially true, in that the UDP dispatch function is subset of  the  TCP

dispatch  function.  UDP dispatch depends only protocol number and local

port.  However, there is an occasion within TCP  when  this  exact  same

subset comes into play, when a process wishes to listen for a connection

from  any  foreign  host.    Thus,  the range of mechanisms necessary to

support TCP dispatch are also sufficient to support  precisely  the  UDP

requirement.)


     The decision to remove port level dispatching from IP to the higher

level  protocol  has  been questioned by some implementors.  It has been

argued that if all of the address structure were part of the  IP  layer,

                                   11


then IP could do all of the packet dispatching function within the host,

which  would  lead  to  a  simpler  modularity.    Three  problems  were

identified with this.  First, not all protocol implementors could  agree

on  the  size  of the port identifier.  TCP selected a fairly short port

identifier, 16 bits, to reduce  header  size.    Other  protocols  being

designed,  however, wanted a larger port identifier, perhaps 32 bits, so

that the port identifier, if  properly  selected,  could  be  considered

probabilistically  unique.    Thus,  constraining  the  port  id  to one

particular IP level mechanism would prevent certain  fruitful  lines  of

research.    Second,  ports  serve  a  special  function  in addition to

datagram delivery:   certain  port  numbers  are  reserved  to  identify

particular services.  Thus, TCP port 23 is the remote login service.  If

ports  were  implemented  at  the  IP level, then the assignment of well

known ports could not be done on a protocol basis, but would have to  be

done  in a centralized manner for all of the IP architecture.  Third, IP

was designed with a very simple layering role:    IP  contained  exactly

those functions that the gateways must understand.  If the port idea had

been  made a part of the IP layer, it would have suggested that gateways

needed to know about ports, which is not the case.


     There are, of course, other ways  to  avoid  these  problems.    In

particular,  the  "well-known  port" problem can be solved by devising a

second mechanism, distinct from port  dispatching,  to  name  well-known

ports.   Several protocols have settled on the idea of including, in the

packet which sets up a  connection  to  a  particular  service,  a  more

general  service  descriptor,  such  as a character string field.  These

special  packets,  which  are  requesting  connection  to  a  particular

                                   12


service,  are  routed on arrival to a special server, sometimes called a

"rendezvous server", which  examines  the  service  request,  selects  a

random  port  which  is to be used for this instance of the service, and

then passes the packet along to  the  service  itself  to  commence  the

interaction.


     For  the  internet architecture, this strategy had the serious flaw

that it presumed all protocols would fit into the same service paradigm:

an initial setup phase, which might contain a certain overhead  such  as

indirect routing through a rendezvous server, followed by the packets of

the  interaction  itself,  which  would  flow  directly  to  the process

providing the service.  Unfortunately, not all high level  protocols  in

internet  were  expected to fit this model.  The best example of this is

isolated datagram exchange using UDP.  The simplest exchange in  UDP  is

one process sending a single datagram to another.  Especially on a local

net,  where  the  net  related overhead is very low, this kind of simple

single datagram interchange can be extremely efficient,  with  very  low

overhead  in  the  hosts.  However, since these individual packets would

not be part of an established connection, if  IP  supported  a  strategy

based  on  a  rendezvous  server and service descriptors, every isolated

datagram would have to  be  routed  indirectly  in  the  receiving  host

through  the  rendezvous  server, which would substantially increase the

overhead of processing, and every datagram would have to carry the  full

service  request  field,  which  would  increase  the size of the packet

header.


     In general, if a network is intended for "virtual circuit service",

                                   13


or  things similar to that, then using a special high overhead mechanism

for circuit setup makes sense.  However, current directions in  research

are  leading  away  from  this  class  of  protocol,  so  once again the

architecture  was  designed  not  to   preclude   alternative   protocol

structures.    The  only  rational  position  was  that  the  particular

dispatching strategy used should be part of the  higher  level  protocol

design, not the IP layer.


     This  same  argument about circuit setup mechanisms also applies to

the design of the IP address structure.  Many protocols do not  transmit

a  full  address  field  as  part of every packet, but rather transmit a

short identifier which is created as part of a circuit setup from source

to destination.  If the full address needs to be  carried  in  only  the

first  packet  of  a long exchange, then the overhead of carrying a very

long address field can easily be justified.  Under these  circumstances,

one  can  create  truly extravagant address fields, which are capable of

extending to address almost  any  conceivable  entity.    However,  this

strategy  is  useable  only  in a virtual circuit net, where the packets

being transmitted are part of a  established  sequence,  otherwise  this

large  extravagant  address  must be transported on every packet.  Since

Internet explicitly rejected this restriction on  the  architecture,  it

was  necessary  to come up with an address field that was compact enough

to be sent in every datagram, but general enough to correctly route  the

datagram  through  the  catanet  without a previous setup phase.  The IP

address of 32 bits is the compromise that results.  Clearly it  requires

a  substantial  amount  of shoehorning to address all of the interesting

places in the universe with only 32 bits.  On the other  hand,  had  the

                                   14


address  field  become  much  bigger,  IP would have been susceptible to

another criticism, which is that the header had grown unworkably  large.

Again, the fundamental design decision was that the protocol be designed

in  such  a way that it supported research in new and different sorts of

protocol architectures.


     There are some limited restrictions imposed by the IP design on the

port mechanism selected by the higher level  process.    In  particular,

when  a packet goes awry somewhere on the internet, the offending packet

is returned, along with an error indication, as part of an ICMP  packet.

An  ICMP  packet  returns only the IP layer, and the next 64 bits of the

original datagram.  Thus, any higher level protocol which wishes to sort

out from which port a particular offending datagram came must make  sure

that  the  port information is contained within the first 64 bits of the

next level header.  This also means, in most cases, that it is  possible

to  imagine,  as  part  of the IP layer, a port dispatch mechanism which

works by masking and matching on the  first  64  bits  of  the  incoming

higher level header.