Network Working Group Jong-Moon Chung Internet Draft (Oklahoma State Expiration Date: August 2002 University) Mauricio A. Subieta Benito (Oklahoma State University) Harleen Chhabra (Exxon Mobil) Grace Yoona Cho (Oklahoma State University) Pravin Rasiah (Oklahoma State University) February 2002 RSVP-TE Extensions for MPLS Multicasting Services draft-chung-mpls-rsvp-multicasting-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document addresses the required extensions to the Resource Reservation Protocol (RSVP) to support MPLS network multicasting functionalities. The concepts presented in this paper support the delivery of multicasting traffic in accordance to the traffic engineering (TE) parameters provided in the MPLS specifications. The IP multicasting procedures based on the protocol procedural format Jong-Moon Chung, et al. Page <1> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 of other multicasting protocols (e.g., PIM-DM, PIM-SM, DVMRP, MOSPF, CBT, etc.) will be fully embedded into the RSVP-TE signaling operations to enable all multicasting procedures to be conducted through pure MPLS networking operations. Table of Contents 1. Introduction................................................3 2. Extensions to RSVP for Multicasting in MPLS Networks........3 2.1. The MULTICASTING_SESSION and TREE objects...................3 2.1.1. LSP_IPv4 MULTICASTING_SESSION Object........................4 2.1.2. LSP_IPv6 MULTICASTING_SESSION Object........................4 2.1.3. TREE Object.................................................5 2.2. Extensions to RSVP: Join, Leave, McRecal, and Destroy Messages....................................................6 2.2.1. Join message................................................6 2.2.2. Leave message (ResvTear message)............................7 2.2.3. Multicast Recalculation (McRecal) message...................7 2.2.4. Destroy message (PathTear message)..........................8 2.3. Multicasting LSP Tree Path and Resv Message Extensions......8 2.3.1. Multicasting Extensions to the Path Message (Msg type = 1)..8 2.3.2. Multicasting Extensions to the Resv Message (Msg type = 2)..8 2.4. Multicasting Extensions to the Hello Message................8 3. Construction of the Multicasting Distribution Tree using RSVP-TE.....................................................9 3.1. Sender-Initiated Tree Calculation...........................9 3.2. Receiver-Initiated Tree Calculation........................11 3.3. Re-calculation Procedures..................................12 4. Conclusion.................................................13 5. References.................................................13 6. AuthorsÆ Addresses.........................................14 Abbreviations CBT: Core Based Tree CoS: Class of Service DVMRP: Distance Vector Multicast Routing Protocol FEC: Forwarding Equivalence Class GoS: Grade of Service MIDB: Multicasting Information Database MOSPF: Multicast Open Shortest Path First PIM-DM: Protocol Independent Multicasting-Dense Mode PIM-SM: Protocol Independent Multicasting-Sparse Mode QoS: Quality of Service LSR-RP: Label Switching Router-Rendezvous Point Jong-Moon Chung, et al. February 2002 Page <2> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 1. Introduction Multi Protocol Label Switching (MPLS) networking provides an underlying networking architecture to support various Traffic Engineering (TE) and Quality of Service (QoS) features. However, the current standards are not capable of providing MPLS based multicasting traffic services, rather an IP controlled MPLS overlay model is provisioned to conduct this task. The protocol extensions to enable MPLS multicasting services proposed in this document agrees with the fundamental framework proposed in [9]. The basic concept is to enable MPLS to provide all functionalities and services required for multicasting, where the addressing and management topology of current IP multicasting users and groups will be done by the Internet Group Management Protocol (IGMP), thereby keeping the management and addressing the same as currently done in IP, but enabling the TE advantages of MPLS to exist over the multicasting network connections. The proposed work in this document extends to the implementation of MPLS multicast protocols and procedures based on the Resource Reservation Protocol with Traffic Engineering (RSVP-TE) extensions [1][2]. The extensions provided to RSVP for LSP tunnel applications in RFC 3209 [1] are restricted to unicast label switched paths, where multicast LSPs were left for further study. With this focus, the technical approach proposed in this document is to enable RSVP- TE with the full set of multicasting functionalities such that MPLS networking is fully capable of multicasting control and services rather than it being dependent on the IP over MPLS overlay model. 2. Extensions to RSVP for Multicasting in MPLS Networks RSVP applies IP datagram forwarding as a transport mechanism [2]. The proposed extensions to RSVP enable the RSVP signaling mechanism to establish, maintain, and terminate multicasting connections. This can be accomplished by adding message types and new C-type identifiers to the existing objects of the messages to establish multicasting based operations using the objects of the RSVP-TE messages. 2.1. The MULTICASTING_SESSION and TREE objects The MULTICASTING_SESSION and the TREE objects explained in this document can be used for the multicasting tree control procedures as optional objects that are additional to the SESSION object (i.e., they do not replace the SESSION object). When a source that is multicasting is associated with a particular multicast session, then the RSVP-TE message format may include the MULTICASTING_SESSION and TREE objects. Jong-Moon Chung, et al. February 2002 Page <3> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 2.1.1. LSP_IPv4 MULTICASTING_SESSION Object Class = MULTICASTING_SESSION, LSP IPv4_Multicast C-Type = 5 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicasting Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Multicast ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicasting Group Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Multicasting Source Address IPv4 address of the source node for multicasting tree. Multicast ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. IPv4 Multicasting Group Address A 32-bit IPv4 Multicasting group address used in the multicasting session that remains constant over the life of the multicasting tree connection. 2.1.2. LSP_IPv6 MULTICASTING_SESSION Object Class = MULTICASTING_SESSION, LSP_Ipv6_Multicast C-Type = 6 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Multicasting Source Address | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MUST be zero | Multicast ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Multicasting Group Address | + + | | + + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Multicasting Source Address IPv6 address of the source node for multicasting tree. Jong-Moon Chung, et al. February 2002 Page <4> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 Multicast ID A 16-bit identifier used in the SESSION that remains constant over the life of the tunnel. IPv6 Multicasting Group Address A 16-byte IPv6 Multicasting group address used in the multicasting session that remains constant over the life of the multicasting tree connection. The Multicast ID is used when there is a need to identify different sessions of multicasting services over the same multicasting tree. If there is no use for this field then it is set to all zeros. 2.1.3. TREE Object The TREE object is a list of multicasting tree LSR-RP (Label Switching Router-Rendezvous Point) addresses that are announced, such that LSRs that are not part of the multicasting tree can identify these LSR-RPs for future connection purposes to the multicasting tree. A LSR-RP is any intermediate LSR that has two or more branches that forward traffic or signaling downstream or aggregate upstream. In addition, for the Join message sent from the root LSR, the TREE object can be used to establish an explicit traffic path when connecting to a new host. In this case, the TREE object list of LSR-RPs will indicate this flow path, where the last LSR-RP of the TREE object list will be the one to connect to the new host. The TREE Class is 22. There are two C-Types defined. Class = TREE, LSP_IPv4_TREE C-Type = 1 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicasting LSR-RP Address-1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ . . . . ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv4 Multicasting LSR-RP Address-N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv4 Multicasting LSR-RP Address A 32-bit IPv4 Multicasting LSR-Rendezvous Point address Jong-Moon Chung, et al. February 2002 Page <5> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 Class = TREE, LSP_IPv6_TREE C-Type = 2 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Multicasting LSR-RP Address-1 | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ . . . . ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + + | IPv6 Multicasting LSR-RP Address-N | + + | | + + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IPv6 Multicasting LSR-RP Address A 16-byte IPv6 Multicasting LSR-Rendezvous Point address 2.2. Extensions to RSVP: Join, Leave, McRecal, and Destroy Messages In order to accommodate the proposed RSVP-TE for multicasting capabilities, four RSVP-TE messages are defined: Join, Leave, McRecal, and Destroy. 2.2.1. Join message We assume that the mechanisms that provide authentication and authorization services are provided for the MPLS network, and that the verification takes place for every node that requests multicasting traffic. When a new host wants to join an existing multicast tree, a Join message will be issued by the new host thereby making a request to join the multicasting tree. In the case where a non-connected label switching router (LSR) is making this request, the LSR will send a Join message to a multicasting LSR of the multicasting tree requesting for a connection. Following this, a Join message will be sent from that multicasting LSR to the root LSR of the multicasting tree requesting a connection and to update the multicasting information database (MIDB) with this request. This Join message may trigger a recalculation of the tree for connection updates. In the RSVP common header, the message type (Msg type) 8 is assigned to indicate the Join message (Msg Type = 8). Jong-Moon Chung, et al. February 2002 Page <6> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 The format of the Join message (Msg type = 8) is as follows: :: = [] [] [] [] [] [...] [] The MULTICASTING_SESSION object of the Join message will include the information of the multicasting tree. 2.2.2. Leave message (ResvTear message) A leaf LSR may initiate a Leave message when it does not have any more hosts actively participating in the multicast session. The Leave message used in multicasting is conducted by the ResvTear message (Msg Type = 6 [2]) that is sent to the upstream LSR-RP, which contains the MULTICASTING_SESSION object information. If the LSR-RP sees that all attached multicasting users are not in service anymore, then the LSR-RP will send a ResvTear message to the upstream LSR requesting a disconnection from the multicasting tree. In this fashion, the Leave functionality will enable parts of the tree that are not used to disconnect itself in modular units. 2.2.3. Multicast Recalculation (McRecal) message The McRecal message is used to inform the root LSR that it has to recalculate the multicast tree for that multicasting group. It also carries the updated information downstream to keep the MIDB of the intermediate nodes current. The McRecal message is assigned Msg type = 9. A McRecal message must be routed like the corresponding Resv message or a ResvTear message, and its IP destination address will be the multicast address of the previous hop. The format of the McRecal message (Msg type = 9) is as follows: ::= [ ] [] [] [] [] [] [...] [] Jong-Moon Chung, et al. February 2002 Page <7> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 2.2.4. Destroy message (PathTear message) The root initiates the Destroy function for a Multicast tree when it wants to terminate a multicast session. The destroy function is conducted through the PathTear message (Msg Type = 5 [2]), which is sent from the root to all its downstream LSRs. The PathTear message that is inherent in RSVP removes all the entries in the LSP as well as all reservations. 2.3. Multicasting LSP Tree Path and Resv Message Extensions In both the Path and Resv messages the SESSION objects can be used with new C-Type assignments to indicate multicasting applications. 2.3.1. Multicasting Extensions to the Path Message (Msg type = 1) In the Path message, the MULTICASTING_SESSION object provides necessary information that should be included in addition to the SESSION object. The MULTICASTING_SESSION object can be considered as an optional object according to the needs of the multicasting applications. The Path message originates from the LSR-RP to the LSR that desires to join the multicasting tree. The MULTICASTING_SESSION object will enable LSRs that are not part of the multicasting tree to know of the multicasting source and group information. 2.3.2. Multicasting Extensions to the Resv Message (Msg type = 2) The Resv message is also extended with the MULTICASTING_SESSION and TREE objects that can be treated as optional objects that are additional to the SESSION object. The MULTICASTING_SESSION and TREE objects used in the Resv message are specified in Section 2.1. 2.4. Multicasting Extensions to the Hello Message The RSVP Hello extension of RFC 3209 enables RSVP nodes to detect when a neighboring node is not reachable. The HELLO mechanism is intended for use between immediate neighbors, and therefore, a Hello message and a Hello Acknowledgement message are exchanged between two RSVP neighbors. The Hello message has a Msg Type of 20 [1]. The extensions to the Hello message format for multicasting applications are as follows: ::= [] [][] The MULTICASTING_SESSION object will enable LSRs that are not part of the multicasting tree to know of the multicasting source and group information. The TREE object contains a list of LSR-RPs. It Jong-Moon Chung, et al. February 2002 Page <8> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 allows intermediate LSRs to identify the LSR-RPs for future connections to the multicasting tree. 3. Construction of the Multicasting Distribution Tree using RSVP-TE The calculation and construction of the multicasting distribution tree must be done in two different contexts: sender-initiated tree calculation, and receiver-initiated tree calculation. Sender- initiated construction occurs when a new source of multicasting traffic starts delivering traffic to all the members of a group, which is known as a traffic-driven scheme. The receiver-initiated calculation becomes useful when a new member of a group wants to start receiving traffic, following a request-driven scheme. The protocol fields that trigger the multicasting operations of RSVP-TE as well as the procedures for creating the multicasting trees, which have not been detailed in previous works, are provided here. In addition, this document enables the multicasting functions of RSVP-TE to be independent of traditional IP-based multicast routing protocols, such as MDVMRP, MOSPF, PIM, etc. However, IGMP will be used to provide the mechanism for establishing and maintaining multicasting group memberships. The TE parameters used in MPLS can provide DiffServ [4] and flexible QoS features in the multicasting tree calculations. In order to include the TE parameters as the main constraints for the tree calculation, a set of extensions can be added to the traditional routing calculation algorithms, such as the distance vector (DV) or the link state (LS) algorithms. Furthermore, based on the current backbone network layout and the topology of how the backbone networks are administered by carrier companies, enough flexibility at calculating the distribution trees has to be given. For this purpose three different tree construction mechanisms can be considered: 1. Tree construction by means of source controlled routing, 2. Tree calculation by means of using traditional algorithms such as the DV or LS algorithms that are solely based on distance oriented metric values, and 3. Tree calculation by means of enhanced versions of the DV or LS algorithms that employ both TE parameters and distance oriented cost values as metric values in the tree calculations. In the following subsections, it is assumed that every LSR knows its neighboring LSRs due to an execution of the RSVP-TE Hello message procedures. 3.1. Sender-Initiated Tree Calculation The calculation and construction of the tree should be performed based on the LSRs that have active members (hosts) that wish to receive multicasting traffic. We assume that they have been either identified in advance or they will be joining dynamically. Jong-Moon Chung, et al. February 2002 Page <9> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 In order to properly calculate the tree, the first step is to find out if there is an IGMP group definition table constructed. This information is assumed to be found in every node in a Network Management System (NMS) database with listings of the group memberships, or in a LSR. With this information, the Multicasting Information Database (MIDB) is created with the purpose of keeping track of all multicasting sources, distribution groups, and destinations. In addition, the MIDB allows the multicast information to be decentralized, making it more effective for dynamic group membership control. If this information is not available, the RSVP- TE Hello extensions mechanism with multicasting extensions can be used to provide information to the MIDB. With the information contained in the MIDB, the calculation for the tree can be done quickly based on one of the methods described above. Once the tree is calculated, the Path messages are generated with the required session object (containing the source and group IP multicasting addresses) along with the other necessary object field information. Once all the messages have been delivered, and all the reservations are defined, the multicast traffic can be delivered to all the predefined nodes. Distribution calculation based on MIDB information +-----------+ | MIDB | +-----+-----+ (3)Multicasting | |(1)Multicasting Tree |(2)Path message Traffic | V Database Information| sent to all LSRs +-----------+ --> +-----+-----+ V of the tree. | Source +-----+ Root LSR | +-----------+ +-----+-----+ | |(4)Multicasting Traffic (5,6,7) | V (5) (6) +-----+-----+ --> +-----------+ --> +-----------+ | LSR +-----+ LSR +-----+ Receiver 1| +-----+-----+ +-----------+ +-----------+ | |(5) | V (6) (7) +-----+-----+ --> +-----------+ --> +-----------+ | LSR +-----+ LSR +-----+ Receiver 2| +-----------+ +-----------+ +-----------+ In Step (1) the information gathered in the MIDB is used by the root LSR to construct the distribution tree. The root LSR will send out Path messages to the LSRs of the multicasting tree to establish LSP connection (step (2)). This will be confirmed by Resv massages at each link of the multicasting tree (not shown in the figure). After the tree connection is completed the source starts multicasting traffic through the root LSR to the LSRs in the multicasting tree composed by Steps (3) through (7). Jong-Moon Chung, et al. February 2002 Page <10> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 3.2. Receiver-Initiated Tree Calculation A multicasting distribution tree is not static; hence, mechanisms that allow dynamic calculation of the tree have to be defined. In order to recalculate the tree, a node has to issue a Join, Leave, or McRecal message. These messages have been defined in Section 2.2. The receiver-initiated tree is based on a predefined source already generating multicast content, and the information contained within the MIDB. 1. When a node wants to request a multicasting tree connection, the node will send a RSVP-TE Join message to a LSR-RP of the multicasting tree. 2. This LSR-RP of the multicasting tree will then send a Join message to the root LSR. This Join request will be checked for multicasting tree connection permission. If permission is granted, a recalculation of the tree may occur if necessary. In this case, a McRecal message will be issued for the recalculation of the multicasting tree. 3. If a multicasting tree recalculation has been requested, an update to the label mapping table of each LSR of the multicasting tree will be conducted. The update procedure refreshes the interfaces in which each message is received and the interfaces through which each message is forwarded. 4. The multicasting root LSR will issue a Join message to the node that is requesting connection to the multicasting tree through the LSR-RP that the root LSR decides to use for this connection. This LSR-RP will issue a Path message to the new host for connection establishment to the tree. 5. If the procedure is not successful, the new receiver that was making the Join message request will wait for an arbitrary timeout and retries until it is able to obtain a multicasting link connection Receiver-initiated tree calculation +---------+ +-----------+ | Source +---+ Root LSR | +---------+ +-----+-----+ | | ^ (2)Join | |(3) | message (1)Join message | V Join +---- <------- +-----+-----+ +-----------+ +------------+ | LSR-RP +-----+ LSR-RP +-----+New Receiver| +-----+-----+ +-----------+ +------------+ | ------> -------> | (4)Join message (5)Path | <------- | (6)Resv | +-----+-----+ +-----------+ | LSR +-----+ LSR | +-----------+ +-----------+ Jong-Moon Chung, et al. February 2002 Page <11> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 In the figure above, step (1) shows the Join message indicating the new receiverÆs intention to receive multicasting traffic. Step (2) shows the Join message generated from the LSR-RP that received the Join message requesting the root LSR to establish a multicasting connection. This in turn triggers the recalculation of the multicasting tree. Assuming that permission has been granted by the root LSR, steps (3) and (4) show a Join message issued by the root LSR which will contain a TREE object. The root LSR will assign one of the neighboring LSR-RP to the host to become its connecting LSR. This LSR-RP will receive the Join message sent from the root LSR, and the Join message will be converted to a Path message to enable a LSP connection to the multicasting tree (step (5)). In step (5), a specific label may be requested to the down stream new receiver such that all outgoing multicasting connections from the LSR-RP may use the same label [2]. Step (6) shows the Resv message that will include the label to be used. 3.3. Re-calculation Procedures As mentioned before, a multicasting tree is not normally static, either because new nodes are joining or because nodes leave the tree. When a LSR does not have any more multicasting receivers, it will issue a RSVP-TE Leave message, which will be sent to the upstream LSR in order to stop the multicast traffic. The upstream LSRs will perform the following activities: 1. If the LSR that is leaving is not the last LSR within the tree, then the upstream LSR will erase the label mapping entry for the downstream LSR, and it will issue a McRecal message to the root LSR such that the root LSR can recalculate the tree should it be necessary. Otherwise, the root LSR will use this information to request an update of the label mapping tables of the LSRs along the multicasting tree. The information in the MIDB will also be updated. 2. If a tree recalculation is conducted, the root LSR will trigger a re-calculation procedure via a McRecal message so all the LSRs can use the updated information in the MIDB. 3. If the LSR that is leaving is the last leaf LSR on the multicasting tree, then the upstream LSR will in turn issue a RSVP-TE Leave message. The MIDB table will then be updated. The root LSR in turn (after receiving the message and recalculating the tree) will trigger a recalculation procedure via a McRecal message so all the nodes can use the updated information in the MIDB. 4. If the leaving LSR is the last one connected to the root LSR (that is, the root LSR will be the last node on the tree), then the Leave message procedures will be performed. A Destroy procedure of the tree will not be performed. The tree will be kept alive and the tree will be recalculated and rebuilt when new hosts request connection to the tree. Jong-Moon Chung, et al. February 2002 Page <12> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 5. In the event that the source has no more multicast content to multicast, the root LSR will issue a RSVP-TE Destroy message that will notify all the LSRs in the tree that the label mappings have to be released and all the multicasting traffic forwarding should be stopped. This will also trigger a purge procedure within the MIDB, clearing all the entries for the specific multicasting group. 4. Conclusion The extensions proposed to RSVP-TE of this document deliver the basic configuration and functionality required to support multicasting for MPLS networking applications. By establishing Join, McRecal, Leave, and Destroy messages, a multicasting distribution tree that is conformant with the constraints defined by the MPLS TE parameters can be created through RSVP-TE signaling. Furthermore, by combining the multicasting extensions for RSVP-TE with the IGMP features for multicasting group database control and the Hello message with the MIDB extensions a set of operational procedures have been developed for the dynamic management of multicasting trees. This conceptualization allows all traffic engineering features of MPLS networking to be flexibly provided within the multicasting services in a very efficient, scalable, and straightforward fashion. 5. References [1] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and Swallow, G., ææRSVP-TE: Extensions to RSVP for LSP Tunnels,ÆÆ RFC 3209, The Internet Society, Dec. 2001. [2] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., "Resource ReSerVation Protocol (RSVP) -- Version 1, Functional Specification," RFC 2205, The Internet Society, Sept. 1997. [3] Chung, J.-M., (Invited Paper) ææAnalysis of MPLS Traffic Engineering,ÆÆ in Proc. IEEE Midwest Symposium on Circuits and Systems 2000 (MWSCASÆ00), East Lansing, Michigan, U.S.A., Aug. 8-11, 2000. [4] Chung, J.-M., Marroun, E., Sandhu, H., and Kim, S.-C., ææVoIP over MPLS Networking Requirements,ÆÆ in Proc. IEEE International Conference on Networking 2001 (ICNÆ01), Colmar, France, July 9- 13, 2001. [5] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y., and Rasiah, P., ææLDP Extensions for MPLS Multicasting Services,ÆÆ submitted, IEEE Networks. [6] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y., and Rasiah, P., ææRSVP Extensions for MPLS Multicasting Services,ÆÆ submitted, IEEE J. Select. Areas in Commun. [7] Chung, J.-M., Subieta Benito, M. A., Chhabra, H., Cho, G. Y., and Rasiah, P., ææLDP Extensions for MPLS Multicasting Services,ÆÆ work in progress, Internet Draft, Internet Engineering Task Force, The Internet Society. [8] Miller, K. C., Multicast Networking and Applications, Addison- Wesley, 1999. Jong-Moon Chung, et al. February 2002 Page <13> Internet Draft draft-ietf-mpls-rsvp-multicasting-00.txtAugust, 2002 [9] Ooms, D., Sales, B., Livens, W., Acharya, A., Griffoul, F., and Ansari, F., ææFramework for IP Multicast in MPLS,ÆÆ work in progress, Internet Draft, Internet Engineering Task Force, The Internet Society. [10] Rosen, E. and Viswanathan, A., ææMultiprotocol Label Switching Architecture,ÆÆ RFC 3031, The Internet Society, Jan. 2001. [11] Stallings, W., High-Speed Networks TCP/IP and ATM Design Principles. New Jersey: Prentice Hall, 1998. [12] Whitmann, R. and Zitterbart, M., Multicasting Communication Protocols and Applications. Morgan Kaufman Publishers, 1999. [13] Williamson, B., Developing Multicasting Networks. Vol. I, Cisco Press, 2000. 6. AuthorsÆ Addresses Jong-Moon Chung ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-9924 Email: jchung_osu@lycos.com Mauricio A. Subieta Benito ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-5215 Email: maurici@okstate.edu Harleen Chhabra Exxon Mobil P.O. Box 4449 Houston, TX 77210-4449 Phone: (713)431-4106 Email: Harleen.Chhabra@exxonmobil.com Grace Yoona Cho ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-5215 Email: chog@okstate.edu Pravin Rasiah ACSEL & OCLNB Laboratories School of Electrical & Computer Engineering Oklahoma State University Stillwater, OK 74078 Phone: (405)744-2662 Email: pravinras10@lycos.com Jong-Moon Chung, et al. February 2002 Page <14>