home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / sdr / sdr-charter.txt < prev    next >
Text File  |  1997-10-08  |  7KB  |  150 lines
  1.  
  2. Source Demand Routing (sdr)
  3. ---------------------------
  4.  
  5.  Charter 
  6.  Last Modified: 19-Feb-97
  7.  
  8.  Current Status: Active Working Group
  9.  
  10.  Chair(s):
  11.      Deborah Estrin <estrin@usc.edu>
  12.  
  13.  Routing Area Director(s): 
  14.      Joel Halpern  <jhalpern@newbridge.com>
  15.  
  16.  Routing Area Advisor: 
  17.      Joel Halpern  <jhalpern@newbridge.com>
  18.  
  19.  Mailing Lists: 
  20.      General Discussion:sdrp@catarina.usc.edu
  21.      To Subscribe:      sdrp-request@catarina.usc.edu
  22.      Archive:           ftp://catarina.usc.edu/pub/sdrp
  23.  
  24. Description of Working Group:
  25.  
  26. The SDR Working Group is chartered to specify and promote the use of SDRP
  27. (Source Demand Routing Protocol) as an inter-domain routing protocol
  28. capability in conjunction with IDRP and BGP inter-domain routing
  29. protocols.  The purpose of SDR is to support explicit selection of inter-
  30. domain routes, to complement the implicit hop-hy-hop route selection
  31. provided by BGP/IDRP.  The group is also chartered to specify and promote
  32. the use of a similar protocol for IPv6, referred to as the Explicit
  33. Routing Protocol (ERP).
  34.  
  35. The goal of the SDR Working Group is to release the components of SDR as
  36. ``experimental'' IETF protocols and to obtain operational experience with
  37. SDR in the Internet.  Once there is enough experience with SDR, the
  38. working group will submit the SDR components to the IESG for
  39. standardization.
  40.  
  41. SDR has four components: packet formats for protocol control messages
  42. and encapsulation of user datagrams, processing and forwarding of user
  43. data and control messages, routing information distribution/collection
  44. and route computation, configuration and usage.
  45.  
  46.  
  47. The group's strategy is to:
  48.  
  49. (1) Define the format, processing and forwarding of user datagram and
  50. control messages so that SDR can be used very early on as an efficient
  51. means of supporting ``configured'' inter-domain routes.  User packets
  52. are encapsulated along with the source route and forwarded along the
  53. ``configured'' route.  Routes are static at the inter-domain level, but
  54. are not static in terms of the intra-domain paths that packets will
  55. take between specified points in the SDR route. The impact of
  56. encapsulation on MTU, ICMP, performance, etc., are among the issues that
  57. must be evaluated before deployment.
  58.  
  59. (2) Develop simple schemes for collecting (a) dynamic domain-level
  60. connectivity information and (b) route construction based on this
  61. information, so that those domains that want to can make use of a
  62. richer, and dynamic set of SDR routes.
  63.  
  64. (3) Apply the experience with SDR design and implementation to the
  65. design and implementation of ERP.
  66.  
  67. (4) Develop SDR and ERP deployment plans.
  68.  
  69. (5) In parallel with (1), (2) and (3) , develop usage and configuration
  70. documents and prototypes that demonstrate the utility of static-SDR and
  71. simple-dynamic-SDR and ERP.
  72.  
  73. (6) After gaining some experience with the simple schemes for
  74. distribution, develop a second generation of information distribution
  75. and route construction schemes.  The group hopes to benefit from
  76. discussions with IDPR and NIMROD developers at this future stage because
  77. the issues faced are similar.  The route distribution and construction
  78. mechanisms are common to both ERP and SDRP.
  79.  
  80. (7) Investigate the use of SDRP and ERP alternate routing as a mechanism
  81. for supporting reservation traffic (e.g., based on RSVP).  This will
  82. require that we address integration of SDRP/ERP and multicast routing
  83. (e.g., running PIM over SDRP/ERP), as well as the interface between
  84. SDRP/ERP and RSVP.  Moreover, we will investigate the construction of
  85. SDRP/ERP routes that make use of some dynamic control information, in
  86. additional to the more traditional hop count.
  87.  
  88. (8) The group will also investigate the addition of security options
  89. into the SDRP/ERP forwarding and packet format specifications.
  90.  
  91. (9) Coordinate with the IDR and IPng Working Groups.
  92.  
  93.  Goals and Milestones: 
  94.  
  95.      Done       Post an Internet-Draft of packet forwarding and control message
  96.                 format and protocol for IP.                                    
  97.  
  98.      Done       Post, as an Internet-Draft, a ``white paper'' on route 
  99.                 construction approaches and mechanisms for SDRP/ERP.           
  100.  
  101.      Done       Submit as an Internet-Draft a specification for Route Setup.   
  102.  
  103.      Done       Submit the packet forwarding and control message format 
  104.                 Internet-Draft for publication as an RFC.                      
  105.  
  106.    Dec 94       Post as an Internet-Draft the SDR usage and configuration 
  107.                 document. This is the highest priority after the draft 
  108.                 specification in order to demonstrate how even static-SDR can 
  109.                 be used to achieve concrete objectives.                        
  110.  
  111.    Dec 94       Post as an Internet-Draft the BGP/IDRP extensions 
  112.                 specification. As mentioned in the Internet-Draft there are a 
  113.                 few extensions to BGP/IDRP needed to support SDR. These must be
  114.                 detailed and documented.                                       
  115.  
  116.    Jan 95       Post as an Internet-Draft a specification for SDR multicast. 
  117.                 This is to be coordinated with IDMR's PIM.                     
  118.  
  119.    Jan 95       Submit a ``white paper'' as an Internet-Draft on routing 
  120.                 support for reservation-based traffic and SRRP's role.  This is
  121.                 to be coordinated with RSVP.                                   
  122.  
  123.    Mar 95       Post as an Internet-Draft the SDR MIB.  Three parts: packet 
  124.                 forwarding and control messages MIB, the route distribution and
  125.                 computation MIB (including policy information).                
  126.  
  127.    Mar 95       Post revised Internet-Draft on route construction approaches 
  128.                 and mechanisms for SDRP/ERP.                                   
  129.  
  130.    Jul 95       Submit the ERP specifiations to the IESG for consideration as 
  131.                 an Experimental protocol.                                      
  132.  
  133.    Oct 95       Post as an Internet-Draft the ERP MIB.  Only the forwarding and
  134.                 control messages are different than the SDR MIB.               
  135.  
  136.    Dec 95       Submit the ERP specifications to the IESG for consideration as 
  137.                 a Proposed Standard.                                           
  138.  
  139.  
  140.  Internet-Drafts:
  141.  
  142.   No Current Internet-Drafts.
  143.  
  144.  Request For Comments:
  145.  
  146.   RFC  Stat Published    Title 
  147. ------- -- ---------- -----------------------------------------
  148. RFC1940      May 96     Source Demand Routing: Packet Format and Forwarding 
  149.                         Specification (Version 1).                             
  150.