home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / sdr / sdr-minutes-94mar.txt < prev    next >
Text File  |  1994-06-04  |  5KB  |  153 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4.  
  5. Reported by Deborah Estrin/USC and Kannan Varadhan/USC
  6.  
  7. Minutes of the Source Demand Routing Working Group (SDR)
  8.  
  9. The SDR Working Group met in Seattle to discuss issues relevant to SDRP
  10. route construction.  The following minutes are an outline of some of the
  11. proposed techniques for route construction, and the various requirements
  12. for making them feasible.
  13.  
  14. Deborah Estrin gave a brief report on the current status of the SDRP 2.0
  15. packet forwarding code done at USC. This version is compliant with the
  16. latest draft of the packet forwarding specification.  Improvements from
  17. the previous version include:
  18.  
  19.  
  20.    o General re-organization of code
  21.  
  22.    o Allow SDRP to work with packets of arbitrary size due to long
  23.      source routes (much mbuf hacking)
  24.  
  25.    o Fragmentation
  26.  
  27.    o ICMP error messages for needing fragmentation, exceeding hop count
  28.  
  29.    o SDRP setup protocol
  30.  
  31.    o Use caching to speed forwarding/processing of SDRP packets
  32.  
  33.    o Avoiding using SDRP on packets with IP strict source route option
  34.  
  35.    o Send error messages along reverse of SDRP source route when IP
  36.      cannot send the error
  37.  
  38.    o sdrp_config version 2.0 rewritten to give friendlier interface for
  39.      installing filters and routes
  40.  
  41.  
  42. As part of the next step, we need to decide on route construction
  43. techniques for the short and medium term range.  In the short term
  44. range, it has been observed that SDRP could be used to do provider
  45. selection in the Internet today, by having the client domain initiate an
  46. IDRP connection with a preferred backbone provider to obtain the
  47. relevant FIB in a dynamic manner.
  48.  
  49. This requires changes to IDRP to overcome common subnetwork
  50. restrictions.  Mechanisms are also needed to install SDRP routes learned
  51. in this manner.  This latter technique will be required for all future
  52. uses of SDRP.
  53.  
  54. The next extension for use in SDRP is to be able to query for RIBs for
  55. selected destinations on demand.
  56.  
  57. This requires the following infrastructure:
  58.  
  59.  
  60.    o Modifications to IDRP to permit querying for RIBs.
  61.    o Protocols to do the RIB query.
  62.    o Code to do the RIB query.
  63.    o Heuristics on whom to query, as for example, a configured list of
  64.      preferred providers.
  65.  
  66.  
  67. Path Explorer is a mechanism to trigger the computation of new routes.
  68. One can use a brute force explorer, or some form of constrained explorer
  69. schemes.  Path Explorer was first proposed by Brijesh Kumar.
  70.  
  71. In the brute force scheme, the source requests the desired destination
  72. to initiate a path explore.  BRs between the source and destination
  73. propagate, but do not store, these routes.  In the process, they do
  74. impose their transit policy criteria, but do not impose their own local
  75. selection criteria.
  76.  
  77. The technique computes end-to-end routes, but is too expensive.
  78.  
  79. Routes are already constrained by their specified attributes.  Some
  80. other techniques for constraining route propagation are to use source
  81. specific preferences, hop counts, or hop counts with proxies.
  82.  
  83. To constrain route propagation, the source can specify a preference
  84. function.  Intermediate BRs will keep a short lived cache, which they
  85. use to compare with each viable route to decide whether or not to
  86. propagate.
  87.  
  88. Given that the number of updates grows exponentially with the length of
  89. the path, the source could specify a constraint hop count to limit the
  90. update flood.
  91.  
  92. The source could use a proxy intermediate node to initiate the explore
  93. to.  The problem with this technique is that it is hard to guess a good
  94. proxy intermediate node accurately.  To fix this, one could use multiple
  95. proxies.
  96.  
  97. The following is a summary of requirements for Path Explorer:
  98.  
  99.    o Protocols to initiate Path Explore and Proxy.
  100.  
  101.    o Specifications for the evaluation functions.
  102.  
  103.    o Requirements from IDRP to support propagation of routes without
  104.      storing them internally:
  105.  
  106.       -  Do not apply selection criteria
  107.       -  Do apply transit criteria
  108.       -  Do not store locally (in FIB or RIBs)
  109.  
  110.    o Requirements from IDRP to support using alternate evaluation
  111.      functions.
  112.  
  113.    o Implementations.
  114.  
  115.  
  116. Path Verifier is a source routed path explorer.  It is required because
  117. the actual forwarding behavior could be different from advertised
  118. behavior, because network topology, or policies change and the cached
  119. information is now stale.
  120.  
  121. We need a tool to verify the path after it has been computed and before
  122. it is used.
  123.  
  124. Sue Hares has volunteered to work on the IDRP document changes.  A few
  125. others have volunteered to port USC's SDRP packet forwarding code to
  126. other architectures.
  127.  
  128.  
  129. Attendees
  130.  
  131. William Barns            barns@gateway.mitre.org
  132. Steven Berson            berson@isi.edu
  133. Randy Bush               randy@psg.com
  134. Deborah Estrin           estrin@usc.edu
  135. William Gilliam          wag@cup.hp.com
  136. Susan Hares              skh@merit.edu
  137. Dimitry Haskin           dhaskin@wellfleet.com
  138. Christian Huitema        Christian.Huitema@sophia.inria.fr
  139. John Krawczyk            jkrawczy@wellfleet.com
  140. Tony Li                  tli@cisco.com
  141. Cheryl Madson            cmadson@wellfleet.com
  142. J. Scott Marcus          smarcus@bbn.com
  143. Daniel McDonald          danmcd@itd.nrl.navy.mil
  144. Keith Mitchell           keith@pipex.net
  145. Robert Moose             rmoose@gateway.mitre.org
  146. Sandra Murphy            murphy@tis.com
  147. Peder Chr.  Noergaard    pcn@tbit.dk
  148. Erik Nordmark            nordmark@eng.sun.com
  149. Ram Ramanathan           ramanath@bbn.com
  150. Kwang Yao                kwang@cup.hp.com
  151. Jessica Yu               jyy@merit.edu
  152.  
  153.