Network Working Group D. Ooms Request for Comments: 3353 Alcatel Category: Informational B. Sales Alcatel W. Livens Colt Telecom A. Acharya IBM F. Griffoul Ulticom F. Ansari Bell Labs August 2002 Overview of IP Multicast in a Multi-Protocol Label Switching (MPLS) Environment Status of this Memo This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved.
AbstractThis document offers a framework for IP multicast deployment in an MPLS environment. Issues arising when MPLS techniques are applied to IP multicast are overviewed. The pros and cons of existing IP multicast routing protocols in the context of MPLS are described and the relation to the different trigger methods and label distribution modes are discussed. The consequences of various layer 2 (L2) technologies are listed. Both point-to-point and multi-access networks are considered.
1. Introduction ............................................. 3 2. Layer 2 Characteristics .................................. 4 3. Taxonomy of IP Multicast Routing Protocols in the Context of MPLS ................................... 5 3.1. Aggregation .............................................. 5 3.2. Flood & Prune ............................................ 5 3.3. Source/Shared Trees ...................................... 6 3.4. Co-existence of Source and Shared Trees .................. 7 3.5. Uni/Bi-directional Shared Trees .......................... 10 3.6. Encapsulated Multicast Data .............................. 11 3.7. Loop-free-ness ........................................... 11 3.8. Mapping of Characteristics on Existing Protocols ......... 11 4. Mixed L2/L3 Forwarding in a Single Node .................. 12 5. Taxonomy of IP Multicast LSP Triggers .................... 14 5.1. Request Driven ........................................... 14 5.1.1. General .................................................. 14 5.1.2. Multicast Routing Messages ............................... 15 5.1.3. Resource Reservation Messages ............................ 15 5.2. Topology Driven .......................................... 16 5.3. Traffic Driven ........................................... 16 5.3.1. General .................................................. 16 5.3.2. An Implementation Example ................................ 17 5.4. Combinations of Triggers and Label Distribution Modes .... 18 6. Piggy-backing ............................................ 18 7. Explicit Routing ......................................... 20 8. QoS/CoS .................................................. 20 8.1. DiffServ ................................................. 20 8.2. IntServ and RSVP ......................................... 21 9. Multi-access Networks .................................... 21 10. More Issues .............................................. 22 10.1. TTL Field ................................................ 22 10.2. Independent vs. Ordered Label Distribution Control ....... 23 10.3. Conservative vs. Liberal Label Retention Mode ............ 24 10.4. Downstream vs. Upstream Label Allocation ................. 25 10.5. Explicit vs. Implicit Label Distribution ................. 25 11. Security Considerations .................................. 26 12. Acknowledgements ......................................... 26 Informative References........................................... 27 Authors' Addresses .............................................. 28 Full Copyright Statement ........................................ 30
Table of Abbreviations ATM Asynchronous Transfer Node CBT Core Based Tree CoS Class of Service DLCI Data Link Connection Identifier DRrecv Designated Router of the receiver DRsend Designated Router of the sender DVMRP Distant Vector Multicast Routing Protocol FR Frame Relay IGMP Internet Group Management Protocol IP Internet Protocol L2 layer 2 (e.g. ATM, Frame Relay) L3 layer 3 (e.g. IP) LSP Label Switched Path LSR Label Switching Router LSRd Downstream LSR LSRu Upstream LSR MOSPF Multicast OSPF mp2mp multipoint-to-multipoint MRT Multicast Routing Table p2mp point-to-multipoint PIM-DM Protocol Independent Multicast-Dense Mode PIM-SM Protocol Independent Multicast-Sparse Mode QoS Quality of Service RP Rendezvous Point RPT-bit RP Tree bit [DEER] RSVP Resource reSerVation Protocol SPT-bit Shortest Path Tree [DEER] SSM Source Specific Multicast TCP Transmission Control Protocol UDP User Datagram Protocol VC Virtual Circuit VCI Virtual Circuit Identifier VP Virtual Path VPI Virtual Path Identifier
For multicast, the optimal solution (minimum cost to interconnect N nodes) would impose a Steiner tree computation. Unfortunately, no multicast routing protocol today is able to maintain such an optimal tree. Different multicast protocols will therefore, in general, generate different trees. The discussion is focused on intra-domain multicast routing protocols. Aspects of inter-domain routing are beyond the scope of this document. DAVI]. ATM offers high switching capacities and QoS awareness, but in the context of MPLS it poses several limitations which are described in [DAVI]. Similar considerations are made for Frame Relay on L2 in [CONT]. The limitations can be summarized as: - Limited Label Space: either the standardized or the implemented number of bits available for a label can be small (e.g. VPI/VCI space, DLCI space), limiting the number of LSPs that can be established. - Merging: some L2 technologies or implementations of these technologies do not support multipoint-to-point and/or multipoint-to-multipoint 'connections', obstructing the merging of LSPs. - TTL: L2 technologies do not support a 'TTL-decrement' function. All three limitations can impact the implementation of multicast in MPLS as will be described in this document. When native MPLS is deployed the above limitations vanish. Moreover on PPP and Ethernet links the same label can be used at the same time for a unicast and a multicast LSP because different EtherTypes for MPLS unicast and multicast are defined [ROSE].
a) Volatile. Due to the Flood & Prune nature of the protocol, very volatile tree structures are generated. Solutions to map a dynamic L3 p2mp tree to a L2 p2mp LSP need to be efficient in terms of signaling overhead and LSP setup time. The volatile L2 LSP will consume a lot of labels throughout the network, which is a disadvantage when label space is limited. b) Traffic-driven. The router only creates state for a certain group when data arrives for that group. Routers also independently decide to remove state when an inactivity timer expires. - Thus LSPs can not be pre-established as is usually done in unicast. To minimize the time between traffic arrival and LSP establishment a fast LSP setup method is favorable. - Since creation and deletion of a L3 route at each node is triggered by traffic, this suggests that the LSP associated with the route be setup and torn down in a traffic-driven manner as well. - If an LSR does not support L3 forwarding this traffic-driven nature even requires that the upstream LSR takes the initiative to create an LSP (Upstream Unsolicited or Downstream on Demand label advertisement). Figure 1). R1 R1 R1 S1 / / / \ / / / \ / / / C---R2 S1---R2 S2---R2 / \ \ \ / \ \ \ S2 \ \ \ R3 R3 R3 Figure 1. Shared tree and Source trees The advantage of using shared trees, when label switching is applied, is that shared trees consume less labels than source trees (1 label per group versus 1 label per source and per group).
However, mapping a shared tree end-to-end on L2 implies setting up multipoint-to-multipoint (mp2mp) LSPs. The problem of implementing mp2mp LSPs boils down to the merging problem discussed earlier. Note that in practice shared trees are often only used to discover new sources of the group and a switchover to a source tree is made at very low bitrates. figures. It is also indicated whether the RPT-bit is set for the (S, G) state. 1) Figure 2 shows a switchover from shared to source tree. Assume that the shortest path from R1 to RP is via N1-N2-N5. N1, the Designated Router of receiver R1 (DRrecv), decides to initiate a source tree for source S1. After the arrival of data via the source tree in N2, N2 will send a prune to N5 for source S1. State co-existence occurs in the node where the overlap of shared and source tree starts (N2) and in the node where S1 does not need forwarding on the shared tree anymore (N5). PJ IJ PJS PJS -> 1 2 -> 1 2 -> 1 2 R1-----N1------N2------N3----S1 3| |3 IJ=Igmp Join ||PPS | PJ=Pim Join (*,G) |vPJ | PJS=Pim Join (S1,G) IJ PJ | PJ | PPS=Pim Prune (S1,G) -> -> |3 -> | R2-----N4------N5------RP----S2 1 2 1 2 1 Figure 2
The multicast routing states created in the Multicast Routing Table (MRT) are: in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) in N1: (*,G):2->1 in N2: (*,G):3->1 (S1,G):2->1 in N3: (S1,G):2->Reg,1 in N4: (*,G):2->1 in N5: (*,G):2->1,3 (S1,G)RPT-bit:2->1 2) Figure 3 shows that even without a switchover, state co-existence can occur. Multicast traffic from a sender will create (S, G) state in the Designated Router of the sender (DRsend; N3 in Figure 3 is the DRsend of S). Each node on a shared-tree has (*, G) state. Thus an on-tree DRsend has both (*, G) and (S, G) state. If the DRsend is on-tree it will also send a prune for S towards the RP, creating (S, G) state in all nodes until the first router which has a branch (N1 and N2 in Figure 3). S PPS PPS | PJ PJ PJ |2 PJ IJ 1 <- 1 3<- <- | <- <- PJ=Pim Join RP------N1----N2----N3----N4----R1 IJ=Igmp Join ^|2 1 2 1 3 1 2 PPS=Pim Prune (S,G) PJ|| IJ 1| <- N5----R2 2 Figure 3 The multicast routing states created in the MRT are: in RP: (*,G):Reg->1 (i.e. incoming itf=Reg; outgoing itf=1) in N1: (*,G):1->2,3 (S,G)RPT-bit:1->2 in N2: (*,G):1->2 (S,G)RPT-bit:1->none in N3: (*,G):1->3 (S,G):2->Reg,3 in N4: (*,G):1->2 in N5: (*,G):1->2
In the examples one can observe that two types of state co- existence occur: 1) (S, G) with RPT-bit not set (N2 in Figure 2, N3 in Figure 3). The (*, G) and (S, G) state have different incoming interfaces, but some common outgoing interfaces. It is possible that the traffic of S arrives on both the (*, G) and (S, G) interfaces. In normal L3 forwarding the (S, G)SPT-bit entry prohibits the forwarding of the traffic from S arriving on the (*, G) incoming interface. The traffic of S can only temporarily arrive on the incoming interfaces of both the (*, G) and (S, G) entries (until N5 in Figure 2 and N1 in Figure 3 have processed the prune messages). To avoid the temporary forwarding of duplicate packets L3 forwarding can be applied in this type of node. If one does not mind the temporary duplicate packets L2 forwarding can be applied. In this case the (*, G) and (S, G) streams have to be merged into the (*, G) LSP on their common outgoing interfaces. 2) (S, G) with RPT-bit set (N5 in Figure 2, N1 in Figure 3). The (*, G) and (S, G) state have the same incoming interface. The (S, G) traffic must be extracted from the (*, G) stream. In MPLS this state co-existence can be handled in several ways. Four approaches to this problem will be described: a) A first method to handle this state co-existence is to terminate the LSPs and forward all traffic of this group at L3. However a return to L3 can be avoided in case a (S, G) entry without an outgoing interface is added to the MRT (N2 in Figure 3). This entry will only receive traffic temporarily. In this particular case one could ignore the (S, G) state and maintain the existing (*, G) LSP, the disadvantage being duplicate traffic for a very short time. b) A second approach is to assign source specific labels on the nodes of the shared tree. Multiple labels will be associated with one (*, G) entry, corresponding to one label per active source. Since the nodes only know which sources are active when traffic from these sources arrives, the LSPs cannot be pre-established and a fast LSP setup method is favorable. c) A third way is that only source trees are labelswitched and that traffic on the shared tree is always forwarded at L3. This assumes that the shared tree is only used as a way for the receivers to find out who the sources are. By configuring a low bitrate switchover threshold, one can ensure that the receivers switchover to source trees very quickly.
d) In the fourth approach, an LSR which has (S, G) RPT-bit state with a non-null oif, advertises a label for (S, G) to the upstream LSR and this label advertisement is then propagated by each upstream LSR towards the RP. In this way a dedicated LSP is created for (S, G) traffic from the RP to the LSR with the (S, G) RPT-bit state. In the latter LSR, the (S, G) LSP is merged onto the (*, G) LSP for the appropriate outgoing interfaces. This ensures that (S, G) packets traveling on the shared tree do not make it past any LSR which has pruned S. BALL]) have the disadvantage of creating a lot of merging points (M) in the nodes (N) of the shared tree. Figure 4 shows these merging points resulting from 2 senders S1 and S2 on a bidirectional tree. S1 S2 || || v| <- <- <- <- |v <- <- | -> -> -> -> | -> ----N----M----M----M----M----M----N || || || || || || |v |v |v |v |v |v | | | | | | Figure 4. Multicast traffic flows from 2 senders on a bidirectional tree In Figure 5 the same situation for unidirectional shared trees is depicted. In this case the data of the senders is tunneled towards the root node R, yielding only a single merging point, namely the root of the shared tree itself. S1 tunnel || S2 <----- v| tunnel || to R<------------------------- v| -> -> | -> -> -> -> | -> ----N----N----N----N----N----N----N || || || || || || |v |v |v |v |v |v | | | | | | Figure 5. Multicast traffic flows from 2 senders on a unidirectional tree
section 4), the (S, G) traffic in DRsend can still be forwarded at L2 on all outgoing interfaces other than the Register interface. 2) The encapsulated traffic can also benefit from MPLS by label switching the tunnels. 3) If the root node decides to join the source (to avoid encapsulation/decapsulation), an end-to-end (S, G) LSP can be constructed. PUSA], MOSPF [MOY], CBT [BALL], PIM-DM [ADAM], PIM-SM [DEER], SSM [HOLB], SM [PERL].
+------------------+------+------+------+------+------+------+------+ | |DVMRP |MOSPF |CBT |PIM-DM|PIM-SM|SSM |SM | +------------------+------+------+------+------+------+------+------+ |Aggregation |no |no |no |no |no |no |no | +------------------+------+------+------+------+------+------+------+ |Flood & Prune |yes |no |no |yes |no |no |option| +------------------+------+------+------+------+------+------+------+ |Tree Type |source|source|shared|source|both |source|shared| +------------------+------+------+------+------+------+------+------+ |State Co-existence|no |no |no |no |yes |no |no | +------------------+------+------+------+------+------+------+------+ |Uni/Bi-directional|N/A |N/A |bi |N/A |uni |uni |bi | +------------------+------+------+------+------+------+------+------+ |Encapsulation |no |no |yes |no |yes |no |yes | +------------------+------+------+------+------+------+------+------+ |Loop Free |no |no |no |no |no |no |no | +------------------+------+------+------+------+------+------+------+ Table 1. Taxonomy of IP Multicast Routing Protocols From Table 1 one can derive e.g. that DVMRP will consume a lot of labels when the Flood & Prune L3 tree is mapped onto a L2 tree. Furthermore since DVMRP uses source trees it experiences no merging problem when label switching is applied. The table can be interpreted in the same way for the other protocols. Figure 6). Because multicast traffic can be forwarded to more than one outgoing interface one can consider the case that traffic to some branches is forwarded on L2 and to other branches on L3 (Figure 7). +--------+ +--------+ | L3 | | L3 | | +>>+ | | | | | | | | | +--|--|--+ +--------+ | | | | | | ->-----+ +-----> ->------>>-----> | L2 | | L2 | +--------+ +--------+ Figure 6. Unicast forwarding on resp. L3 or L2
+--------+ +--------+ +--------+ | L3 | | L3 | | L3 | | +>>++ | | +>>+ | | | | | || | | | | | | | +--|--||-+ +--|--|--+ +--------+ | | |+----> | | +-----> | +----> ->-----+ | | | |L2 | ->----->>-+ | | L2+-----> ->-----+>>------> | L2 +----> +--------+ +--------+ +--------+ Figure 7. Multicast forwarding on resp. L3, mixed L2/L3 or L2 Nodes that support this 'mixed L2/L3 forwarding' feature allow splitting of a multicast tree into branches in which some are forwarded at L3 while others are switched at L2. The L3 forwarding has to take care that the traffic is not forwarded on those branches that already get their traffic on L2. This can be accomplished by e.g. providing an extra bit in the Multicast Routing Table. Although the mixed L2/L3 forwarding requires processing of the traffic at L3, the load on the L3 forwarding engine is generally less than in a pure L3 node. Supporting this 'mixed L2/L3 forwarding' feature has the following advantages: a) Assume LSR A (Figure 8) is an MPLS edge node for the branch towards LSR B and an MPLS core node for the branch towards LSR C. The mixed L2/L3 forwarding allows that the branch towards C is not disturbed by a return to L3 in LSR A. +-------------+ | MPLS cloud | | N | | / \ | | / \ | | / \ | | A N | |/ \ \ | | \ \ | /| \ | B | C | | | +-------------+ Figure 8. Mixed L2/L3 forwarding in node A
b) Enables the use of the traffic driven trigger with the Downstream Unsolicited or Upstream on Demand label distribution mode, as explained in section 5.3.1. Figure 9 illustrates these two cases. LSRu LSRd LSRu LSRd -------+ +--- ---+ +------- | control | | control | <---*<-----message------- <-------message-------*---- | | | | | | trigger| | | | | |trigger | | bind | | bind | | +--------or---------> <---------or----------+ | bind-request | | bind-request | | | | | | | | | |----data----->| |-----data---->| incoming outgoing Figure 9. Request driven trigger (interception of resp. incoming and outgoing control messages)
The downstream LSR (LSRd) sends a control message to the upstream LSR (LSRu). In the case that incoming control messages are intercepted and the MPLS module in LSRu decides to establish an LSP, it will send an LDP bind (Upstream Unsolicited mode) or an LDP bind request (Downstream on Demand mode) to LSRd. Currently, for multicast, we can identify two important types of control messages: the multicast routing messages and the resource reservation messages. FARI], however, at the cost of modifying the IP multicast routing protocol itself! IP multicast routing messages can create both hard states (e.g. CBT Join + CBT Join-Ack) and soft states (e.g. PIM-SM Joins are sent periodically). The latter generates more control traffic for tree maintenance and thus requires more processing in the MPLS module. Triggers based on the multicast routing protocol messages have the disadvantage that the 'routing calculations' performed by the multicast routing daemon to determine the Multicast Routing Table are repeated by the MPLS module. The former determines the tree that will be used at L3, the latter calculates an identical tree to be used by L2. Since the same task is performed twice, it is better to create the multicast LSP on the basis of information extracted from the Multicast Routing Table itself (see section 5.2 and 5.3). The routing calculations become more complex for protocols which support a switch-over from a (*, G) tree to a (S, G) tree because more messages have to be interpreted. When a host has a point-to-point connection to the first router one could create 'LSPs up to the end-user' by intercepting not only the multicast routing messages but the IGMP Join/Prune messages ([FENN]) as well.
a) RSVP Resv messages can merge. b) RSVP Resv messages are only sent up to the first branch which made the required reservation. section 4) is not supported, the traffic driven trigger requires a label distribution mode in which the label is requested by the LSRu (Downstream on Demand or Upstream Unsolicited mode). In Figure 10, suppose an LSP for a certain group exists to LSRd1 and another LSRd2 wants to join the tree. In order for LSRd2 to initiate a trigger, it must already receive the traffic from the tree. This can be either at L2 or at L3. The former case is a chicken and egg problem. The latter case requires a mixed L2/L3 forwarding capability in LSRu to add the L3 branch.
+--------+ | LSRd1 | | | +--------+ | L3 | | LSRu | +--------+ | | | | | L3 | +--------------------------> +--------+ / | L2 | | | / +--------+ ->-------------+ | L2 | +--------+ +--------+ | LSRd2 | | | | L3 | +--------+ | | | | | L2 | +--------+ Figure 10. The LSRu has to request the label.
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.
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.
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.
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]. 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.
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.
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. 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 \ \ B---C---R2 Figure 11.
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.
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. 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).
Explicit distribution allows pre-establishment (before the arrival of data) of LSPs with topology or request driven triggers.
[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.
[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.
Arup Acharya IBM TJ Watson Research Center 30 Saw Mill River Road, Hawthorne NY 10532 Phone : 1 914 784 7481 EMail: email@example.com Frederic Griffoul Ulticom, Inc. Les Algorithmes, 2000 Route des Lucioles, BP29 06901 Sophia-Antipolis, FRANCE EMail: firstname.lastname@example.org Furquan Ansari Bell Labs, Lucent Tech. 101 Crawfords Corner Rd., Holmdel, NJ 07733 Phone : 1 732 949 5249 Fax : 1 732 949 4556 EMail: email@example.com
Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.