rfc3353.txt

RFC 的详细文档！

                                   \
                                    \
                                     B---C---R2

                                Figure 11.








Ooms, et al.                 Informational                     [Page 23]

RFC 3353          IP Multicast in an MPLS Environment        August 2002


10.3. Conservative vs. Liberal Label Retention Mode

   In the Conservative Mode ([ANDE]) only the labels that are used for
   forwarding data (if the next-hop for the FEC is the LSR which
   advertised the label) are allocated and maintained.  In the Liberal
   Mode labels are advertised and maintained to all neighbors.  Liberal
   Mode does not make sense in multicast.  Two reasons can be identified
   for this:

   1) All LSRs have a route for each unicast FEC.  This is not true for
      multicast FECs.

   2) For multicast an LSR always knows to which neighbor to send the
      label request or the label map messages.  In e.g. unicast
      Downstream Unsolicited mode (see below) the LSR does not know
      where to send the label mappings and thus has to send the mapping
      to all its neighbors.  In this case supporting the Liberal Mode
      does not generate extra messages (it still requires extra state
      information and label space) and thus the threshold to support
      Liberal Mode could be considered lower.

   Table 3 shows the cases where it is known by an LSR where to send its
   label requests.

              +---------+----------------------------------+
              |         |       label requested by         |
              |         |      LSRu      |      LSRd       |
              +---------+----------------+-----------------|
              |unicast  |      Yes       |       No        |
              +---------+----------------+-----------------|
              |multicast|      Yes       |      Yes        |
              +---------+----------------+-----------------+

       Table 3. Does an LSR know where to send its label requests ?

   For a unicast flow, an LSR can determine the next hop LSR, which is
   the one to send the request to in case of Upstream Unsolicited or
   Downstream on Demand mode.  The LSR is however not able to find the
   previous hop.  The previous hop is not necessarily the next hop
   towards the source, because the path from A to B is not necessarily
   the same as the path from B to A.  Such a situation can occur as a
   result of asymmetric link measures or in the event that multiple
   equal cost paths exist [PAXS].

   In the case of multicast, an LSR knows both the next hop(s) and the
   previous hop.  Because multicast trees are constructed using the
   reverse shortest path method, the previous hop is always the next hop
   towards the source or towards the root of the tree.



Ooms, et al.                 Informational                     [Page 24]

RFC 3353          IP Multicast in an MPLS Environment        August 2002


10.4. Downstream vs. Upstream Label Allocation

   The label can be allocated by either the downstream LSR (Downstream
   on Demand, Downstream Unsolicited) or the upstream LSR (Upstream on
   Demand, Upstream Unsolicited, implicit).  The advantages of
   downstream label allocation are:

   a) It is the same mode as for unicast LDP, thus eliminating the need
      to develop upstream label distribution procedures.

   b) The same label can be kept when the upstream LSR changes due to a
      route change, which is an advantage on multi-access networks (see
      section 9).

   c) Compatible with piggy-backing (especially the downstream
      distribution mode).

   The advantages of upstream label allocation are:

   a) Easier label allocation in multi-access networks (see section 9).

   b) The same label can be kept when the downstream LSR (which would
      have been the label allocator in downstream mode in a multi-access
      network) leaves the group (see section 9).

   c) The upstream and implicit distribution mode allow a faster LSP
      setup when the LSP is traffic triggered.

   Whether to use upstream or downstream label distribution is outside
   the scope of this framework.  The relative complexity between the
   necessary protocol extensions and the resolution mechanism needed, as
   well as the relative operational complexity, will influence which way
   to go.

10.5. Explicit vs. Implicit Label Distribution

   Beside the explicit distribution modes (which use a signaling
   protocol), [ACHA] proposes an implicit label distribution method by
   using unknown labels.  This method has all the advantages of the
   upstream label allocation method and is probably the fastest label
   advertisement method for traffic triggered LSPs.

   Implicit label distribution is not applicable if the FEC-to-label
   binding has been advertised prior to traffic arrival, e.g. explicit
   routing (i.e. if all the information necessary to identify the FEC is
   not present in the packet).





Ooms, et al.                 Informational                     [Page 25]

RFC 3353          IP Multicast in an MPLS Environment        August 2002


   Explicit distribution allows pre-establishment (before the arrival of
   data) of LSPs with topology or request driven triggers.

11. Security Considerations

   In general, the use of multicast in an MPLS environment poses no
   extra security issues beyond the ones that already exist in multicast
   and MPLS protocols as such.

   The protocols described in this document are however not suited to
   cross administrative boundaries.

   When the multicast tree is determined by an existing multicast
   routing protocol (this is the assumption made in this document,
   except for the Explicit Routing section), clearly no additional
   security issues are introduced with respect to the shape of the tree
   (e.g.  unauthorized joining, tapping, blackholing, injecting traffic,
   ...).  These security issues should have been addressed in the
   specifications of the multicast routing protocols.

   In the MPLS context it is possible that control messages trigger L2
   resource allocations (e.g. LSPs).  If security flaws would still be
   present in the existing protocols (which possibly are not too harmful
   in its original context) the abusive sending of such control messages
   can yield more severe DoS attacks.

   In case of an "explicit routed" tree that is calculated centrally,
   sufficient authentication must be done on the control messages that
   set up the tree in the network nodes.

