RFC1668 Unified Routing Requirements for IPng

1668 Unified Routing Requirements for IPng. D. Estrin, T. Li, Y.Rekhter. August 1994. (Format: TXT=5106 bytes) (Status: INFORMATIONAL)

日本語訳
RFC一覧

参照

Network Working Group                                          D. Estrin
Request for Comments: 1668                                           USC
Category: Informational                                            T. Li
                                                           Cisco Systems
                                                              Y. Rekhter
                                  T.J. Watson Research Center, IBM Corp.
                                                             August 1994


                 Unified Routing Requirements for IPng

Status of this Memo

   This memo provides information for the Internet community.  This memo
   does not specify an Internet standard of any kind.  Distribution of
   this memo is unlimited.

Abstract

   This document was submitted to the IETF IPng area in response to RFC
   1550.  Publication of this document does not imply acceptance by the
   IPng area of any ideas expressed within.  Comments should be
   submitted to the big-internet@munnari.oz.au mailing list.

1. IPng Requirements

   The following list provides requirements on the IPng from the
   perspective of the Unified Routing Architecture, as describe in RFC
   1322.

   1. To provide scalable routing, IPng addressing must provide support
      for topologically significant address assignment.

   2. Since it is hard to predict how routing information will be
      aggregated, the IPng addressing structure should impose as few
      preconditions as possible on the number of levels in the hierarchy.
      Specifically, the number of levels must be allowed to be different
      at different parts in the hierarchy. Further, the levels must not
      be statically tied to particular parts (fields) in the addressing
      information.

   3. Hop-by-hop forwarding algorithm requires IPng to carry enough
      information in the Network Layer header to unambiguously determine
      a particular next hop. Unless mechanisms to compute
      context-sensitive forwarding tables and provide consistent
      forwarding are defined, the requirement assumes the presence of
      full hierarchical addresses.  Therefore, IPng packet format must
      provide efficient determination of the full hierarchical



Estrin, Li & Rekhter                                            [Page 1]

RFC 1668         Unified Routing Requirements for IPng       August 1994


      destination address.

   4. Hierarchical address assignment should not imply strictly
      hierarchical routing. Therefore, IPng should carry enough
      information to provide forwarding along both hierarchical and
      non-hierarchical routes.

   5. The IPng packet header should accommodate a "routing label" or
      "route ID". This label will be used to identify a particular FIB
      to be used for packet forwarding by each router.

      Two types of routing labels should be supported: "strong" and
      "weak".

      When a packet carries a "strong" routing label and a router does
      not have a FIB with this label, the packet is discarded (and an
      error message is sent back to the source).

      When a packet carries a "weak" routing label and a router does not
      have a FIB with this label, the packet should be forwarded via a
      "default" FIB, i.e., according to the destination address. In
      addition, the packet should carry an indication that somewhere
      along the path the desired routing label was unavailable.

   6. IPng should provide a source routing mechanism with the following
      capabilities (i.e., flexibility):

       - Specification of either individual routers or collections of
         routers as the entities in the source route.

       - The option to indicate that two consecutive entities in a
         source route must share a common subnet in order for the
         source route to be valid.

       - Specification of the default behavior when the route to
         the next entry in the source route is unavailable:

       - The packet is discarded, or

       - The source route is ignored and the packet is forwarded based
         only on the destination address (and the packet header will
         indicate this action).

       - A mechanism to verify the feasibility of a source route.

Security Considerations

   Security issues are not discussed in this memo.



Estrin, Li & Rekhter                                            [Page 2]

RFC 1668         Unified Routing Requirements for IPng       August 1994


Authors' Addresses

   Deborah Estrin
   University of Southern California
   Computer Science Department, MC 0782
   Los Angeles, California 90089-0782

   Phone: (310) 740-4524
   EMail: estrin@usc.edu


   Tony Li
   cisco Systems, Inc.
   1525 O'Brien Drive
   Menlo Park, CA 94025

   EMail: tli@cisco.com


   Yakov Rekhter
   T.J. Watson Research Center IBM Corporation
   P.O. Box 218
   Yorktown Heights, NY 10598

   Phone:  (914) 945-3896
   EMail:  yakov@watson.ibm.com

























Estrin, Li & Rekhter                                            [Page 3]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

Date.setFullYear

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る