rfc1992.txt

中、英文RFC文档大全打包下载完全版 .

     |  |        |       |        |                    |        |  |
     |  | a:y:h1 --------|  c:h1  |--------------------| b:d:h1 |  |
     |  |        |       |        |                    |        |  |
     |  +--------+       +--------+                    +--------+  |
     |    |    |           |    |                        |    |    |
   +--------+  |           |  +------+  +------+         |  +--------+
   |        |  |           |  |      |  |      |         |  |        |
   | a:y:r1 |  |           |  | c:r1 |--| c:h3 |         |  | b:d:r1 |
   |        |  |           |  |      |  |      |         |  |        |
   +--------+  |           |  +------+  +------+         |  +--------+
     |    |    |           |    |                        |    |    |
     |  +--------+       +--------+                    +--------+  |
     |  |        |       |        |                    |        |  |
     |  | a:y:h2 |--------  c:h2  |--------------------| b:d:h2 |  |
     |  |        |       |        |                    |        |  |
     |  +--------+       +--------+                    +--------+  |
     |         |                                         |         |
     |         |                                         |         |
     |         |                                         |         |
     |         \-----------------------------------------/         |
     \-------------------------------------------------------------/



                          Figure 6:  Nimrod Map II


 2. Connectivity Specifications Sequence (CSS) mode: In this mode,
    packets carry a list of connectivity specifications.  The packet
    is supposed to go sequentially through the nodes that own each one
    of the listed connectivity specifications in the order they were
    specified.  The nodes need not be adjacent.  This mode can be seen
    as a generalization of the CSC mode.  Notice that CSCs are said to
    be a *chains* of locators, CSSs are *sequences* of locators.  This
    difference emphasizes the contiguity requirement in CSCs.  A
    detailed description of this mode is in section 5.6.




Castineyra, et. al.          Informational                     [Page 21]

RFC 1992              Nimrod Routing Architecture            August 1996


 3. Flow mode: In this mode, the packet includes a path-id that
    indexes state that has been previously set up in routers along the
    path.  Packet forwarding when flow state has been established is
    relatively simple: follow the instructions in the routers' state.
    Nimrod includes a mechanism for setting up this state.  A more
    detailed description of this mode can be found in section 5.4.

 4. Datagram mode: in this mode, every packet carries source and
    destination locators.  This mode can be seen as a special case of
    the CSS mode.  Forwarding is done following procedures as
    indicated in section 5.5.

    BEGIN COMMENT

    The obvious parallels are between CSC mode and IPV4's strict
    source route and between CSS mode and IPV4's loose source route.

    END COMMENT

   In all of these modes, the packet may also carry locators and EIDs
   for the source and destinations.  In normal operation, forwarding
   does not take the EIDs into account, only the receiver does.  EIDs
   may be carried for demultiplexing at the receiver, and to detect
   certain error conditions.  For example, if the EID is unknown at the
   receiver, the locator and EID of the source included in the packet
   could be used to generate an error message to return to the source
   (as usual, this error message itself should probably not be allowed
   to be the cause of other error messages).  Forwarding can also use
   the source locator and EID to respond to error conditions, for
   example, to indicate to the source that the state for a path-id
   cannot be found.

   Packets can be visualized as moving between nodes in a map.  A packet
   indicates, implicitly or explicitly, a destination locator.  In a
   packet that uses the datagram, CSC, or CSS forwarding mode, the
   destination locator is explicitly indicated .  In a packet that uses
   the flow forwarding mode, the destination locator is implied by the
   path-id and the distributed state in the network (it might also be
   included explicitly).  Given a map, a packet moves to the node in
   this map to which the associated destination locator belongs.  If the
   destination node has a "detailed" internal map, the destination
   locator must belong to one of the nodes in this internal map
   (otherwise it is an error).  The packet goes to this node (and so on,
   recursively).







Castineyra, et. al.          Informational                     [Page 22]

RFC 1992              Nimrod Routing Architecture            August 1996


5.1 Policy

   CSC and CSS mode implement policy by specifying the connectivity
   specifications associated with those nodes that the packet should
   traverse.  Strictly speaking, there is no policy information included
   in the packet.  That is, in principle, it is not possible to
   determine what criteria were used to select the route by looking at
   the packet.  The packet only contains the results of the route
   generation process.  Similarly, in a flow mode packet, policy is
   implicit in the chosen route.

   A datagram-mode packet can indicate a limited form of policy routing
   by the choice of destination and source locators.  For this choice to
   exist, the source or destination endpoints must have several locators
   associated with them.  This type of policy routing is capable of, for
   example, choosing providers.

5.2 Trust

   A node that chooses not to divulge its internal map can work
   internally any way its administrators decide, as long as the node
   satisfies its external characterization as given in its Nimrod map
   advertisements.  Therefore, the advertised Nimrod map should be
   consistent with a node's actual capabilities.  For example, consider
   the network shown in figure 7 which shows a physical network and the
   advertised Nimrod map.  The physical network consists of hosts and a
   router connected together by an ethernet.  This node can be sub-
   divided into component nodes by assigning locators as shown in the
   figure and advertising the map shown.  The map seems to imply that it
   is possible to send packets to node a:x without these being
   observable by node a:y; however, this is actually not enforceable.

   In general, it is reasonable to ask how much trust should be put in
   the maps obtained by a router.  Even when a node is "trustworthy,"
   and the information received from the node has been authenticated,
   there is always the possibility of an honest mistake.















