home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mpls / mpls-minutes-97aug.txt < prev   
Text File  |  1997-10-10  |  10KB  |  247 lines

  1. Draft MPLS Minutes
  2.  
  3. Framework Document - Ross Callon
  4.  
  5.   <draft-ietf-mpls-framework-01.txt>
  6.  
  7. Ross made a brief presentation on the framework document.  Another
  8. draft was submitted.  In it, several sections of the former draft were
  9. fleshed out.  The framework document is also being used to capture
  10. architecture discussions which have lead to particular decisions in the
  11. architecture document.  The hierarchy and multicast sections were
  12. pointed out as in need of further work.
  13.  
  14.  
  15. MPLS Architecture - Callon, Rosen, Viswanathan
  16.  
  17.    <draft-rosen-mpls-arch-00.txt>
  18.  
  19. Eric Rosen presented the draft.  An extensive number of architectural
  20. issues have been agreed and settled.  These include the semantics of
  21. labels, the concept of equivalence classes, the need for hierarchy and
  22. thus the label stack, the need for explicit routes, a preference for
  23. topology based (actually control) label distribution vs traffic (data)
  24. based setup.
  25.  
  26. Several important issues remain to be resolved.  These were discussed
  27. extensively during the meeting, but with no resolution.  The
  28. discussion did have the effect of getting a large number of people
  29. informed on the issues.  The most prominent issues are:
  30.  
  31.   1.  Distributed vs Egress control
  32.  
  33.   The debate here is one of both versus egress only.  The observation
  34.   was made that the two modes can interoperate in a natural way.  Arun
  35.   on the other hand argues that egress control offers all the
  36.   capabilities of distributed control and more, so why have two.
  37.   In particular, egress control allows the level of aggregation to be
  38.   consistent across the network.  Eric Rosen pointed out that this
  39.   only holds when you want to explicitly configure granularities other
  40.   than coarse or fine.  Those in favor of the distributed
  41.   method point to the issues of scalability and convergence time as
  42.   weaknesses of egress control.  
  43.  
  44.  
  45.   2.  Loop Prevention
  46.  
  47.   Rick Bovie presented the loop prevention scheme that is in the current
  48.   architecture draft.  The scheme is based on the diffusion algorithm.
  49.   It pins down routes until it can verify that a change will not result
  50.   in a loop.  The effects of this are that for traffic moving from a
  51.   good path to a better path will continue to use the good path.
  52.   Traffic which is being black-holed may be black-holed longer.  
  53.  
  54.   The architecture team believes that this is a workable approach with
  55.   acceptable trade-offs.  The point of contention is whether the
  56.   algorithm is mandatory or optional.  It was pointed out that in all
  57.   cases except ATM with VC merge, there are other mechanisms to deal
  58.   with looping packets.  Also, Jeremy Lawrence made a presentation
  59.   showing that some classes of ATM switches have the capability of using
  60.   fair queuing or fair buffering schemes to contain the effects of loops
  61.   in the VC merge case.
  62.  
  63.  
  64.   3.  LDP Transport
  65.  
  66.   It is agreed that LDP transactions need to be reliable, but there is
  67.   no agreement on how that reliability should be achieved.
  68.  
  69.  
  70. The architecture draft was accepted as the baseline text for the
  71. working group.  
  72.  
  73.  
  74. LAN Encapsulation  (Ghanwani)
  75.  
  76.    <draft-srinivasan-mpls-lans-label-00.txt>
  77.  
  78. IBM presented an update of the LAN proposal to carry labels in the
  79. destination MAC address field.  The most significant changes are: 
  80.  
  81. 1) switches are now required to swap labels 
  82.  
  83. 2) labels are placed in the source address of label update messages to
  84.    allow bridges to learn them
  85.  
  86. The authors will continue to refine their draft.
  87.  
  88.  
  89. MPLS encapsulation format  (Rosen)
  90.  
  91.    <draft-rosen-tag-stack-02.txt>
  92.  
  93. Eric presented the changes to his encaps draft, namely that the label
  94. is now 20 bits, the tos 3 bits and the TTL 8 bits.
  95.  
  96. It was proposed that the document be accepted as baseline text.  Vijay
  97. objected to the presence of a LAN encapsulation in that document given
  98. that the above LAN encaps has also been proposed.  Rosen agreed to
  99. drop the LAN section from his document (for now).  It was then agreed
  100. that rough consensus existed to promote the draft to a working group
  101. document.
  102.  
  103.  
  104. Soft State Switching (Blake)
  105.  
  106.     <draft-viswanathan-mpls-rsvp-00.txt>
  107.  
  108. IBM presented an update of their draft and then moved that it be
  109. accepted as baseline text.  This was objected to on the grounds that
  110. a) there was already another existing draft on the subject and b)
  111. their draft was a late submission.  After some discussion it was
  112. agreed that the authors of the two drafts would work together to
  113. create a combined document.  The two drafts appear to be quite
  114. reconcilable.
  115.  
  116.  
  117. MPLS in VC environments   (Doolan/Esaki/Demizu)
  118.  
  119. The soon-to-be-published draft addresses problems related running MPLS
  120. in ATM networks where the LSR's are not directly connected.  In this
  121. situation, the label (VPI/VCI) will not be preserved between the
  122. logically adjacent LSR's.
  123.  
  124. The document points out that there are two functions of a label.
  125. These are 1) to provide the value upon which something is switched and
  126. 2) to provide the binding between the switching operation and the
  127. associated equivalence class.  When LSRs are directly connected the
  128. same value is easily used for both functions.  But when ATM switches
  129. are not directly connected, the VPI/VCI cannot be used as a binding as
  130. the intermediate switch may not preserve the VPI/VCI from the incoming
  131. to the outgoing link.  
  132.  
  133. The authors plan to continue developing their draft.
  134.  
  135.  
  136. VC pool (Noritoshi)
  137.  
  138.     <draft-demizu-vcpool-00.txt>
  139.  
  140. Setting up ATM SVCs require signaling and this will introduce delay is
  141. setting up LSPs.  The proposal is to pre-create a pool of VCs.  When a
  142. tag is allocated, the VC is then picked in the LDP BIND procedure.
  143.  
  144.  
  145. Two modes of Explicit Label Distribution Protocol (Katsube)
  146.  
  147.     <draft-katsube-mpls-two-ldp-00.txt>
  148.  
  149. There are two modes of assigning labels, edge initiated and
  150. distributed.  The TDP specification could be classed in both
  151. categories where the conservative mode over ATM represents a edge
  152. initiated approach and the liberal mode the distributed.  The
  153. distribute approach are more light-weight as it only is link by link,
  154. while the edge initiated approach implies end to end signaling.  Edge
  155. initiated is desirable for controlling LSPs with arbitrary
  156. granularity, while distributed is adequate for multicast, RSVP driven
  157. or unicast with limited granularity.
  158.  
  159.  
  160. Double Identification Label Switching  - DILS (Droz)
  161.  
  162.     <draft-droz-dils-arch-00.txt>
  163.  
  164. The goal of this draft is to have a scalable solution for n
  165. endpoints, avoid the n**2 cross connect problem, preserve ATM traffic
  166. characteristics, and not require hardware changes.  The DILS concept
  167. involves the use of flow merging and connection setup as proposed by
  168. ARIS and the use of VP merging.
  169.  
  170. Two cases are supported a symmetric and an asymmetric. The proposal is 
  171. considered complementary to ARIS, it is possible to extend with QoS
  172. support.  It was claimed that this could be achieved with no ATM
  173. hardware changes. 
  174.  
  175. The presentation generated quite a bit of discussion.  It was pointed
  176. out that most ATM hardware does not allow the VCI replacement function
  177. to be independent of the VPI replacement, since these operations are
  178. coupled in normal ATM.  This means that in a worst case, the number of
  179. cross connects required is still n**2.
  180.  
  181.  
  182. Performance Issues in VC merge MPLS Switches  (Widjaja)
  183.  
  184.      <draft-widjaja-mpls-vc-merge-00.txt>
  185.  
  186. VC merging requires that all the cells of a packet be buffered before
  187. the first cell can be transmitted.  This changes the queueing behavior
  188. of ATM systems.  To investigate the effects of VC merge a series of
  189. comparative simulations was run across various utilizations and
  190. traffic models.
  191.  
  192. The simulations showed that within normal operational limits that the
  193. additional buffering for VC merging is minimal and that best effort
  194. traffic would benefit from VC merging.  As utilization increases, the
  195. additional drops due to VC merge decreases.
  196.  
  197.  
  198. Multi-Protocol Labels Switching: Performance and QoS Issues (Crosby)
  199.  
  200. The requirements on improved forwarding performance has to be better
  201. defined.  What is the metrics?  The intention is to explicitly
  202. describe the performance requirements and include them in the Framework
  203. document.
  204.  
  205.  
  206. CSR Experimental Operation (Esaki)
  207.  
  208. The WIDE project is an experimental network in Japan using legacy routers 
  209. and CSRs all based on ATM.  Hiroshi gave an update of their progress,
  210. pointing out the various service offerings and pointing out that the
  211. project incorporates hardware and software from different vendors.
  212.  
  213.  
  214. Scalability Issues in MPLS over ATM (Wang)
  215.  
  216.       <draft-wang-mpls-scaling-atm-00.txt>
  217.  
  218. Scalability is a major concern for MPLS over ATM.  While VC merging
  219. address this issue, it may not be available on all platforms.  This ID
  220. analyzes the scalability of MPLS without VC merge in terms of the size
  221. of the VPI/VCI space.  If all 28 bits in the VPI/VCI field are
  222. available for label switching, then the number of end to end LSPs that
  223. can be supported is equivalent to 32k endpoints.  Given that LSPs will
  224. end on routers rather than hosts, this is quite sufficient to support
  225. most real networks.
  226.  
  227. Support of different services between the same end points will consume
  228. additional VPI/VCI space.  However, the conclusion is that the
  229. combined VPI/VCI space in ATM should still be able to support networks
  230. of sufficient size.
  231.  
  232. In the ensuing discussion, it was pointed out that in most cases the
  233. size of the cross connect tables of the ATM switch would be the
  234. limiting factor.
  235.  
  236.  
  237.  
  238.  
  239.  
  240. ======================================================================
  241. George Swallow       Cisco Systems                   (508) 244-8143
  242.                      250 Apollo Drive
  243.                      Chelmsford, Ma 01824
  244.  
  245.  
  246.  
  247.