home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / mpls / mpls-charter.txt < prev    next >
Text File  |  1997-10-25  |  9KB  |  220 lines
  1.  
  2. Multiprotocol Label Switching (mpls)
  3. ------------------------------------
  4.  
  5.  Charter 
  6.  Last Modified: 24-Oct-97
  7.  
  8.  Current Status: Active Working Group
  9.  
  10.  Chair(s):
  11.      George Swallow <swallow@cisco.com>
  12.      Vijay Srinivasan <vijay_srinivasan@vnet.ibm.com>
  13.  
  14.  Routing Area Director(s): 
  15.      Joel Halpern  <jhalpern@newbridge.com>
  16.  
  17.  Routing Area Advisor: 
  18.      Joel Halpern  <jhalpern@newbridge.com>
  19.  
  20.  Mailing Lists: 
  21.      General Discussion:mpls@external.cisco.com
  22.      To Subscribe:      mpls-request@cisco.com
  23.          In Body:       in body: subscribe (unsubscribe)
  24.      Archive:           ftp://ftpeng.cisco.com/mpls/mpls
  25.  
  26. Description of Working Group:
  27.  
  28. Problem Statement:
  29.  
  30. Recently the use of label-swapping based forwarding ("label switching")
  31. in conjunction with network layer routing has attracted much attention.
  32. Several vendors have proposed techniques based on this paradigm. Among
  33. the problems this paradigm is expected to address are the following:
  34.  
  35. 1.  Scalability of network layer routing
  36.  
  37.     Using labels as a means to aggregate forwarding information, while
  38.     working in the presence of routing hierarchies.
  39.  
  40. 2.  Greater flexibility in delivering routing services
  41.  
  42.     Using labels to identify particular traffic which are to receive
  43.     special services, e.g. QoS.
  44.  
  45.     Using labels to provide forwarding along an explicit path different
  46.     from the one constructed by destination-based forwarding.
  47.  
  48. 3.  Increased performance
  49.  
  50.     Using the label-swapping paradigm to optimize network performance.
  51.     
  52. 4.  Simplify integration of routers with cell switching based
  53.     technologies
  54.  
  55.     a) making cell switches behave as peers to routers (thus reducing
  56.        the number of routing peers that a  router has to maintain),
  57.  
  58.     b) by making information about physical topology available to
  59.        Network Layer routing procedures, and
  60.  
  61.     c) by employing common addressing, routing, and management
  62.        procedures.
  63.  
  64. High Level Requirements
  65.  
  66. 1.  The solution should be general with respect to data link
  67.     technologies. Specific optimizations for particular media will be
  68.     considered.
  69.  
  70. 2.  The solution must be compatible with existing internetwork
  71.     technologies and routing protocols.
  72.  
  73. 3.  The solution should be capable of operating independently of the
  74.     underlying routing protocol.  It has been observed that
  75.     considerable optimizations can be achieved in some cases by small
  76.     enhancements of existing protocols.  Such enhancements will be
  77.     considered in the case of IETF standard routing protocols, and if
  78.     appropriate, coordinated with the relevant working group.
  79.  
  80. 4.  The solution should support a wide range of forwarding
  81.     granularities associated with a given label, from a single
  82.     application flow to a group of topologically related destinations.
  83.  
  84. 5.  The solution should support operations, administration, and
  85.     maintenance facilities at least as extensive as those supported in
  86.     IP networks.
  87.  
  88. 6.  Routing protocols that could be used in conjuction with MPLS
  89.     could be based on distributed computation. As such, during routing
  90.     transients these protocols may construct forwarding paths that
  91.     contain loops. The protocols defined by MPLS must provide protocol
  92.     mechanism(s) to either prevent the formation of loops and/or
  93.     contain the amount of (networking) resources that could be consumed
  94.     due to the presence of such loops.
  95.  
  96. 7.  The standard must clearly state how the protocol operates in a 
  97.     hierarchical network.
  98.  
  99. 8.  Scalability issues will be considered and analyzed.  Very scalable
  100.     solutions will be sought.  For example, in the case of ATM
  101.     technologies, the solution will attempt to conserve VC usage.
  102.  
  103. Charter Statement:
  104.  
  105. Currently, none of the solutions that that employ label-swapping based
  106. forwarding ("label switching") in conjunction with network layer
  107. routing are based on standard technology. In order to be able to
  108. achieve the benefits of this new technology, a standard solution is
  109. necessary.
  110.  
  111. The working group is responsible for standardizing a base technology
  112. for using label swapping forwarding paradigm (label switching) in
  113. conjunction with network layer routing and for the implementation of
  114. that technology over various link level technologies, which may include
  115. Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as
  116. Gigabit Ethernet, etc.), Token Ring,...
  117.  
  118. This includes procedures and protocols for the distribution of labels
  119. between routers, encapsulations, multicast considerations, use of
  120. labels to support higher layer resource reservation and QoS mechanisms,
  121. and definition of host behaviors.
  122.  
  123.  
  124. Objectives:
  125.  
  126. 1.  Specify standard protocol(s) for maintenance and distribution of 
  127. label
  128.     binding information to support unicast destination-based routing 
  129. with
  130.     forwarding based on label-swapping.
  131.  
  132. 2.  Specify standard protocol(s) for maintenance and distribution of 
  133. label
  134.     binding information to support multicast routing with
  135.     forwarding based on label-swapping.
  136.  
  137. 3.  Specify standard protocol(s) for maintenance and distribution of 
  138. label
  139.     binding information to support hierarchy of routing knowledge (e.g.,
  140.     complete segregation of intra and inter-domain routing) with 
  141. forwarding 
  142.     based on label-swapping.
  143.  
  144. 4.  Specify standard protocol(s) for maintenance and distribution of 
  145. label
  146.     binding information to support explicit paths different from the one 
  147.     constructed by destination-based forwarding with forwarding based on 
  148.     label-swapping.
  149.  
  150. 5.  Specify standard procedures of carrying label information over 
  151. various
  152.     link level technologies.
  153.  
  154. 6.  Specify a standard way to use the ATM user plane
  155.  
  156.     a) Allow operation/co-existence with standard (ATM Forum, ITU, etc.)
  157.        ATM control plane and/or standard ATM hardware
  158.     b) Specify a 'label swapping' control plane
  159.     c) Take advantage of possible mods/improvements in ATM
  160.        hardware, for example the ability to merge VCs
  161.  
  162. 7.  Discuss support for QOS (e.g. RSVP).
  163.  
  164. 8.  Define standard protocol(s) to allow direct host (e.g. server) 
  165.     participation.
  166.  
  167. Coordination:
  168.  
  169. The working group will coordinate its activities with other working
  170. groups as appropriate.
  171.  
  172.  Goals and Milestones: 
  173.  
  174.    Mar 97       Produce Framework Document Internet-Draft to contain goals with
  175.                 detailed motivations and description of solution space, 
  176.                 possible approaches                                            
  177.  
  178.    May 97       Submit Framework Document to IESG (Informational RFC)*         
  179.  
  180.    May 97       Freeze Internet Draft for carrying label information over 
  181.                 serial lines (p2p links) and over LAN media (e.g., Ethernet, 
  182.                 Token Ring, FDDI)                                              
  183.  
  184.    Jun 97       Submit Achitecture Document to IESG (Informational RFC)        
  185.  
  186.    Aug 97       Submit specifications for the protocol to distribute label 
  187.                 binding information for unicast routes to IESG (Standards 
  188.                 Track)                                                         
  189.  
  190.    Oct 97       Submit specifications for handling label binding information 
  191.                 (including distribution of this information) for multicast 
  192.                 routes to IESG (Standards Track)                               
  193.  
  194.    Dec 97       Submit specifications for Operation over ATM to IESG (Standards
  195.                 Track)                                                         
  196.  
  197.    Dec 97       Submit specifications for carrying label information over 
  198.                 serial lines (p2p links) and over LAN media (e.g., Ethernet, 
  199.                 Token Ring, FDDI) to IESG (Standards Track)                    
  200.  
  201.    Apr 98       Submit procedures for Host Behavior to IESG (Standards Track)  
  202.  
  203.    Apr 98       AD review status of WG efforts and determine whether to close 
  204.                 down or not. If not, identify next set of milestones.          
  205.  
  206.  
  207.  Internet-Drafts:
  208.  
  209. Posted Revised       I-D Title  <Filename>
  210. ------ ------- ------------------------------------------
  211.  May 97 Aug 97  <draft-ietf-mpls-framework-01.txt> 
  212.                 A Framework for Multiprotocol Label Switching                  
  213.  
  214.  Aug 97 New     <draft-ietf-mpls-arch-00.txt> 
  215.                 A Proposed Architecture for MPLS                               
  216.  
  217.  Request For Comments:
  218.  
  219.   None to date.
  220.