rfc1753.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

   straightforward, and foolproof, to simply identify the flow a packet
   belongs to with by means of a specialized tag field (the "flow-id" )
   in the internetwork header. Given that you can always find situations
   where the existing fields alone don't do the job, and you *still*
   need a separate field to do the job correctly, it seems best to take
   the simple, direct approach , and say "the flow a packet belongs to
   is named by a flow-id in the packet header".

   The simplicity of globally-unique flow-id's (or at least a flow-id
   which unique along the path of the flow) is also desirable; they take
   more bits in the header, but then you don't have to worry about all
   the mechanism needed to remap locally-unique flow-id's, etc., etc.
   From the perspective of designing something with a long lifetime, and
   which is to be deployed widely, simplicity and directness is the only
   way to go. For me, that translates into flows being named solely by
   globally unique flow-id's, rather than some complex semantics on
   existing fields.

   However, the issue of how to recognize which packets belong to flows
   is somewhat orthogonal to the issue of whether the internetwork level
   recognizes flows at all. Should it?





Chiappa                                                        [Page 14]

RFC 1753         Nimrod Technical Requirements for IPng    December 1994


3.2.3 Flows and State

   To the extent that you have service state in the routers you have to
   be able to associate that state with the packets it goes with. This
   is a fundamental reason for flows. Access to service state is one
   reason to explicitly recognize flows at the internetwork layer, but
   it is not the only one.

   If the user has requirements in a number of areas (e.g., routing and
   access control), they can theoretically communicate these to the
   routers by placing a copy of all the relevant information in each
   packet (in the internetwork header). If many subsystems of the
   internetwork are involved, and the requirements are complex, this
   could be a lot of bits.

   (As a final aside, there's clearly no point in storing in the routers
   any user state about packets which are providing datagram service;
   the datagram service has usually come and gone in the same packet,
   and this discussion is all about state retention.)

   There are two schools of thought as to how to proceed. The first says
   that for reasons of robustness and simplicity, all user state ought
   to be repeated in each packet. For efficiency reasons, the routers
   may cache such user state, probably along with precomputed data
   derived from the user state.  (It makes sense to store such cached
   user state along with any applicable server state, of course.)

   The second school says that if something is going to generate lots of
   packets, it makes engineering sense to give all this information to
   the routers once, and from then on have a tag (the flow-id) in the
   packet which tells the routers where to find that information. It's
   simply going to be too inefficient to carry all the user state around
   all the time. This is purely an engineering efficiency reason, but
   it's a significant one.

   There is a slightly deeper argument, which says that the routers will
   inevitably come to contain more user state, and it's simply a
   question of whether that state is installed by an explicit mechanism,
   or whether the routers infer that state from watching the packets
   which pass through them.  To the extent that it is inevitable anyway,
   there are obvious benefits to be gained from recognizing that, and an
   explicit design of the installation is more likely to give
   satisfactory results (as opposed to an ad-hoc mechanism).

   It is worth noting that although the term "flow" is often used to
   refer to this state in the routers along the path of the flow, it is
   important to distinguish between i) a flow as a sequence of packets
   (i.e., the definition given in 3.2.2 above), and ii) a flow, as the



Chiappa                                                        [Page 15]

RFC 1753         Nimrod Technical Requirements for IPng    December 1994


   thing which is set up in the routers. They are different, and
   although the particular meaning is usually clear from the context,
   they are not the same thing at all.

   I'm not sure how much use there is to any intermediate position, in
   which one subsystem installs user state in the routers, and another
   carries a copy of its user state in each packet.

   (There are other intermediate positions. First, one flow might use a
   given technique for all its subsystems, and another flow might use a
   different technique for its; there is potentially some use to this,
   although I'm not sure the cost in complexity of supporting both
   mechanisms is worth the benefits. Second, one flow might use one
   mechanism with one router along its path, and another for a different
   router. A number of different reasons exist as to why one might do
   this, including the fact that not all routers may support the same
   mechanisms simultaneously.)

   It seems to me that to have one internetwork layer subsystem (e.g.,
   resource allocation) carry user state in all the packets (perhaps
   with use of a "hint" in the packets to find potentially cached copies
   in the router), and have a second (e.g., routing) use a direct
   installation, and use a tag in the packets to find it, makes little
   sense. We should do one or the other, based on a consideration of the
   efficiency/robustness tradeoff.

   Also, if there is a way of installing such flow-associated state, it
   makes sense to have only one, which all subsystems use, instead of
   building a separate one for each flow.

   It's a little difficult to make the choice between installation, and
   carrying a copy in each packet, without more information of exactly
   how much user state the network is likely to have in the future. (For
   instance, we might wind up with 500 byte headers if we include the
   full source route, resource reservation, etc., in every header.)

   It's also difficult without consideration of the actual mechanisms
   involved. As a general principle, we wish to make recovery from a
   loss of state as local as possible, to limit the number of entities
   which have to become involved. (For instance, when a router crashes,
   traffic is rerouted around it without needing to open a new TCP
   connection.) The option of the "installation" looks a lot more
   attractive if it's simple, and relatively cheap, to reinstall the
   user state when a router crashes, without otherwise causing a lot of
   hassle.






Chiappa                                                        [Page 16]

RFC 1753         Nimrod Technical Requirements for IPng    December 1994


   However, given the likely growth in user state, the necessity for
   service state, the requirement for reliable installation, and a
   number of similar considerations, it seems that direct installation
   of user state, and explicit recognition of flows, through a unified
   definition and tag mechanism in the packets, is the way to go, and
   this is the path that Nimrod has chosen.

3.3 Specific Interaction Issues

   Here is a very incomplete list of the things which Nimrod would like
   to see from the internetwork layer as a whole:

   - A unified definition of flows in the internetwork layer, and a
     unified way of identifying, through a separate flow-id field, which
     packets belong to a given flow.

   - A unified mechanism (potentially distributed) for installing state
     about flows (including multicast flows) in routers.

   - A method for getting information about whether a given resource
     allocation request has failed along a given path; this might be
     part of the unified flow setup mechanism.

   - An interface to (potentially distributed) mechanism for maintaining
     the membership in a multi-cast group.

   - Support for multiple interfaces; i.e., multi-homing. Nimrod does
     this by decoupling transport identification (done via EID's) from
     interface identification (done via locators). E.g., a packet with
     any valid destination locator should be accepted by the TCP of an
     endpoint, if the destination EID is the one assigned to that
     endpoint.

   - Support for multiple locators ("addresses") per network interface.
     This is needed for a number of reasons, among them to allow for
     less painful transitions in the locator abstraction hierarchy as
     the topology changes.

   - Support for multiple UID's ("addresses") per endpoint (roughly, per
     host). This would definitely include both multiple multicast SID's,
     and at least one unicast EID (the need for multiple unicast EID's
     per endpoint is not obvious).

   - Support for distinction between a multicast group as a named
     entity, and a multicast flow which may not reach all the members.

   - A distributed, replicated, user name translation system (DNS?) that
     maps such user names into (EID, locator0, ... locatorN) bindings.



Chiappa                                                        [Page 17]

RFC 1753         Nimrod Technical Requirements for IPng    December 1994


Security Considerations

   Security issues are discussed in section 2.2.

Author's Address

   J. Noel Chiappa

   Phone: [phone]
   EMail: [e-mail]









































Chiappa                                                        [Page 18]