rfc1753.txt

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

        current one on the top. When you aggregate, you push a new one
        on; when you de-aggregate, you take one off. This takes more
        work, but less space in the packet than the complete "source-
        route". Encapsulating packets to do aggregation does basically
        this, but you're stacking entire headers, not just flow-ids. The
        clever way to do this flow-id stacking, without doing
        encapsulation, is to find out from flow-setup how deep the stack
        will get, and allocate the space in the packet when it's
        created. That way, all you ever have to do is insert a new
        flow-id, or "remove" one; you never have to make room for more
        flow-ids.

      - Option 3: The packet contains only the "base" flow-id (i.e., the
        one with the finest granularity), and the current flow-id. When
        you aggregate, you just bash the current flow-id. The tricky
        part comes when you de-aggregate; you have to put the right
        value back. To do this, you have to have state in the router at
        the end of the aggregated flow, which tells you what the de-
        aggregated flow for each base flow is. The downside here is
        obvious: we get away without individual flow state for each of
        the constituent flows in all the routers along the path of that
        aggregated, flow, *except* for the last one.






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


        Other than encapsulation, which has significant inefficiency in
        space overhead fairly quickly, after just a few layers of
        aggregation, there appears to be no way to do it with just one
        flow-id in the packet header.  Even if you don't touch the
        packets, but do the aggregation by mapping some number of "base"
        flow-id's to a single aggregated flow in the routers along the
        path of the aggregated flow, the table that does the mapping is
        still going to have to have a number of entries directly
        proportional to the number of base flows going through the
        switch.

   - A looping packet detector. This is any mechanism that will detect a
     packet which is "stuck" in the network; a timeout value in packets,
     together with a check in routers, is an example. If this is a hop-
     count, it has to be more than 8 bits; 12 bits would be adequate,
     and I recommend 16 (which also makes it easy to update). This is
     not to say that I think networks with diameters larger than 256 are
     good, or that we should design such nets, but I think limiting the
     maximum path through the network to 256 hops is likely to bite us
     down the road the same way making "infinity" 16 in RIP did (as it
     did, eventually). When we hit that ceiling, it's going to hurt, and
     there won't be an easy fix. I will note in passing that we are
     already seeing paths lengths of over 30 hops.

   - Optional source and destination locators. These are structured,
     variable length items which are topologically sensitive identifiers
     for the place in the network from which the traffic originates or
     to which the traffic is destined. The locator will probably contain
     internal separators which divide up the fields, so that a
     particular field can be enlarged without creating a great deal of
     upheaval. An adequate value for maximum length supported would be
     up to 32 bytes per locator, and longer would be even better; I
     would recommend up to 256 bytes per locator.

   - Perhaps (paired with the above), an optional pointer into the
     locators.  This is optional "forwarding state" (i.e., state in the
     packet which records something about its progress across the
     network) which is used in the datagram forwarding mode to help
     ensure that the packet does not loop. It can also improve the
     forwarding processing efficiency. It is thus not absolutely
     essential, but is very desirable from a real-world engineering view
     point. It needs to be large enough to identify locations in either
     locator; e.g., if locators can be up to 256 bytes, it would need to
     be 9 bits.

   - An optional source route. This is used to support the "source
     routed packet" forwarding mode. Although not designed in detail
     yet, we can discuss two possible approaches.



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


     In one, used with "semi-strict" source routing (in which a
     contiguous series of entities is named, albeit perhaps at a high
     layer of abstraction), the syntax will likely look much like source
     routes in PIP; in Nimrod they will be a sequence of Nimrod entity
     identifiers (i.e., locator elements, not complete locators), along
     with clues as to the context in which each identifier is to be
     interpreted (e.g., up, down, across, etc.). Since those identifiers
     themselves are variable length (although probably most will be two
     bytes or less, otherwise the routing overhead inside the named
     object would be excessive), and the hop count above contemplates
     the possibility of paths of over 256 hops, it would seem that these
     might possibly some day exceed 512 bytes, if a lengthy path was
     specified in terms of the actual physical assets used. An adequate
     length would be 512 bytes; the recommended length would be 2^16
     bytes (although this length would probably not be supported in
     practise; rather, the field length would allow it).

     In the other, used with classical "loose" source routes, the source
     consists of a number of locators. It is not yet clear if this mode
     will be supported. If so, the header would need to be able to store
     a sequence of locators (as described above). Space might be saved
     by not repeating locator prefixes that match that of the previous
     locator in the sequence; Nimrod will probably allow use of such
     "locally useful" locators. It is hard to determine what an adequate
     length would be for this case; the recommended length would be 2^16
     bytes (again, with the previous caveat).

   - Perhaps (paired with the above), an optional pointer into the
     source route. This is also optional "forwarding state". It needs to
     be large enough to identify locations anywhere in the source route;
     e.g., if the source router can be up to 1024 bytes, it would need
     to be 10 bits.

   - An internetwork header length. I mention this since the above
     fields could easily exceed 256 bytes, if they are to all be carried
     in the internetwork header (see comments below as to where to carry
     all this information), the header length field needs to be more
     than 8 bits; 12 bits would be adequate, and I recommend 16 bits.
     The approach of putting some of the data items above into an
     interior header, to limit the size of the basic internetworking
     header, does not really seem optimal, as this data is for use by
     the intermediate routers, and it needs to be easily accessible.

   - Authentication of some sort is needed. See the recent IAB document
     which was produced as a result of the IAB architecture retreat on
     security (draft-iab-sec-arch-workshop-00.txt), section 4, and
     especially section 4.3. There is currently no set way of doing
     "denial/theft of service" in Nimrod, but this topic is well



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


     explored in that document; Nimrod would use whatever mechanism(s)
     seem appropriate to those knowledgeable in this area.

   - A version number. Future forwarding mechanisms might need other
     information (i.e., fields) in the packet header; use a version
     number would allow it to be modified to contain what's needed.
     (This would not necessarily be information that is visible to the
     hosts, so this does not necessarily mean that the hosts would need
     to know about this new format.) 4 bits is adequate; it's not clear
     if a larger value needs to be recommended.

