rfc1753.txt

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


RFC 1753         Nimrod Technical Requirements for IPng    December 1994


   mechanisms at the internetwork level to provide that service.

   To answer the question of what the service model ought to be, one can
   view the internetwork layer itself as a subsystem of an even large
   system, the entire internetwork itself. (That system is quite likely
   the largest and most complex system we will ever build, as it is the
   largest system we can possibly build; it is the system which will
   inevitably contain almost all other systems.)

   From that point of view, the issue of the service model of the
   internetwork layer becomes a little clearer. The services provided by
   the internetwork layer are no longer purely abstract, but can be
   thought about as the external module interface of the internetwork
   layer module. If agreement can be reached on where to put the
   functional boundaries of the internetwork layer, and on what overall
   service the internet as a whole should provide, the service model of
   the internetwork layer should be easier to agree on.

   In general terms, it seems that the unreliable packet ought to remain
   the fundamental building block of the internetwork layer. The design
   principle that says that we can take any packet and throw it away
   with no warning or other action, or take any router and turn it off
   with no warning, and have the system still work, seems very powerful.
   The component design simplicity (since routers don't have to stand on
   their heads to retain a packet which they have the only copy of), and
   overall system robustness, resulting from these two assumptions is
   absolutely critical.

   In detail, however, particularly in areas which are still the subject
   of research and experimentation (such as resource allocation,
   security, etc.), it seems difficult to provide a finished definition
   of exactly what the service model of the internetwork layer ought to
   be.

3.1.2 The Subsystems of the Internetwork Layer

   In any event, by viewing the internetwork layer as a large system,
   one starts to think about what subsystems are needed, and what the
   interactions among them should look like. Nimrod is simply a number
   of the subsystems of this larger system, the internetwork layer. It
   is *not* intended to be a purely standalone set of subsystems, but to
   work together in close concert with the other subsystems of the
   internetwork layer (resource allocation, security, charging, etc.) to
   provide the internetwork layer service model.

   One reason that Nimrod is not simply a monolithic subsystem is that
   some of the interactions with the other subsystems of the
   internetwork layer, for instance the resource allocation subsystem,



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


   are much clearer and easier to manage if the routing is broken up
   into several subsystems, with the interactions between them open.

   It is important to realize that Nimrod was initially broken up into
   separate subsystems for purely internal reasons. It so happens that,
   considered as a separate problem, the fundamental boundary lines for
   dividing routing up into subsystems are the same boundaries that make
   interaction with other subsystems cleaner; this provides added
   evidence that these boundaries are in fact the right ones.

   The subsystems which comprise the functionality covered by Nimrod are
   i) routing information distribution (in the case of Nimrod, topology
   map distribution, along with the attributes [policy, QOS, etc.] of
   the topology elements), ii) route selection (strictly speaking, not
   part of the Nimrod spec per se, but functional examples will be
   produced), and iii) user traffic handling.

   The former can fairly well be defined without reference to other
   subsystems, but the second and third are necessarily more involved.
   For instance, route selection might involve finding out which links
   have the resources available to handle some required level of
   service. For user traffic handling, if a particular application needs
   a resource reservation, getting that resource reservation to the
   routers is as much a part of getting the routers ready as making sure
   they have the correct routing information, so here too, routing is
   tied in with other subsystems.

   In any event, although we can talk about the relationship between the
   Nimrod subsystems, and the other functional subsystems of the
   internetwork layer, until the service model of the internetwork layer
   is more clearly visible, along with the functional boundaries within
   that layer, such a discussion is necessarily rather nebulous.

3.2 State and Flows in the Internetwork Layer

   The internetwork layer as whole contains a variety of information, of
   varying lifetimes. This information we can refer to as the
   internetwork layer's "state". Some of this state is stored in the
   routers, and some is stored in the packets.

   In the packet, I distinguish between what I call "forwarding state",
   which records something about the progress of this individual packet
   through the network (such as the hop count, or the pointer into a
   source route), and other state, which is information about what
   service the user wants from the network (such as the destination of
   the packet), etc.





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