Castineyra, et. al.          Informational                     [Page 23]

RFC 1992              Nimrod Routing Architecture            August 1996


                                 +--+
                                 |RA| a:r1
                                 +--+
                                  |
                                  |
                                  |
                                  |
                     -------------------------------
                         |                       |
                        +--+                    +--+
                        |Ha| a:x:h1             |Ha| a:y:h2
                        +--+                    +--+


                               Physical Network


                      a             |
                   +----------------|--------------------
                   |                |                   |
                   |              +----+                |
                   |              |a:r1|                |
                   |   a:x        +----+  a:y           |
                   |   +------+  /      \ +-------+     |
                   |   |      | /        \|       |     |
                   |   |      |           |       |     |
                   |   |      |           |       |     |
                   |   +------+           +-------+     |
                   |                                    |
                   + -----------------------------------+


                               Advertised Nimrod Map




                    Figure 7:  Example of Misleading Map

5.3 Connectivity Specification (CSC) Mode

   Routing for a CSC packet is specified by a list of connectivity
   specifications carried in the packet.  These are the connectivity
   specifications that make the specified path, in the order that they
   appear along the path.  These connectivity specifications are
   attributes of nodes.  The route indicated by a CSC packet is specifed
   in terms of connectivity specifications rather than physical
   entities:  a connectivity specification in a CSC-mode packet would



Castineyra, et. al.          Informational                     [Page 24]

RFC 1992              Nimrod Routing Architecture            August 1996


   correspond to a type of service between two points of the network
   without specifying the physical path.

   Given two connectivity specifications that appear consecutively in
   the a CSC-mode packet, there should exist an adjacency going from the
   node corresponding to the first connectivity specification to the
   node corresponding to the second connectivity specification.  The
   first connectivity specification referenced in a CSC-mode packet
   should be an outbound connectivity specification; similarly, the last
   connectivity specification referenced in a CSC-mode packet should be
   an inbound connectivity specification; the rest should be transit
   connectivity specifications.

5.4 Flow Mode

   A flow mode packet includes a path-id field.  This field identifies
   state that has been established in intermediate routers.  The packet
   might also contain locators and EIDs for the source and destination.
   The setup packet also includes resource requirements.  Nimrod
   includes protocols to set up and modify flow-related state in
   intermediate routers.  These protocols not only identify the
   requested route, but also describe the resources requested by the
   flow---e.g., bandwidth, delay, etc.  The result of a set-up attempt
   might be either confirmation of the set-up or notification of its
   failure.  The source-specified routes in flow mode setup are
   specified in terms of CSSs.

5.5 Datagram Mode

   A realistic routing architecture must include an optimization for
   datagram traffic, by which we mean user transactions which consist of
   single packets, such as a lookup in a remote translation database.
   Either of the two previous modes contains unacceptable overhead if
   much of the network traffic consists of such datagram transactions.
   A mechanism is needed which is approximately as efficient as the
   existing IPv4 "hop-by-hop" mechanism.  Nimrod has such a mechanism.

   The scheme can be characterized by the way it divides the state in a
   datagram network between routers and the actual packets.  In IPv4,
   most packets currently contain only a small amount of state
   associated with the forwarding process ("forwarding state")---the hop
   count.  Nimrod proposes that enlarging the amount of forwarding state
   in packets can produce a system with useful properties.  It was
   partially inspired by the efficient source routing mechanism in SIP
   [5], and the locator pointer mechanism in PIP [6]).

   Nimrod datagram mode uses pre-set flow-mode state to support a
   strictly non-looping path, but without a source-route.



Castineyra, et. al.          Informational                     [Page 25]

RFC 1992              Nimrod Routing Architecture            August 1996


5.6 Connectivity Specification Sequence Mode

   The connectivity specification sequence mode specifies a route by a
   list of connectivity specifications.  There are no contiguity
   restrictions on consecutive connectivity specifications.

    BEGIN COMMENT

    The CSS and CSC modes can be seen as combination of the datagram
    and flow modes.  Therefore, in a sense, the basic forwarding modes
    of Nimrod are just these last two.

    END COMMENT

6. Security Considerations

   Security issues are not addressed in this document.

7. References

   [1] Steenstrup, M., "Inter-Domain Policy Routing Protocol
       Specification: Version 1," RFC 1479, June 1993.

   [2] Steenstrup M., and R. Ramanathan, "Nimrod Functionality and
       Protocols Specification," Work in Progress, February 1996.

   [3] Wright, R., "Three Scientists and their Gods Looking for Meaning
       in an Age of Information", New York: Times Book, first ed., 1988.

   [4] Deering, S., "SIP: Simple Internet Protocol," IEEE Network, vol.
       7, May 1993.

   [5] Francis, P., "A Near-Term Architecture for Deploying Pip," IEEE
       Network, vol. 7, May 1993.

















Castineyra, et. al.          Informational                     [Page 26]

RFC 1992              Nimrod Routing Architecture            August 1996


8. Authors' Addresses

   Isidro Castineyra
   BBN Systems and Technologies
   10 Moulton Street
   Cambridge, MA 02138

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


   Noel Chiappa
   EMail:  [e-mail]

   Martha Steenstrup
   BBN Systems and Technologies
   10 Moulton Street
   Cambridge, MA 02138

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






























Castineyra, et. al.          Informational                     [Page 27]