rfc3353.txt

RFC 的详细文档！

5.4. Combinations of Triggers and Label Distribution Modes

   Table 2 shows the valid combinations of label distribution modes and
   trigger types that were discussed in the previous sections.  The (X)
   means that the combination is valid when the mixed L2/L3 forwarding
   feature is supported in the LSR.

     +----------------+---------------------------------------------+
     |                |              label requested by             |
     |                |          LSRu        |          LSRd        |
     |                +----------------------+----------------------+
     |                | upstream  |downstream|downstream |upstream  |
     |                |unsolicited|on demand |unsolicited|on demand |
     +----------------+-----------+----------+-----------+----------+
     |Request Driven  |           |          |           |          |
     |(incoming msg)  |    X      |    X     |           |          |
     +----------------+-----------+----------+-----------+----------+
     |Request Driven  |           |          |           |          |
     |(outgoing msg)  |           |          |     X     |    X     |
     +----------------+-----------+----------+-----------+----------+
     |Topology Driven |    X      |    X     |     X     |    X     |
     +----------------+-----------+----------+-----------+----------+
     |Traffic Driven  |    X      |    X     |    (X)    |   (X)    |
     +----------------+-----------+----------+-----------+----------+

   Table 2. Valid combinations of triggers and label distribution modes

6. Piggy-backing

   In Figure 9 (outgoing case) one can observe that instead of sending 2
   separate messages the label advertisement can be piggy-backed on the
   existing control messages.  For multicast two piggy-back candidates
   exist:

   a) Multicast routing messages:  protocols such as PIM-SM and CBT have
      explicit Join messages which could carry the label mappings.  This
      approach is described in [FARI].  When different multicast routing
      protocols are deployed, an extension to each of these protocols
      has to be defined.

   b) RSVP Resv messages:  a label mapping extension object for RSVP,
      also applicable to multicast, is proposed in [AWDU].

   The pros and cons of piggy-backing on multicast routing messages will
   be described now.






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


   Piggy-backing has following advantages:

   a) If the label advertisement is piggy-backed on multicast routing
      messages, then the distribution of routes and the distribution of
      labels is tightly synchronized.  This eliminates difficult corner
      cases such as "what do I do with a label if I don't (yet) have a
      routing table entry to attach it to?".  It also minimizes the
      interval between the establishment of the multicast route and the
      mapping of a label to the route.

   b) The number of control messages needed to support label
      advertisement beyond those needed to support the multicast routing
      itself is zero.

   Following disadvantages of piggy-backing can be identified:

   a) In dense-mode protocols there are no messages on which the label
      advertisement can be piggy-backed.  [FARI] proposes to add
      periodic messages to dense-mode protocols for the purpose of label
      advertisement, which is a heavy impact on the multicast routing
      protocol and it eliminates the message conserving benefit of
      piggy-backing.

   b) The second solution for the state co-existence problem (section
      3.4) cannot be applied in combination with piggy-backing.

   c) Piggy-backing requires extending the multicast routing protocol,
      and hence becomes less attractive if label advertisement needs to
      be supported for multiple multicast routing protocols.  Especially
      when not only the label advertisement but also the other two LDP
      functions (discovery and adjacency) are piggy-backed.

   d) Piggy-backing assumes the Downstream Unsolicited label
      distribution mode, this excludes a number of trigger methods (see
      Table 2).

   e) LDP normally runs on top of TCP, assuring a reliable communication
      between peer nodes.  Piggy-backed label advertisement often
      replaces the reliable communication with periodic soft-state label
      advertisements.  Because of this periodic label advertisement the
      control traffic (in number of bytes) will increase.










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


   f) If a VCID notification mechanism [NAGA] is required, the (in-band)
      notification can normally be done by sending the LDP bind through
      the newly established VC.  This way only one message is
      required.  This method cannot be combined with piggy-backing
      because the routing message is sent before the VC can be
      established.  An extra handshake message is thus required,
      diminishing the benefit of piggy-backing.

   So whether piggy-backing makes sense or not depends heavily on which
   and how many multicast routing protocols are deployed, whether LDP is
   already used for unicast, which trigger mechanism is used, ...
   Piggy-backing is just one possible component of an MPLS multicast
   solution.

7. Explicit Routing

   Explicit routing for unicast refers to overriding the unicast routing
   table by using LSPs.

   A first way to interpret "multicast explicit routing" is overriding
   the tree established by the multicast routing protocol by another LSP
   tree (e.g. a Steiner tree calculated by an off-line tool).  In this
   interpretation the current 'shortest path' multicast routing protocol
   becomes obsolete and can be replaced by label advertisement messages
   that follow an explicit route (e.g. a branch of the Steiner tree).

   A second way of interpreting "multicast explicit routing" is that the
   known multicast routing protocols are running, but that the messages
   generated by these protocols use explicit unicast routes (instead of
   the IGP shortest path routes) to construct trees.

8. QoS/CoS

8.1. DiffServ

   The Differentiated Services approach can be applied to multicast as
   well.  It introduces finer stream granularities (DiffServ Codepoint
   (DSCP) as an extra differentiator).  A sender can construct one or
   more trees with different DSCPs.

   These (S, G, DSCP) or (*, G, DSCP) trees can be mapped very easily
   onto LSPs when the traffic driven trigger is used.  In this case one
   can create LSPs with different attributes for the various DSCPs.
   Note however that these LSPs still use the same route as long as the
   tree construction mechanism itself does not take the DSCP as an
   input.





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