3.2.1 User and Service State

   I call state which reflects the desires and service requests of the
   user "user state". This is information which could be sent in each
   packet, or which can be stored in the router and applied to multiple
   packets (depending on which makes the most engineering sense). It is
   still called user state, even when a copy is stored in the routers.

   User state can be divided into two classes; "critical" (such as
   destination addresses), without which the packets cannot be forwarded
   at all, and "non-critical" (such as a resource allocation class),
   without which the packets can still be forwarded, just not quite in
   the way the user would most prefer.

   There are a range of possible mechanisms for getting this user state
   to the routers; it may be put in every packet, or placed there by a
   setup. In the latter case, you have a whole range of possibilities
   for how to get it back when you lose it, such as placing a copy in
   every Nth packet.

   However, other state is needed which cannot be stored in each packet;
   it's state about the longer-term (i.e., across the life of many
   packets) situation; i.e., state which is inherently associated with a
   number of packets over some time-frame (e.g., a resource allocation).
   I call this state "server state".

   This apparently changes the "stateless" model of routers somewhat,
   but this change is more apparent than real. The routers already
   contain state, such as routing table entries; state without which is
   it virtually impossible to handle user traffic. All that is being
   changed is the amount, granularity, and lifetime, of state in the
   routers.

   Some of this service state may need to be installed in a fairly
   reliable fashion; e.g., if there is service state related to billing,
   or allocation of resources for a critical application, one more or
   less needs to be guaranteed that this service state has been
   correctly installed.

   To the extent that you have state in the routers (either service
   state, or user state), you have to be able to associate that state
   with the packets it goes with. The fields in the packets that allow
   you to do this are "tags".








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


3.2.2 Flows

   It is useful to step back for a bit here, and think about the traffic
   in the network. Some of it will be from applications with are
   basically transactions; i.e., they require only a single packet, or a
   very small number.  (I tend to use the term "datagram" to refer to
   such applications, and use the term "packet" to describe the unit of
   transmission through the network.) However, other packets are part of
   longer-lived communications, which have been termed "flows".

   A flow, from the user's point of view, is a sequence of packets which
   are associated, usually by being from a single application instance.
   In an internetwork layer which has a more complex service model
   (e.g., supports resource allocation, etc.), the flow would have
   service requirements to pass on to some or all of the subsystems
   which provide those services.

   To the internetworking layer, a flow is a sequence of packets that
   share all the attributes that the internetworking layer cares about.
   This includes, but is not limited to: source/destination, path,
   resource allocation, accounting/authorization,
   authentication/security, etc., etc.

   There isn't necessarily a one-one mapping from flows to *anything*
   else, be it a TCP connection, or an application instance, or
   whatever. A single flow might contain several TCP connections (e.g.,
   with FTP, where you have the control connection, and a number of data
   connections), or a single application might have several flows (e.g.,
   multi-media conferencing, where you'd have one flow for the audio,
   another for a graphic window, etc., with different resource
   requirements in terms of bandwidth, delay, etc., for each.)

   Flows may also be multicast constructs, i.e., multiple sources and
   destinations; they are not inherently unicast. Multicast flows are
   more complex than unicast (there is a large pool of state which must
   be made coherent), but the concepts are similar.

   There's an interesting architectural issue here. Let's assume we have
   all these different internetwork level subsystems (routing, resource
   allocation, security/access-control, accounting), etc. Now, we have
   two choices.

   First, we could allow each individual subsystem which uses the
   concept of flows to define itself what it thinks a "flow" is, and
   define which values in which fields in the packet define a given
   "flow" for it. Now, presumably, we have to allow 2 flows for
   subsystem X to map onto 1 flow for subsystem Y to map onto 3 flows
   for subsystem Z; i.e., you can mix and match to your heart's content.



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


   Second, we could define a standard "flow" mechanism for the
   internetwork layer, along with a way of identifying the flow in the
   packet, etc. Then, if you have two things which wish to differ in
   *any* subsystem, you have to have a separate flow for each.

   The former has the advantages that it's a little easier to deploy
   incrementally, since you don't have to agree on a common flow
   mechanism. It may save on replicated state (if I have 3 flows, and
   they are the same for subsystem X, and different for Y, I only need
   one set of X state). It also has a lot more flexibility. The latter
   is simple and straightforward, and given the complexity of what is
   being proposed, it seems that any place we can make things simpler,
   we should.

   The choice is not trivial; it all depends on things like "what
   percentage of flows will want to share the same state in certain
   subsystems with other flows". I don't know how to quantify those, but
   as an architect, I prefer simple, straightforward things. This system
   is pretty complex already, and I'm not sure the benefits of being
   able to mix and match are worth the added complexity. So, for the
   moment I'll assume a single, system-wide, definition of flows.

   The packets which belong to a flow could be identified by a tag
   consisting of a number of fields (such as addresses, ports, etc.), as
   opposed to a specialized field. However, it may be more