12. Acknowledgements

   The authors would like to thank Eric Rosen, Piet Van Mieghem, Philip
   Dumortier, Hans De Neve, Jan Vanhoutte, Alex Mondrus and Gerard
   Gastaud for the fruitful discussions and/or their thorough revision
   of this document.















Ooms, et al.                 Informational                     [Page 26]

RFC 3353          IP Multicast in an MPLS Environment        August 2002


Informative References

   [ACHA]  A. Acharya, R. Dighe and F. Ansari, "IP Switching Over Fast
           ATM Cell Transport (IPSOFACTO) : Switching Multicast flows",
           IEEE Globecom '97.

   [ADAM]  A. Adams, J. Nicholas, W. Siadak, Protocol Independent
           Multicast Version 2 Dense Mode Specification", Work In
           Progress.

   [ANDE]  Andersson, L., Doolan, P., Feldman, N., Fredette, A. and
           R. Thomas, "LDP Specification", RFC 3036, January 2001.

   [AWDU]  Awduche, D., Berger, L., Gan, D., Li, T., Swallow, G.  and
           V. Srinivasan, "RSVP-TE: Extensions to RSVP for LSP Tunnels",
           RFC 3209, December 2001.

   [BALL]  Ballardie, A., "Core Based Trees (CBT) Multicast Routing
           Architecture", RFC 2201, September 1997.

   [CONT]  Conta, D., Doolan, P. and A. Malis, "Use of Label Switching
           on Frame Relay Networks", RFC 3034, January 2001.

   [CRAW]  Crawley, E., Berger, L., Berson, S., Baker, F., Borden, M.
           and J. Krawczyk, "A Framework for Integrated Services and
           RSVP over ATM", RFC 2382, August 1998.

   [DAVI]  Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen,
           E., Swallow, G. and P. Doolan, "MPLS using LDP and ATM VC
           switching", RFC 3035, January 2001.

   [DEER]  Deering, S., Estrin, D., Farinacci, D., Helmy, A., Thaler,
           D., Handley, M., Jacobson, V., Liu, C., Sharma, P. and L Wei,
           "Protocol Independent Multicast-Sparse Mode (PIM-SM):
           Protocol Specification", RFC 2362, June 1998.

   [FARI]  D. Farinacci, Y. Rekhter, E. Rosen and T. Qian, "Using PIM to
           Distribute MPLS Labels for Multicast Routes", Work In
           Progress.

   [FENN]  Fenner, W., "Internet Group Management Protocol, IGMP,
           Version 2", RFC 2236, November 1997.

   [GARR]  Garrett, M. and M. Borden, "Interoperation of Controlled-Load
           Service and Guaranteed Service with ATM", RFC 2381, August
           1998.





Ooms, et al.                 Informational                     [Page 27]

RFC 3353          IP Multicast in an MPLS Environment        August 2002


   [HOLB]  H. Holbrook, B. Cain, "Source-Specific Multicast for IP",
           Work In Progress.

   [MOY]   Moy, J., "Multicast Extensions to OSPF", RFC 1584, March
           1994.

   [NAGA]  Nagami, K., Demizu, N., Esaki, H., Katsube, Y. and P. Doolan,
           "VCID Notification over ATM link for LDP", RFC 3038, January
           2001.

   [PERL]  R. Perlman, C-Y. Lee, A. Ballardie, J. Crowcroft, Z. Wang, T.
           Maufer, "Simple Multicast", Work In Progress.

   [PUSA]  T. Pusateri, "Distance Vector Multicast Routing Protocol",
           Work In Progress.

   [PAXS]  V. Paxson, "End-to-End Routing Behavior in the Internet",
           IEEE/ACM Transactions on Networking 5(5), pp. 601-615.

   [ROSE]  Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow,
           G., Li, T. and A. Conta, "MPLS Label Stack Encoding",
           RFC 3032, January 2001.

Authors Addresses

   Dirk Ooms
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerp, Belgium.
   Phone : [phone]
   Fax   : [phone]
   EMail: [e-mail]

   Bernard Sales
   Alcatel Corporate Research Center
   Fr. Wellesplein 1, 2018 Antwerp, Belgium.
   Phone : [phone]
   EMail: [e-mail]

   Wim Livens
   Colt Telecom
   Zweefvliegtuigstraat 10, 1130 Brussels, Belgium
   Phone : [phone]
   Fax   : [phone]
   EMail: [e-mail]







Ooms, et al.                 Informational                     [Page 28]

RFC 3353          IP Multicast in an MPLS Environment        August 2002


   Arup Acharya
   IBM TJ Watson Research Center
   30 Saw Mill River Road, Hawthorne
   NY 10532
   Phone : [phone]
   EMail: [e-mail]

   Frederic Griffoul
   Ulticom, Inc.
   Les Algorithmes, 2000 Route des Lucioles, BP29
   06901 Sophia-Antipolis, FRANCE
   EMail: [e-mail]

   Furquan Ansari
   Bell Labs, Lucent Tech.
   101 Crawfords Corner Rd., Holmdel, NJ 07733
   Phone : [phone]
   Fax