home *** CD-ROM | disk | FTP | other *** search
/ Internet Standards / CD1.mdf / INET / IETF / 93JUL / ROUTING < prev    next >
Encoding:
Text File  |  1993-09-23  |  5.6 KB  |  139 lines

  1.  
  2. Routing Area
  3.  
  4. Director(s):
  5.  
  6.  
  7.    o Bob Hinden:  hinden@eng.sun.com
  8.  
  9.  
  10. Area Summary reported by Bob Hinden/Sun Microsystems
  11.  
  12.  
  13. Border Gateway Protocol Working Group (BGP) and
  14. OSI IDRP for IP Over IP Working Group (IPIDRP)
  15.  
  16. The BGP and IPIDRP Working Groups met jointly.  BGP and IPIDRP will be
  17. writing a joint usage document.  Implementors' experiences were
  18. solicited for writing the Proposed Standard report by September for both
  19. protocols.
  20.  
  21. BGP and IDRP will be forwarding final documents, plus the Proposed
  22. Standard report, to the Routing Area Director so that BGP4 and IDRP can
  23. go forward.  Both IPIDRP and BGP will be going into ``hiatus'' once the
  24. standard requests are granted.
  25.  
  26.  
  27. Inter-Domain Multicast Routing Working Group (IDMR)
  28.  
  29. The Amsterdam IETF meeting was the first official meeting of the IDMR
  30. Working Group.  The working group met for two 2-hour sessions.
  31.  
  32. During the first session, Deborah Estrin gave a presentation on ESL, one
  33. of the new proposals for inter-domain multicast routing.  This was the
  34. result of a collaboration with Steve Deering, Dino Farinacci, and Van
  35. Jacobson.  The motivation behind the design of ESL was, for groups with
  36. a relatively small number of senders (sources), to allow receivers to
  37. receive data from those sources either over a shared tree, or over a
  38. shortest-path tree rooted at the source.  The latter is useful for
  39. applications requiring minimal delay between senders and receivers.  It
  40. was agreed that, because ESL is in its early stages of development,
  41. there remain specification and engineering details that need to be
  42. resolved.
  43.  
  44. The second session was mostly dedicated to discussing the IDMR charter.
  45. It was unanimously agreed that the current charter is lacking with
  46. respect to many aspects of inter-domain multicasting, and it should be a
  47. goal of the working group to try to resolve many of these, for example,
  48. user group management and interoperability.
  49.  
  50. The conclusion of this discussion was that the charter should be
  51. re-worked and re-submitted to the area director after the items to be
  52. worked on have been enumerated in order of priority.
  53.  
  54.                                    1
  55.  
  56.  
  57.  
  58.  
  59.  
  60. IP Routing for Wireless/Mobile Hosts Working Group (MOBILEIP)
  61.  
  62.  
  63. The MOBILEIP Working Group met twice at the Amsterdam IETF, with only
  64. one of the previously most active contributors unable to attend.
  65. Outside of the working group meetings themselves considerable time was
  66. spent over coffee tables, meals, and trains discussing the major issues.
  67. There seems to be movement towards some common mechanisms (the question
  68. of ``encapsulation'' versus ``source routing,'' for example, seems to
  69. have been settled in favor of encapsulation).
  70.  
  71. There were reports on a user requirements document, as well as on
  72. liaison activities with IEEE 802.11.  There were substantial discussions
  73. about common terminology, beaconing, and how the location of a host is
  74. discovered.  The creation of an ``IP encapsulation working group''
  75. within the IETF was suggested.
  76.  
  77.  
  78.  
  79. RIP Version II (RIPV2)
  80.  
  81.  
  82. The use of the Routing Domain in RIP-2 was discussed.  Its use is still
  83. unclear.  It was determined that the use of the field could not be
  84. sufficiently well defined to meet the varying needs of those few people
  85. who would like to use it.  The field also poses difficult MIB problems
  86. (discussed below).  Therefore, it has been decided to remove the field
  87. from the protocol and leave a Must Be Zero field in its place.
  88.  
  89. There were two proposed changes to the MIB. The first was to deprecate
  90. the Routing Domain object.  It has been pointed out that the tables
  91. cannot be indexed correctly unless the Routing Domain object was used as
  92. part of the index.  Given that the Routing Domain field is not well
  93. defined, this change would result in an overall simplification of the
  94. MIB. The second proposal dealt with handling unnumbered interfaces.
  95. While the RIP-2 protocol does not expressly address them, their
  96. existence does require consideration since the MIB tables cannot be
  97. indexed properly with unnumbered interfaces.  The proposal is to use a
  98. network number of zero and a host number of if_index to create a
  99. suitable IP address for use in indexing tables.
  100.  
  101. There are currently two independent implementations of RIP-2:  gated and
  102. Xylogics's routed.  The MIB has been implemented for gated.  ACC has a
  103. partial implementation of RIP-2 and is planning to implement the
  104. remainder.
  105.  
  106. Gerry Meyer's Demand Routing proposal was discussed at length.  It was
  107. agreed that it performed a useful function.  It was pointed out that it
  108. simulated many of the functions of TCP and that other routing protocols,
  109. such as RAP, used TCP.
  110.  
  111.                                    2
  112.  
  113.  
  114.  
  115.  
  116.  
  117. Source Demand Routing (SDR)
  118.  
  119. Following a brief overview of the SDR forwarding protocol, Deborah
  120. Estrin described successful experiments completed on small-scale network
  121. testbeds including DARTnet.  Plans were made for continued
  122. experimentation in conjunction with MERIT and others.  No changes have
  123. been made to the specification since the last IETF; however a few very
  124. minor changes are planned.
  125.  
  126. Tony Li presented a language for describing SDRP policies, and a simple
  127. request-response protocol for exchanging this information.  The group
  128. also reviewed the draft specification for optional-setup mode in SDRP.
  129. The implementation of this functionality will be finished at the end of
  130. the summer.  Drafts of the policy language and setup specification are
  131. available now, and will submitted as Internet-Drafts in the coming month
  132. or two.  In addition, a draft usage document and MIB will be submitted
  133. as Internet-Drafts before the next IETF. At the next IETF Tony Li will
  134. lead a detailed walk through of the SDRP specification.
  135.  
  136.  
  137.  
  138.                                    3
  139.