8.2. IntServ and RSVP

   RSVP can be used to setup multicast trees with QoS.  An important
   multicast issue is the problem of how to map the 'heterogeneous
   receivers' paradigm onto L2 (remark that it is not solved in IP
   either).  This subject is tackled in [CRAW].  Pragmatic approaches
   are the 'Limited Heterogeneity Model' which allows a best effort
   service and a single alternate QoS (e.g. a QoS proposed by the sender
   in a RSVP Path message) and the 'Homogeneous Model' which allows only
   a single QoS.

   The first approach will construct full trees for each service class.
   The sender has to send its traffic twice across the network (e.g. 1
   best-effort and 1 QoS tree).  Both trees can be label switched.

   The second approach constructs one tree and the best-effort users are
   connected to the QoS tree.  If the branches created for best-effort
   users are not to be label switched, (thus carried by a hop-by-hop
   default LSP) the QoS multicast traffic has to be merged onto these
   default LSPs.  This function can be provided by the 'mixed L2/L3
   forwarding' feature described in section 4.  If this is not
   available, merging is necessary to avoid a return to L3 in the QoS
   LSP.

   The mapping of the IntServ service categories onto L2 for ATM service
   categories is studied in [GARR].

9. Multi-access Networks

   Multicast MPLS on multi-access networks poses a special problem.  An
   LSR that wants to join a group must always be ready to accept the
   label that is already assigned to the group LSP (to another
   downstream LSR on the link).  This can be achieved in three ways:

   1) Each LSR on the multi-access link memorizes all the advertised
      labels on the link, even if it has not received a join for the
      associated group.  If an LSR is added to the multi-access link it
      has to retrieve this information from another LSR on the link or
      in case of soft state label advertisement it can wait a certain
      time before it can allocate labels itself.  If LSRs allocate a
      label 'at the same moment' the LSR with the highest IP address
      could keep it, while the other LSRs withdraw the label.

   2) Each LSR gets its own label range to allocate labels from.  A
      mechanism for label partitioning is described in [FARI].  If an
      LSR is added to the multi-access link, the label ranges have to be
      negotiated again and possibly existing LSPs are torn down and
      are reconstructed with other labels.



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


   3) Per multi-access link one LSR could be elected to be responsible
      for label allocation.  When an LSR needs a label, it can request
      it from this Label Allocation LSR.

   Unlike the unicast case, a multicast stream can have more than one
   downstream LSR which all have to use the same label.  Two solutions
   for label advertisement can be thought of:

   1) [FARI] proposes to multicast the label advertisements to all LSRs
      on the shared link.  Since multicast is not reliable this requires
      periodic label advertisements, yielding label advertisement
      duplicates in time.

   2) Another approach is that an LSR unicasts its label advertisements
      in a reliable way (TCP) to all other (or to all interested) LSRs
      on the shared link.  In this approach the hard-state character of
      LDP can be maintained but the label advertisement is duplicated in
      space.

   Since LSPs are only rewarding if they have a long lifetime and since
   the number of LSRs on a shared link is limited the second approach
   seems advantageous.

   Another issue with multicast in multi-access networks is whether to
   use upstream or downstream label assignment.  For multicast traffic,
   upstream label allocation is simpler since there can be only one
   upstream node per link that belongs to a multicast tree.  This
   (upstream) node can assign a unique label for the FEC.  With
   downstream allocation, there may be multiple downstream nodes for a
   given tree on a multi-access link; each node may propose a different
   label assignment for a FEC that would require some resolution process
   in order to come up with a single label per multicast FEC on the
   link.

   Once a label has been assigned, it is possible that the label
   assigner leaves the tree.  With downstream label assignment, this
   could happen when the label allocator leaves the group.  With
   upstream assignment this could happen when the upstream LSR changes
   due to a unicast topology change.

10. More Issues

10.1. TTL Field

   The TTL field in the IP header is typically used for loop detection.
   In IP multicast it is also used to limit the scope of the multicast
   packets by setting an appropriate TTL value.




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


   Thus in LSRs that do not support a TTL decrement function (e.g. ATM
   LSR), the scope restriction function is affected.  Suppose one could
   calculate in advance the number of hops an LSP traverses.  In a
   unicast LSP the TTL value could then be decremented at the ingress or
   the egress node.  For multicast all the branches of the tree can have
   different lengths so the TTL can only be decremented at the egress
   node, potentially wasting bandwidth if the TTL turns out to be zero
   or negative.

10.2. Independent vs. Ordered Label Distribution Control

   Current Label Distribution Terminology is only defined for unicast.
   The following sections explore what this terminology might mean in a
   multicast context.

   In Independent Control ([ANDE]) each LSR can take the initiative to
   do a label mapping.  In Ordered Control ([ANDE]) an LSR only maps a
   label when it already received a label from its next-hop.

   All the previously described trigger methods (section 5) combine with
   Independent Control.  Note that if the request driven approach is
   used with Independent Control the label distribution still behaves as
   in Ordered Control:  the control messages flow from the egress node
   upstream, imposing the same sequence to the label advertisement.

   Ordered Control is not applicable for a traffic driven trigger in
   case the node does not support mixed L2/L3 forwarding.  According to
   Table 2, this case implies that labels are requested by the upstream
   LSR.  Suppose in Figure 11 that an LSP exists from S to R1 and a new
   branch must be added to R2.  B will only accept a label on the A-B
   link if a label is already assigned on the B-C link.  However, to
   establish a label on the B-C link, B must already receive traffic on
   the A-B link.

                                     N---N---R1
                                    /
                                   /
                           S -----A