2.3 Field Requirements and Addition Methods

   As noted above, it's possible to use Nimrod in a limited mode where
   needed information/fields are added by the first-hop router. It's
   thus useful to ask "which of the fields must be present in the host-
   router header, and which could be added by the router?" The only ones
   which are absolutely necessary in all packets are the endpoint
   identification (provided that some means is available to map them
   into locators; this would obviously be most useful on UID's which are
   EID's).

   As to the others, if the user wishes to use flows, and wants to
   guarantee that their packets are assigned to the correct flows, the
   flow-id field is needed. If the user wishes efficient use of the
   datagram mode, it's probably necessary to include the locators in the
   packet sent to the router.  If the user wishes to specify the route
   for the packets, and does not wish to set up a flow, they need to
   include the source route.

   How would additional information/fields be added to the packet, if
   the packet is emitted from the host in incomplete form? (By this, I
   mean the simple question of how, mechanically, not the more complex
   issue of where any needed information comes from.)

   This question is complex, since all the IPng candidates (and in fact,
   any reasonable inter-networking protocol) are extensible protocols;
   those extension mechanisms could be used. Also, it would possible to
   carry some of the required information as user data in the
   internetworking packet, with the original user's data encapsulated
   further inside. Finally, a private inter-router packet format could
   be defined.

   It's not clear which path is best, but we can talk about which fields
   the Nimrod routers need access to, and how often; less used ones
   could be placed in harder-to-get-to locations (such as in an
   encapsulated header). The fields to which the routers need access on
   every hop are the flow-id and the looping packet detector. The



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


   locator/pointer fields are only needed at intervals (in what datagram
   forwarding mode calls "active" routers), as is the source route (the
   latter at every object which is named in the source route).

   Depending on how access control is done, and which forwarding mode is
   used, the UID's and/or locators might be examined for access control
   purposes, wherever that function is performed.

   This is not a complete exploration of the topic, but should give a
   rough idea of what's going on.

3. Architectural Issues

3.1 Interaction Architectural Issues

   The topic of the interaction with the rest of the internetwork layer
   is more complex. Nimrod springs in part from a design vision which
   sees the entire internetwork layer, distributed across all the hosts
   and routers of the internetwork, as a single system, albeit a
   distributed system.

   Approached from that angle, one naturally falls into a typical system
   designer point of view, where you start to think of the
   modularization of the system; chosing the functional boundaries which
   divide the system up into functional units, and defining the
   interactions between the functional units.  As we all know, that
   modularization is the key part of the system design process.

   It's rare that a group of completely independent modules form a
   system; there's usually a fairly strong internal interaction. Those
   interactions have to be thought about and understood as part of the
   modularization process, since it effects the placement of the
   functional boundaries. Poor placement leads to complex interactions,
   or desired interactions which cannot be realized.

   These are all more important issues with a system which is expected
   to have a long lifetime; correct placement of the functional
   boundaries, so as to clearly and simply break up the system into
   truly fundamental units, is a necessity is the system is to endure
   and serve well.

3.1.1 The Internetwork Layer Service Model

   To return to the view of the internetwork layer as a system, that
   system provides certain services to its clients; i.e., it
   instantiates a service model. To begin with, lacking a shared view of
   the service model that the internetwork layer is supposed to provide,
   it's reasonable to suppose that it will prove impossible to agree on



Chiappa                                                         [Page 9]